[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 9 Dec 2012 14:11:56 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU
On Sun, Dec 9, 2012 at 11:45 AM, Sayantan Datta <std2048@...il.com> wrote:
> Hi Alexander,
>
>
> On Sun, Dec 9, 2012 at 7:19 AM, Solar Designer <solar@...nwall.com> wrote:
>
>> On the other hand, 0x0000000f is small
>> > enough to fit in an immediate offset field or even in a register number
>> > field (GCN allows for encoding of values in the -16 to +64 range in that
>> > way, via impossible register numbers).
>>
>
> Since the real world offset values would never exceed 8 bits , I think we
> should focus on that. That way we could also eliminate *endianness
> issue. *
> *
> *
> 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).* *
>
> Okay. So searching the exact values is not the way to go. So basically
> we've to diff two binaries and find the locations where they differ. And
> since the operands are not at byte boundaries , the operand might be spread
> over two consecutive bytes(considering nonzero 8 bit operands). Also taking
> in account a shift of 0bit and 4bit should suffice , because hopefully the
> size of operands and opcodes are always 4bit multiples. Are there any
> opcode or operand field which is not a multiple of 4bits ? Then find the
> deltas in their values and verify it is the same the source
> kernels. Negative numbers may be a problem though , because it would
> require the knowledge of how they are being encoded. For example the 2's
> complement of a small 12bit number say 000000000101 is a very large number
> 111111111011 .
>
> Regards,
> Sayantan
>
I checked the tahiti isa of two different hardcoded kernels and to my
surprise they just differ by a single line.
v_xor_b32 v68, v38, v68 // 00000A24:
3A888926
vs
v_xor_b32 v68, v21, v68 // 00000A24:
3A888915
However when I check the difference between two binaries directly there are
differences in more than 200 locations.
Sayantan
Content of type "text/html" skipped
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.
