Date: Tue, 16 Apr 2013 21:12:58 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Endianity in input files On 16 Apr, 2013, at 19:55 , Alexander Cherepanov <cherepan@...me.ru> wrote: > On 2013-04-14 10:06, Solar Designer wrote: >> On Sat, Apr 13, 2013 at 05:31:23PM +0200, magnum wrote: >>> I did some testing of *2john programs on big-endian and noticed a problem that might be wide-spread: zip2john produces infiles that can only be cracked with a same-endian build of John. That is, some of the hex fields (integers) are in machine's endianness. >> >> Ouch. I am not surprised, though. >> >>> This is not a huge problem but we might want to fix it (in bleeding?). I think all hex fields should be LE regardless of arch. >> >> I agree. >> >>> OTOH if we change it, we break backwards compatibility on BE archs. >> >> Maybe we need to introduce new/revised $-prefixes for the affected >> formats, to indicate that they're now reliably LE. Print a warning for >> the old ones. > > If $-prefixes are to be revised maybe they could be simplified at the same time. Anything specific in mind? This could be a good opportunity to drop the first, redundant, '*'. It occurs in all or nearly all of Dhiru's formats. $zip$*0*1*8005b1b7d077708d*dee4 - old, machine-endian last field $zip$0*1*8005b1b7d077708d*dee4 - new, little-endian last field magnum
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.