[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121209010248.GC526@openwall.com>
Date: Sun, 9 Dec 2012 05:02:48 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU
Sayantan -
On Fri, Dec 07, 2012 at 09:58:12AM +0530, Sayantan Datta wrote:
> My task is even simpler though. I only need to replace a set of compile
> time constants. Using build options I can eliminate the source,llvmir
> ,amdil sections and keep only the text/ISA section in the binaries. My
> problem is that I cannot pinpoint any location for patching. First I search
> for an integer constant in binaries and came up with a set of locations
> where I can find that integer. Next I change the constant and do the search
> again to get a second set of locations. But I couldn't find any common
> location between the two sets.
This suggests that you should be searching for other than raw values of
the constants.
> Should I be looking for character
> equivalent of integers(like what we do for text files e.g string matching )
> instead of searching binary integers in the header ?
No.
What we're looking for is a sequence of _bits_ matching the immediate
offsets that we hard-code in the source. Moreover, the few always-zero
least-significant bits might not be encoded there at all. For example,
if an instruction can only load 32-bit aligned values, then it will not
need to encode 2 least-significant bits of the byte offset. In other
words, it will encode the 32-bit word offset rather than byte offset.
For loads to VGPRs (which we probably have here), the granularity can be
up to 512-bit.
Additionally, there might be some other base offset added to your
hard-coded offsets. So the offsets might not be the same as what you
specify, and they might even be negative. (The immediate offset field
is typically a small signed integer. To maximize the available range,
if required, the compiler may choose to use offsets relative to other
than the beginning of the memory area in question.)
Your best bet to find them is really to compare several builds, for
different hard-coded offsets. Then for the locations that differ across
the builds, you can calculate the deltas - and match those against
deltas between your hard-coded offsets, with varying shift amounts
added (since the immediate offset field does not have to start right at
instruction boundary, nor at a byte boundary).
Another potential hurdle is endianness. The instruction field does not
have to be in the same endianness as the host's integers are.
In AMD_Southern_Islands_Instruction_Set_Architecture.pdf (SHA-1:
c64c24077eab93b070d291da3624a8d988d70d5d), see pages 66, 89. It appears
that we need to be patching 12-bit field called inst_offset.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
