Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 Apr 2013 21:12:58 +0200
From: magnum <>
Subject: Re: Endianity in input files

On 16 Apr, 2013, at 19:55 , Alexander Cherepanov <> 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


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.