Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ