Archive

Posts Tagged ‘lso’

Small updates

February 17th, 2010 No comments

Just recently saw a post at Slashdot about Adobe implementing private browsing in their Flash Player.  That means that when the user starts private browsing mode in their web browsers LSO files will not be stored on disk.  This is implemented in the way that during the private browser session all Flash cookies are stored only in memory, and as soon as the browser is closed they are cleared.

Why do we care about this? Well with this change we will start to see that private browsing is becoming more private (or actually private), and it will make our lives as forensic investigators more difficult, since we cannot simply examine Flash cookies to determine the users browsing history (at least partially).

I just posted a blog post in the SANS forensics blog about the structure of LSO files and a quick view of how log2timeline parses it to extract timestamps. I’m not going to repeat that post on this site, so if you would like to know more about the binary format of LSO files, please read the blog post.

Recently there have been a lot of discussions about creating a standard for timeline analysis. Currently log2timeline relies upon the good old mactime format for it’s output (although it is possible to use several different output mechanism), a standard that was created for filesystem timelines.  Although it works great for its original purpose It might not be the most optimal output mechanism when incorporating timestamp information from other sources which is one of the reasons why this push for a new standard has been discussed. The structure of log2timeline will be changed soon to separate the internal structure away from the emphasis on mactime and move to a more neutral approach, and perhaps change the default output mechanism to something like TLN.

With the move to a more neutral approach more logic will be moved into the output modules, meaning that it will be easier to make the description text (which every output module includes) can be more descriptive and does not need to repeat information that might be contained within the output itself (such as TLN which includes a source field, why repeat the source in the description field?)

-->