linux-ext4 - Re: algorithm for half-md4 used in htree directories

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF1vpkgPAy3FJ9mN22OVQ41jQAYoRdoCdqzYwRYYPXD4uucdpg@mail.gmail.com>
Date:   Sun, 3 Oct 2021 15:47:01 +0300
From:   Avi Deitcher <avi@...tcher.net>
To:     linux-ext4@...r.kernel.org
Subject: Re: algorithm for half-md4 used in htree directories

I can narrow down the question further. In my live sample, one of the
entries in the tree is for a directory named "dir155".

If I run "dx_hash dir155", I get:

# debugfs -R "dx_hash dir155" /var/lib/file.img
debugfs 1.46.2 (28-Feb-2021)
Hash of dir155 is 0x16279534 (minor 0x0)

If I look in the tree with "htree_dump", I get:

# debugfs -R "htree_dump /testdir" /var/lib/file.img
debugfs 1.46.2 (28-Feb-2021)
....
Entry #0: Hash 0x00000000, block 1
Reading directory block 1, phys 6459
168 0x00d11d98-b9b6b16b (16) dir155   332 0x009edafe-77de7d72 (16) dir319

That hash for dir155 does not match what dx_hash gave. If I try to
take the code from fs/ext4/hash.c and build a small program to
calculate the hash, I get:

$ ./md4 dir155
MD4: d90278a1 25182ac7 a02e56be c3f30f04
hash: 0x25182ac6
minor: 0xa02e56be

Clearly that isn't what is in the tree. What basic am I missing?

On Fri, Oct 1, 2021 at 2:49 PM Avi Deitcher <avi@...tcher.net> wrote:
>
> Hi,
>
> I have been trying to understand the algorithm used for the "half-md4"
> in htree-structured directories. Going through the code (and trying
> not to get into reverse engineering), it looks like it is part of md4
> but not entirely? Yet any subset I take doesn't quite line up with
> what I see in an actual sample.
>
> What is the algorithm it is using to turn an entry of, e.g., "file125"
> into the appropriate hash. I did run a live sample, and try to get
> some form of correlation between the actual md4 hash (16 bytes) of the
> above to the actual entry (4 bytes) shown by debugfs, without much
> luck.
>
> What basic thing am I missing?
>
> Separately, how does the seed play into it?
>
> Thanks
> Avi



-- 
Avi Deitcher
avi@...tcher.net
Follow me http://twitter.com/avideitcher
Read me http://blog.atomicinc.com