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 discussed 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.

Structure

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

Header

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 youtube.com/settings.

Data

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 youtube.com/soundData.sol0|[LSO] LSO created -> File: youtube.com/soundData.sol and object name: soundData variable: {mute = (FALSE), volume = (40)} |20835066|0|0|0|0|1262603852|1262603852|1262603852|1262603852log2timeline -f sol -z local www.site.com/aa_user.sol0|[LSO] lastVisit -> File: <a href="http://www.site.com/aa_user.sol" class="redactor-autoparser-object">www.site.com/aa_user.sol</a> 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 Guðjónsson, 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.