Blog: SANS Digital Forensics and Incident Response Blog

Blog: SANS Digital Forensics and Incident Response Blog

Local Shared Objects, aka Flash Cookies

The Adobe Flash player can store various information regarding user settings to "remember" things like the preferred volume a user likes in a video player, saved game settings, whether or not the user allows the flash player to connect to the web camera, etc. With the introduction of various ad blocking software and privacy settings in the browsers, web developers and advertisers have increasingly started to use these files to store other information as well (see the paper "Flash Cookies and Privacy"). These files are now more often used to store the same information as can be found inside traditional browser cookies. The notion of flash cookies has been discussed previously on SANS blogs, both in the Digital Forensics Blog by Chad Tilbury and in the IT Audit one by David Hoelzer.

Despite the privacy modes of many browsers today, where they do not store any type of browser history on the local disk, local shared objects or flash cookies can still be collected, stored and examined to determine the browser history. This fact has proven to be very valuable to investigators so far, however that might change in the next released version, 10.1, where private browsing will be implemented in the player according to Adobe.

According to Adobe: "Instead of saving local storage (local shared objects, or LSOs) on disk as it does during normal browsing, Flash Player stores LSOs in memory during private browsing". After this change Flash cookies will not be as affective in tracing user's web behavior as it used to be when users use privacy modes in their browsers. Despite that they are still very useful in tracking user behavior when privacy browsing is turned off, since Flash cookies are not cleared when users clear their browser cookies.

Few points about flash cookies:

  • The cookies can be viewed and managed with several tools, some of which are discused in this blog post.
  • Cookie information in a local shared object is not affected when the user clears his or hers cookies and it can be shared independent of the browser that is used.


The LSO is stored as a binary file in a network or big-endian style. The file is structured in three sections:
  • First 16 bytes are the file's header.
  • The objects name in ASCII
  • A series of data objects, that contain the actual values of the LSO


As noted above the first 16 bytes comprise the LSO header. It is structured in the following way:
  • Two bytes magic value (should be 0x00bf)
  • Four bytes length of LSO file excluding the length and magic value. So to get the correct total length this value should be increased by six.
  • Four bytes of magic value. This value should be the ASCII value of TCSO.
  • Six bytes of padding, should always equal 0x00 04 00 00 00 00.
An example header is:
<00bf> {0000 004b} [5443 534f] <0004 0000 0000>

If the header above is examined a bit more closely it can bee seen that the length of the LSO file is 0x00 00 00 4b = 75. If we add the length of the magic bytes in the beginning and the length of the int32 value that represent the length variable we get that the total length of the LSO file is 75+6 or 81 bytes (0x51).

Object Name

Following the header is the objects name. The structure is simple:
  • First two bytes represent the length of the name part
  • The name part in ASCII, the length according to previous value
  • Four bytes of pad (should equal 0x00 00 00 00 )
An example name part is the following:
(0014) <796f 7574 7562 652e 636f 6d2f 7365 7474 696e 6773> {0000 0000}

The length of the name is stored inside the parenthesis, 0x14 or 20 bytes. The next 20 bytes then represent the name part, in this case


After the name part ends a series of data start. The data is type is structured in the following way:
  • Two bytes represent the length of the name in ASCII
  • The name of the data/variable
  • The type of the data/variable
There are several different data types available, each one represented differently. The available data types are:
  • 0x00 — NUMBER. This is a double number so the next eight bytes represent the number.
  • 0x01 — BOOLEAN. One byte is read, either it is TRUE (value of 0x01) or FALSE (value of 0x00).
  • 0x02 — STRING. Contains two bytes representing the length of the string, followed by that amount of bytes in ASCII.
  • 0x03 — OBJECT. An object contains various data types wrapped inside a single data type. It has the same structure as other data types, that is it begins with two bytes representing the length of the name part of the variable, followed by the name in ASCII and then one byte representing the data type, which is then read the same way as any other data type. is read. The object then ends with the magic number of "0x00 00 09".
  • 0x05 — NULL. This is just a null object.
  • 0x06 — UNDEFINED. This is also a null object, since it has not been defined.
  • 0x08 — ARRAY. The array contains the exactly the same structure as an object, except that it starts with four bytes representing the number of elements stored inside the array. As with the objects it ends with the magic number of "0x00 00 09".
  • 0x0B — DATE. A date object is ten bytes, beginning with a double number contained in the first eight bytes followed by a signed short integer (two bytes) that represents the time offset in minutes from Epoch time. The double number represents an Epoch time in milliseconds.
  • 0x0D — NULL. As the name implies a null value.
  • 0x0F — XML. An XML structure begins with two bytes that should equal zero (0x00) followed by a string value (first two bytes represent the length of the XML, then an ASCII text containing the XML text).
  • 0x10 — CLASS. The class is very similar to that of an array or an object. The only difference is a class starts with a name of the class. The first two bytes represent the length of the name, followed by the name of the class in ASCII. Then as usual additional data types that are contained within the class, ending with a magic value of "0x00 00 09".
The tool log2timeline contains an input module that parses the structure of a .sol file and extracts all available timestamps to represent them in a super timeline. An example usage of the tool is:
log2timeline -f sol -z local
0|[LSO] LSO created -> File: and object name: soundData variable: {mute = (FALSE), volume = (40)} |20835066|0|0|0|0|1262603852|1262603852|1262603852|1262603852
log2timeline -f sol -z local
0|[LSO] lastVisit -> File: and object name: aa_user variable: {usr_rName = (XXXXX), mainList = (Bruno_DVD_UK => banner2 => count => 1, hasClicked => no, lastVisit => Mon Nov 23 2009 15:43:37 GMT, count => 1, hasClicked => no), usr_rgdt = (Mon Nov 23 2009 15:43:37 GMT), usr_kbsr = (0)} |20835107|0|0|0|0|1258991017|1258991017|1258991017|1258991017

Kristinn Gujnsson, GCFA #5028, is the author of log2timeline and several other scripts as well as being the team leader of information security at Skyggnir, forensic analyst, incident handler an a local mentor for SANS.


Posted February 17, 2010 at 9:55 PM | Permalink | Reply

Chad Tilbury

Nice work, Kristinn! The "Super Timeline" keeps getting better and better.

Posted March 12, 2010 at 7:08 PM | Permalink | Reply


Hey Admin! Thanks, Forever web pages..

Posted June 13, 2010 at 4:12 PM | Permalink | Reply


the format does not seem to apply to all lso objects.
I have one for example which is:
This does not seem to fit into the format you presented in your post!

Additionally the link to log2timeline seems to be dead.

Posted September 26, 2010 at 4:38 PM | Permalink | Reply


Is the description of the file format original research or is it based on someone else's work?

Posted September 28, 2010 at 2:47 PM | Permalink | Reply


Yes and no, that is it is partly built on someone's else work, and partly with original research.

Originally there was a <a href=";group_id=131628">small post on Sourceforge</a> describing the basic structure (an open-source tool that purpose was to parse Flash Cookies). The site is no longer available (through google cache or wayback machine). I also found some information on Adobe's site:
<a href="">here</a> and <a href="">here</a>.

Then to find more about the structure I found the open-source tool <a href="">Solve</a> by Darron Schall. I read part of the code to get a better understanding of the standard. So this is partly based on these documents, however none of these documents really described everything. I was hitting walls on many files, which required an original research into the issues. So yes and no, it is partly based on original research and partly based on work by others.

But after a previous comment here I found out the format is actually an Action Message Format encoded messages. That is we have a common header for localized stored objects (Flash cookies), but the actual payload is then coded according to a previously published Adobe standard, the Action Message Format. Most of the Flash cookies that I've come across are written using the AMF0, or the Action Message Format version 0, but some of them are using a more recent one, the AMF3, or version 3. For a full specification of the actual standard:

<a href="">AMF0</a>
<a href="">AMF3</a>

Thanks to jens for pointing this out to me. After reading this I found out that I had also missed few data types in my research, something I hadn't come across in the "wild". I'm also reading this paper to create a new parser capable of parsing both the AMF0 and AMF3.

Post a Comment

* Indicates a required field.