[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUBvFJexoJK+BGSZHyVnao2cKPgboFkk+T6vXyt7b8tD_w@mail.gmail.com>
Date: Tue, 14 May 2013 21:21:45 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: des-opencl salt binaries
On Tue, May 14, 2013 at 9:16 PM, Sayantan Datta <std2048@...il.com> wrote:
> Hi Solar,Lukas,Daniel
>
> I had been playing around with des-opencl GCN binaries for the last few
> days. So,I built all the 4096 kernel binaries to see how much they differ
> among themselves. During the process I found the following:
>
> Opencl binaries generated with build option "-fno-bin-llvmir
> -fno-bin-source -fbin-exe -fno-bin-amdil" still contains the AMD IL ,
> however in a much different location.
>
> OpenCl binaries so generated have following sections:
> .rodata - very small in size and same for all kernel
> .text - this is the section of our main interest and it is an elf
> object itself.
> .comment - very small , not intersted.
>
> Now the offset and size of above .text section can be extracted using
> command '*objdump -h filename*' and a custom script. So I extract the
> .text section into a new file. Now the new file has following
> sections(using command '*objdump -h newfile*'):
> .text - This section contains the AMD IL again. Its size is very large
> and occupies nearly 85% of the full openCL object. So, I zeroed this
> section section entirely.Fortunately zeroing the IL didn't affect the
> runtime characteristics of binary. This enabled huge amount
> compression since the AMD-IL portion is very different for different
> different des salts.
> .data - contains 1280 bytes of zeroes padding.
> .text - This section contains the actual ISA and the associated memory
> addresses. If we see the ISA for different salts , all of them are exactly
> same. This puzzled me in the beginning but the ISA is only the tip of the
> ice berg.
> The main ISA(only the instructions) which is same for all 4096
> kernels is only 4168 bytes. The associated data(memory addresses and
> constant buffer address etc) is excess of 62KB and it is different for all
> 4096 kernels.
> Even though the data section is different for all kernels,
> chunks of bytes staring at different offsets were found to be same when
> compared to a base kernel. Nearly 40 to 70% of all data sections are same
> even though they have
> different offset locations in the kernel. However the
> difference between the data in the kernel is still too large to make
> runtime patching possible. I instead focused on improving compression
> rather than runtime patching. So I zeroed big chunks
> which were similar to the base kernel and stored the necessary
> offsets in a file.
> .data - again 1280 bytes of zero padding .
>
> Finally I merged all 4096 kernels to a single file which improves
> compression a little bit. Now the compressed recoverable binaries have size
> 7.7MB using 7z , 52MB using rar and 61MB using tar. I can automate the
> extraction and patching process, but the final extracted kernels would take
> around 1.5GB disk space.
>
> Regards,
> Sayantan
>
> Sorry for the misalignment of the sentences. It just happened when I hit
send.
Regards,
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.
