Monday, January 21, 2013

BinMode: Parsing Java *.idx files, pt. deux

My last post addressed parsing Java *.idx files, and since I released that post, a couple of resources related to the post have been updated.  In particular, Joachim Metz has updated the ForensicsWiki page he started to include more information about the format of the *.idx files, with some information specific to what is thought to be the header of the files.

Also, Corey Harrell was kind enough to share the *.idx file from this blog post with me (click here to see the graphic of what the file "looks like" in Corey's post), and I ran it through the parser to see what I could find:

File: d:\test\781da39f-6b6c0267.idx

Times from header:
time_0: Sun Sep 12 15:15:32 2010 UTC
time_2: Sun Sep 12 22:38:40 2010 UTC


Server Response:
HTTP/1.1 200 OK
content-length: 14226
last-modified: Sun, 12 Sep 2010 15:15:32 GMT
content-type: text/plain
date: Sun, 12 Sep 2010 22:38:35 GMT
server: Apache/2
deploy-request-content-type: application/x-java-archive

Ah, pretty interesting stuff.  Again, the "Times from header" section is comprised of, at this moment, data from those offsets within the header that Joachim has identified as possibly being time stamps.  In the code, I have it display only those times that are not zero.  What we don't have at the moment is information about the structure of the header so that we can identify to what the time stamps refer.

However, this code can be used to parse *.idx files and help determine to what the times refer.  For example, in the output above we see that "time_0" is equivalent to the "last modified" field in the server response, and that the "time_2" field is a few seconds after the "date" field in the server response.  Perhaps incorporating this information into a timeline might be useful, while research continues in order to identify what the time stamps represent.  What is very useful is that the *.idx files are associated with a specific user profile, so for testing purposes, an analyst should be able to incorporate browser history and *.idx info into a timeline, and perhaps be able to "see" what the time stamps may refer to...if the analyst were to control the entire test environment, to include the web server, even more information may be developed.

Speaking of timelines, Sploited commented to my previous post regarding developing timelines analysis pivot points from other resources; in the comment, a script for parsing IE history files ( was mentioned; I would suggest that incorporating a user's web history, as well as incorporating searches against the Malware Domain List might be extremely helpful in identifying initial infect vectors and entry points.

Interested in Windows DF training?  Check it out: Timeline Analysis, 4-5 Feb; Windows Forensic Analysis, 11-12 Mar.  Be sure to check the WindowsIR Training Page for updates.

No comments: