Ques on Windows file formats
Does anyone out there have a need to develop a better understanding of file formats, specifically from Windows systems? What I mean is, when you look at raw Event Log (sysevent.evt, etc) and Registry (system, sam, etc) files in a hex viewer, it looks like a mess. Would knowing the format of these files be of use/benefit to you?
My thought is that knowing the file format would increase the level of knowledge of the analyst, as well as provide some insight into what sorts of things are sitting in slack/unallocated space.
Yes Harlan, greater ease understaning of the raw Event Log especially would certainly be of a great assistance - are you working on anything towards this/ or can you recommend anything?
I've already released code and information in the past, but I'm working on redoing the code…not that it needs rewriting, but I'm looking at turning the scripts into Perl modules so that they are more easily incorporated into existing platforms, such as ProDiscover, Sleuthkit, PyFlag, etc.
I guess what I'm really trying to get a feel for here is the need for such a thing. After all, I've heard the term "Nintendo forensics" bandied about, and I have to wonder…do people really want to know the format of the INFO2 file, or are they content to simply run EnCase?
An example is that in developing my Perl script for parsing raw Event Log files, I found a complete event record that was hidden from the MS API…tools using the MS API reported 2363 event records, and I found 2364 complete event records.
I think knowing the file formats can only help. Nintendo forensics..oh how true it is.
I honestly think a majority of people will simply want to run encase, however there is a side of the forensic community that is interested in more than just running tools, so by all means post your information.
I understand what you're saying, but what I'm trying to do at this point is (a) see if there's interest, and (b) if so, see what format the information should be posted in.
How would the information be most likely to be used?
To answer a and b..
B) the information should be in multiple formats.
Something to add to a magic file. INFO2 is already there. but .evt files are not.
Any unique characteristics that would aid a hex search.
A 32byte header analysis (assuming that 32 contains all of the pertinent information about the file).
and a full breakdown of how to translate files by hand. –atleast the parts that contain the really important information anyways.
I can only attest to how this information would be used by me.
We capture 64 bytes of data from all network traffic. This is usually enough to determine what was being transmitted. However during one incident a discrepancy occured where a file was transmitted that was alleged to be a DB3 file. The only way to know was by finding the DB3 file format and checking it against the 64bytes. Turned out it was a flash file.
corroborating evidence is of the utmost importance, so every little bit of information helps. If computer forensics is going to be treated as a true science then we need to have the academic information behind us to prove that what we are saying is true.
> To answer a and b..
> A) Yes.
B> ) the information should be in multiple formats.
Great. Which ones?
> My suggestions
> Something to add to a magic file. INFO2 is already there. but .evt files are not.
> Any unique characteristics that would aid a hex search.
> A 32byte header analysis (assuming that 32 contains all of the pertinent
> information about the file).
Well, that response definitely confirms the need for the information! 😉 Dude, Event Log file headers are 48 bytes long. File "magic numbers" for file signature analysis are located in the first 20 bytes of the file.
> and a full breakdown of how to translate files by hand. –atleast the
> parts that contain the really important information anyways.
> corroborating evidence is of the utmost importance, so every little bit of
> information helps. If computer forensics is going to be treated as a true
> science then we need to have the academic information behind us to
> prove that what we are saying is true.