Forensic scientist’s blog

There is always a lot of conversation about when digital evidence is and is not admissible. Questions like “are proxy logs admissible?” and “what tools generate admissible evidence?” are focused on the concept of evidence admissibility. Some of the responses to these questions are correct, and some not really correct. I think [...]

By Andreas Schuster
Copyright © 2007 int for(ensic){blog;}. All rights reserved.

Parsing clear text can be a tedious piece of work, especially in the case of XML, which is known for its low entropy. Under the premise that XML messages are frequently re-read, the conversion of certain language elements into "tokens" can save a significant amount of computational power and also cuts down on the requirements for storage space.

Let's start with an example. We are going to tokenize the following piece of textual XML:

<EventID>1234</EventID>

This is translated into the following sequence of tokens:

1. The first angle bracket, which opens the start tag of our container element, becomes the #OpenStartElementTag# token.
2. The string "EventID" is left untouched for simplicity (in fact this is turned into an application token, so it can be reused later).
3. The next angle bracket closes the start tag of our element, so it becomes the #CloseStartElementTag# token.
4. Then the payload follows. If it were an XML stream then it would get tokenized, too.
5. Finally there's the end tag of our container element. It becomes the #EndElementTag# token. Notice that the tag's name is given by the sequence of #OpenStartElementTag# tokens, so there's no need to repeat it.

While these tokens describe elements, some others mark the beginning and the end of the binary XML stream, define attributes and their values or are simply placeholders for varying data. Here is the complete list:

So this is what the tokenized XML sequence will look like (again leaving out the encoding of the element's name and the contained data): 0x0f 0x01 EventID 0x02 1234 0x04 0x00

The high-nibble contains flags. So far I've seen only the value 0x40, which indicates that at least one attribute will follow the tag. This flag can frequently be seen in conjunction with the OpenStartElementTag token: 0x41.

As you can see there are some values missing in the table above. Most likely the "holes" are associated with some other XML language elements like character data (CDATA) sections, character and entity references and processing instructions. However, I yet have to see those in real-life log files.

submit by troym; comments by blogger jglI think this lab-on-a-chip idea has been around for a while. If I'm not mistaken, there are some ideas based on SNP analysis, but this seems like true STR work. No new databases needed.The goal of the new techn...

By Andreas Schuster
Copyright © 2007 int for(ensic){blog;}. All rights reserved.

Guidance Software and Access Data have updated some of their products during the last few days.

EnCase version 6.6 now supports Microsoft Office 2007 documents and the mbox format which is quite common among mail user agents.

Registry Viewer 1.5 by Access Data brings an enhanced report generator. Also support for Microsoft Vista registry files was improved.

By Andreas Schuster
Copyright © 2007 int for(ensic){blog;}. All rights reserved.

By far the largest part of an event record consists of a complex binary XML structure. I'm going to explain its internals in a series of postings. I'm starting with an overview of the XML schema.

Fortunately the XML structure is not completely undocumented. The Microsoft Developer Network provides an extensive documentation of the XML schema. The following figure shows the layout of an event log file:

<Events>
    <Event>
        <System> . . . </System>
        <EventData> . . . </EventData>
    </Event>
    <Event>
        <System> . . . </System>
        <UserData> . . . </UserData>
    </Event>
    <Event>
        ...
    </Event>
</Events>

The "Events" element spans the whole file. It acts as an container for the "Event" elements. Each of them provides the information about a single event. Every "Event" starts with a "System" element, which is filled in by the Windows event logging subsystem and contains a basic set of information like a timestamp, the Event ID number and the subsystem the event message originated from. The System element will play a key-role at a later time when it comes to the reconstruction of partial log files.

One out of the "EventData", "UserData", "BinaryEventData", "DebugData" or "ProcessingErrorData" structures may follow the "System" container. Of them "EventData" is the element most frequently used.

The textual representation of an event message is transformed into a binary form by a three step process:

1. XML language elements are tokenized
2. structure is separated from content through the substitution mechanism
3. templates are defined for repeated XML structures

This transformation helps to cut down on storage space and computing power. The details of all three steps will be covered in some later posts.

I had the pleasure of sitting down the other day with a technology law professor and we began discussing the issues surrounding memory capture. Not only the impact that a collection might have on a system and how a lawyer might attack that capture bei...

Abstract  In a series of experiments, we have tested the usefulness and limitations of the Guardian Bio-Threat Alert (BTA) system for
detection of staphylococcal enterotoxin B (SEB), botulinum toxins (BTXs) A and B, and ricin. In this report, the BTA system
has been further evaluated for toxin subtypes and the detection ability of manufactural lots of the BTA strips. The SEB strips
failed to detect staphylococcal enterotoxin A, C, and D; the BTX strips generally failed to detect BTXs C, D, E, and F, but
one lot showed positive results for BTXs C and D with very low sample values. Differences were observed in sample values at
1 μg/ml for all main toxins according to the different manufactural strip lots: 3.9-fold difference for SEB, 6.3-fold difference
for BTX A, 10.9-fold difference for BTX B, and 6.4-fold difference for ricin. The ricin strips showed high cross reactivity
toward RCA120. The BioWarfare Agent Detection Devices system showed much lower sensitivity than the BTA system for BTX and
ricin (detection limit: about 10 μg/ml).

Content TypeJournal Article

JournalForensic ToxicologyOnline ISSN 1860-8973Print ISSN 1860-8965 (Source: Forensic Toxicology)

Quite some time ago, Tableau stated that they'd be providing the ability to remove HPA and DCO's using their write blockers. Well, that day has come and gone. The Tableau Disk monitor tool provides this capability on windows. Cool. Now it seems acc...

I always wanted to do something fancy for a presentation when it came to describing how I found a scene. Sure, you can use visio, or autocad if you want to get super fancy, or even some real expensive modeling software for crime scenes. I decided to e...

By Andreas Schuster
Copyright © 2007 int for(ensic){blog;}. All rights reserved.

I'm excited to release the first version of a template for the 010 Editor which parses the outer structure of a Vista event log file. By "outer structure" I refer to the structures described earlier in this blog, from the file level down to the single record. However, the template can not yet decode the binary XML inside of an event record - and provably never will. For this task I will provide a more complex tool in a few weeks.

The template parses the following structures:

• File Header
• Chunk Header
• String Table
• Template Table
• Event Record

Here are a few screen shots of the output generated by the template. The first one shows the file header.

Here is the string table. The template tries to resolve the addresses stored within the hash buckets into actual strings for clarity.

This is what an event record looks like. Only the record number and a timestamp are given outside of the complex binary XML structure.