|
Message-ID: <77ff9c46e1230d899d576ed2bc1b0089@smtp.hushmail.com> 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.