[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bdd63a08680650e2d84a911a67c53caa@smtp.hushmail.com>
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.
