[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67d5c85a201503b7e1b7224fbd49bd4c@smtp.hushmail.com>
Date: Fri, 1 Feb 2013 01:59:39 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: DMG (was: dmg2john)
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?
magnum
On 31 Jan, 2013, at 9:13 , Milen Rangelov <gat3way@...il.com> wrote:
> Hmmm, I was not aware about the "Apple" check (I am using just the koly/UEFI PART/msdos partition if I remember correct). I guess that is a filesystem identifier so there should be other bytes that we can scan together with the apple string.
>
> On Thu, Jan 31, 2013 at 9:59 AM, 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 :(
>
> We'll only keep it until we have something better and then ifdef it out. False positives are bad but false negatives are much worse!
>
> I am sure a 40-bit "Apple" signature will give a whole lot more false positives than a 64-bit zero though. Just do the math! And we could search for 24 zero bytes instead, or 32 if we want to. There were a whole lot of zeros in there.
>
> > I think the key to this is to get more samples and understand the image layout properly. When we worked with Dhiru on dmg, we did not dig that much into this (and we did not have many samples to analyze). So we just looked for known plaintexts that happened to occur either in the first or the last 2 decrypted sectors (that would be either MSDOS signatures, UEFI signatures, filesystem signatures, etc). Now decrypting that much of data then searching for signatures in it slows it down a lot. In fact, speed dropped several times going from the zeros check to the heuristics checks. It became more reliable, but much slower.
>
> We're (sort of) no longer looking at an image but at a partition and/or a file system, if I get things right. And this can be one of several partition types (or none!) and one of several file system types. So I believe there will never be a canonical one-size-fits-all solution unless we find something in the image itself, outside this data.
>
> For these plaintext magics we could also look at non-encrypted DMG files for clues. Like installation images. They are all over the net.
>
> magnum
>
Content of type "text/html" skipped
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.
