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.