Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 1 Feb 2013 02:09:07 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: DMG (was: dmg2john)

On 1 Feb, 2013, at 1:59 , magnum <john.magnum@...hmail.com> wrote:
> 
>> On 31 Jan, 2013, at 8:43 , Milen Rangelov <gat3way@...il.com> wrote:
>> > I would rather avoid the "zero" test BTW. This is what my initial version did and it did work for some of the images, it also gave out a lot of false negatives for others. This saves a lot of CPU work, but it does not work reliably unfortunately :(
>  
> In addition to nulls, I added checks for "</plist>" and "jrnlhfs+", also 8 bytes each. 64 bits is a pretty low risk of false positive (especially at this speed). The koly is 8 bytes too as it reads an int after it (BTW it does an unaligned read of that int). The only really problematic check I see is "Apple". That's just 40 bits. And that one is not needed with the NULL test. Actually no other check is, from what I've seen so far.
> 
> I will bump the nulls test to 16, and disable the rest for now. There is no way in hell you'll get 128 consecutive bits of 0 in random data. I'll also remove the FMT_NOT_EXACT unless -DDMG_DEBUG.
> 
> How many nulls did you look for when you got false positives? It must have been fewer than 8, no?

Oh, you said false negatives. So I re-enabled the other tests again :-)  But not the Apple one.

magnum
[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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