Hi, this is my firs post in this forum, i'm sorry for my non-perfect english.
so, i have a question about the structure of the $usnjrnl (Change journal) file i red the Carrier's Book (the bible) "Filsystem Forensic Analysis", and "Windows Internals", too. i looked at the poor microsoft documentation about it.
I found that the structure isByte Range Description Essential
0–3 Size of this journal entry Yes
4–5 Major version Yes
6–7 Minor version Yes
8–15 File reference of file that caused this entry Yes
16–23 Parent directory file reference for file that caused this entryNo
24–31 USN for entry Yes
32–39 Timestamp Yes
40–43 Flags for type of change (see Table 13.28) Yes
44–47 Source information No
48–51 Security ID (SID) No
52–55 File attributes No
56–57 Size of file name Yes
58+ File name Yes
BUT on internet, and on a parse-tool i found on many websites i found a different structure it's the same but at the end 0x38 2 Size of filename (in bytes)
0x3A 2 Offset to filename
0x3C V Filename
so, in the first we have 0-57 byte before filename, but in the second we have 0-59, with "Offset to filename" before filename..
i tryed the parse tool and i saw that it works correctly (i think) so i don't understand who is right!
Is this the reference you used?
http//
If not, have a look. I note that it says it is a reference for change journals of version 2 or later. So perhaps the differences you're seeing are for the difference versions of the journal.
Rich
yes, i used that reference. but i work only with version >= 2, and i just used that strucuture (not the first i wrote in the first post). It seems works, but the journal has some value i don't understand, for example the value "8224" in "Size of filename"…
and i think it's strage that carrier's book doesn't talk about the change of the strucuture by version..
What's the value stored in, does it need converting to something? You got a chunk of HEX you can post so that we're talking about the same thing?
sure, i'm posting an example. i'm using a parser that i found online, and i'm trying to understand if it works or not.. however this is the hex00 00 00 00 00 00 00 00 00 00 20 20 00 00 90 00 3C 00 63 00 68 00 72 00 6F 00 6D 00 65 00 2D 00 65 00 78 00 74 00 65 00 6E 00 73 00 69 00 6F 00 6E 00 5F 00 62 00 70 00 66 00 62 00 62 00 6E 00 67 00 63 00 63 00 65 00 66 00 62 00 62 00 6E 00 64 00 67 00 69 00 6E 00 6F 00 6D 00 6F 00 66 00 67 00 70 00 61 00 67 00 6B 00 6A 00 63 00 6B 00 69 00 6B 00 5F 00 30 00 2E 00 6C 00 6F 00 63 00 61 00 6C 00 73 00 74 00 6F 00 72 00 61 00 67 00 65 00 2D 00 6A 00 6F 00 75 00 72 00 6E 00 61 00 6C 00 00 00 00 00 D0 00 00 00 02 00 00 00 B6 F0 00 00 00 00 23 01 53 2D 01 00 00 00 03 00 F8 05 44 41 00 00 00 00 54 89 14 84 C1 31 CC 01 02 01 00 00 00 00 00 00 00 00 00 00
and this is the text...... ....<.c.h.r.o.m.e.-.e.x.t.e.n.s.i.o.n._.b.p.f.b.b.n.g.c.c.e.f.b.b.n.d.g.i.n.o.m.o.f.g.p.a.g.k.j.c.k.i.k._.0...l.o.c.a.l.s.t.o.r.a.g.e.-.j.o.u.r.n.a.l.....Ð.......¶ð....#.S-......ø.DA....T‰.„Á1Ì.............the parser shows "Size of filename 8224" and "Offset to filename 114"…
even if the strucuture is correct…
I don't think that's enough hex posted for the full record, I think from the first letter of the filename, you should have 60 bytes before that.
From your first letter of the filename, the 'c' of chrome, you only have 18 bytes.
But anyway, your size of filename is \x16\x00, or 22 in little endian. And your offset is \x3C\x00, which is 60 in little endian. Both of these values are correct, as the filename is 22 bytes long - 11 characters of unicode, and it starts from offset 60 of the file as I described at the beginning.
the parser shows different values (8224 and 114). do u think the problem could be that it's not little endian ? i'll try to force it… but if these values are correct i suppose that the structure is right, good
Sorry I have no idea why I posted \x16\x00 and 22, clearly wasn't concentrating flicking between machines. Should have said \x90\x00 and 144 bytes (72 unicode chars)! But it appears correct anyway heh.
72 char infact is the real size of filename.. so i'll try to force little endian…
the thing that is not clear is that if the problem is that there isn't little endian, why the filename is parsed correctly?
Size Offset Filename
8224 144 chrome-extension_bpfbbngccefbb
the parser shot this, with that structure… it could not be a endian's problem..