[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Mar 2015 04:24:21 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Generic parsing functions -- prototype
On 2015-03-30 01:29, Alexander Cherepanov wrote:
> I've tried to create some prototype of generic parsing functions. Not
> much is implemented. But it's enough to for 7z format (more or less).
This was discussed a couple of years ago and I wasn't very interested
then, but I think it may be about time we do this. I opened an issue on
GitHub linking to this thread.
> - %d for unsigned decimal numbers (uint32_t), can have a range for
> accepted values like %1-24d. Returns the result via uint32_t *;
I think we should use %u for unsigned to avoid confusion - and to be
able to support signed integers later.
> - %s -- arbitrary string (like usernames).
BTW we might need some Unicode magic like the salt length check in
mscash2. That format's valid has to verify that the salt *after encoding
to UTF-16* does not exceed a max length. With possibly UTF-8 input, that
is kinda tricky.
> - spaces. Do we have hashes with spaces in them?
Yes.
> Do we need negative numbers (they are used only in pdf hashes)?
If we already have a format needing it, I'd say yes.
> - hex. Do we need variants for lower- and upper-case?
Yes. Some formats require a certain case.
> - fixed-length data. Do we have cases of fixed-length data without a
> separator after it?
I'm pretty sure we have formats that look like one long hex blob, but
that are actually fixed-length salt and a hash. Yes, MSSQL comes to mind.
> - variable-length data. Do we need ranges for lengths?
Probably. Formats like RAR may have inlined data of very varying length.
That's all I have for now. But I like this idea.
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.
