[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABh=JRFJ4-X2NtzCeU=1qcx=TMTvafMpNg=CpO-17p3Gd_XUsg@mail.gmail.com>
Date: Thu, 31 Jan 2013 10:13:48 +0200
From: Milen Rangelov <gat3way@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: DMG (was: dmg2john)
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.
