In diesem Beispiel enthält der obere Eintrag 12 Bytes an Daten, die entsprechend dem Inhalt des Feldes "Type" als Security Identifier (SID) interpretiert werden sollen. Der nachfolgende Eintrag, Nr. 13, soll hingegen als NullType interpretiert werden. Dieser Eintrag enthält auch keine weiteren Daten.

Genau das habe ich in unzähligen Protokolleinträgen gesehen. Eines Tages aber schickte mir Roberto De Vivo eine Protokolldatei, die meinen Parser abstürzen ließ. Mehrere SubstitutionArrays in seiner Datei sahen in etwa so aus, wie es die folgende Abbildung zeigt:

Die Länge ist eindeutig von 0 verschieden und der Tabelleneintrag enthält Daten. Ich konnte in der Datei weitere NullType-Objekte finden; manche von ihnen enthalten bis zu16 Bytes an Daten.

Zunächst vermutete ich, dass ich ein grundlegend falsches Verständnis des NullType-Objektes entwickelt hatte. Also wandelte ich mit Microsofts eigener Ereignisprotokollanzeige die betreffenden Datensätzte in XML um. In diesem Klartext konnte ich die fraglichen Daten jedoch nicht finden.

Weitere Untersuchungen sind notwendig, um die Ursache für diese Daten zu finden, und ob sie in einer forensischen Analyse von Wert sind.

Weitere Informationen gibt es in der Kursbeschreibung des Veranstalters Security Research.

Vielen Interessenten sind dann letztlich die Hürden dieser Angebote zu hoch: Vereinbarkeit mit der familiären und beruflichen Situation, Kosten, aktive Fremdsprachenkenntnisse... Das neue Angebot an der FH Albstadt-Sigmaringen mit seiner deutlich niedrigeren Einstiegsschwelle ist hier sicherlich eine interessante Alternative.

Der Master versteht sich als Aufbaustudium, ein erster berufsbefähigender Abschluss an einer wissenschaftlichen Hochschule, Fachhochschule, Berufsakademie oder ein vergleichbarer Abschluss an einer ausländischen Bildungseinrichtung ist also erforderlich. Bewerber auf einen der 30 Studienplätze müssen darüber hinaus mindestens ein Jahr Praxiserfahrung in einem einschlägigen Beruf nachweisen, zum Beispiel als Administrator oder in der IT-Sicherheit.

Wer über keinen Hochschulabschluss verfügt, soll trotzdem einzelne Module aus dem Studiengang belegen können. Ein Abschluss mit dem Master ist dann aber natürlich nicht möglich.

Das Studium findet überwiegend online statt. Präsenzveranstaltungen sollen vorwiegend an Wochenenden und an den kooperierenden Hochschulen, der FH Albstadt-Sigmaringen und den Universitäten Mannheim und Tübingen abgehalten werden. Das Angebot ist damit auch für Interessenten aus Österreich und der Schweiz attraktiv.

Die Unterrichtssprache ist Deutsch. Man wird aber sicherlich nicht umhin kommen, Fachtexte in englischer Sprache zu lesen. Wer seinen Bekanntheitsgrad steigern möchte, wird wahrscheinlich auch seine Master-Thesis in Englisch schreiben.

Das Studium besteht aus 17 Modulen, wobei je Semester drei Module angeboten werden sollen. Die Regelstudienzeit liegt also bei 6 Semestern. Das Studium kostet ca. 15.000 EUR. Vorkenntnisse können angerechnet werden und reduzieren Studiendauer und -Kosten.

Für weitere Auskünfte steht die Studienberatung unter digitale-forensik [at] hs-albsig [punkt] de oder Telefon +49 (0) 7571-732 94 40 zur Verfügung. Weitere Informationen sollen in Kürze auch unter www.digitaleforensik.com veröffentlicht werden.

Eine Aufnahme des Studiums ist jeweils zum Wintersemester möglich. Bewerbungen sind bis zum 15. Juli an die FH Albstadt-Sigmaringen zu richten.

Hexadezimalzahlen werden jetzt in Großbuchstaben ausgegeben und entsprechen insofern der Darstellung im Microsoft Event Viewer. Auch die Ausgabe der GUIDs habe ich angepasst.

Das Modul für den Type0x12 musste ich leider entfernen, da mir bislang nicht ausreichend Testdaten zur Überprüfung seiner korrekten Funktion zur Verfügung stehen.

Neu enthalten ist die Datei evtxsort.xsl, mit deren Hilfe sich Protokolldateien im XML-Format sortieren und normalisieren lassen.

Bereits in der Version 1.0.2 gab es folgende Änderungen (aber keine Ankündigung im deutschsprachigen Blog):

XML-Sonderzeichen werden nun richtig codiert. Dieser Fehler wurde von Kristinn Gudjonsson gemeldet.

NullType-Objekte können Daten enthalten. Roberto De Vivo hat mir eine Datei überlassen, aus der dieses seltsame Verhalten klar hervorgeht.

An der Programmarchitektur gab es einige Änderungen in der Behandlung der schließenden Tags von XML-Elementen. Von Bedeutung sind diese Änderungen allerdings nur für Programmierer, die auf der Bibliothek aufsetzen.

Ausserdem müssen Daten, die zu unterschiedlichen Fällen gehören, sauber getrennt werden. Dies ist einfach zu erreichen, indem man für jeden Fall einen eigenen, "sterilen", Datenträger verwendet.

WiebeTech Drive eRazer DRZR-2-VBND und Drive eRazer PRO löschen beide wie erwartet die sichtbaren Sektoren. Sektoren innerhalb der Host Protected Area (HPA) oder des Device Configuration Overlays (DCO) werden jedoch nicht immer gelöscht. Einzelheiten hierzu enthält der Testbericht. (PDF)

Voom HardCopy II unterstützt nicht das ATA SECURE WRITE Kommando. Die Testmedien wurden vollständig gelöscht. (PDF)

Die populäre Boot-CD Darik's Boot and Nuke 1.0.7 unterstützt ebenfalls nicht das SECURE WRITE Kommando, sondern überschreibt Sektoren per WRITE. Laut Untersuchungsbericht ist durch den Hersteller dokumentiert, dass hierbei HPA und DCO nicht angetastet werden; die entsprechenden Tests unterblieben deshalb. (PDF)

Der Editor unterstützt jetzt nativ UNICODE Strings (wstring bzw. wchar). Damit entfallen in meinen Template zahlreiche unelegante Workarounds.

Der Preprocessor funktioniert jetzt so, wie man es von der Programmiersprache C her kennt. Allerdings erfordert #include jetzt, dass das Argument in spitze Klammern oder Anführungszeichen eingeschlossen sein muss. Das ist noch nicht in allen meinen Templates der Fall, kann aber bei Bedarf schnell ausgebessert werden.

Das Update auf Version 3.1 ist bei Sweetscape erhältlich.

<?xml version="1.0" encoding="UTF-8" ?>

<xsl:stylesheet version="1.0" 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
  xmlns:evtx="http://schemas.microsoft.com/win/2004/08/events/event">
  
  <xsl:output method="xml" indent="yes" encoding="UTF-8"/>
  <xsl:strip-space elements="*" />
  
  <xsl:template match="Events">
    <xsl:copy>
      <xsl:apply-templates select="evtx:Event">
        <xsl:sort select="evtx:System/evtx:EventRecordID" 
          data-type="number" 
          order="ascending"/>
        </xsl:apply-templates>
      </xsl:copy>
  </xsl:template>
  
  <xsl:template match="*">
    <xsl:copy>
      <xsl:apply-templates/>
    </xsl:copy>
  </xsl:template>
</xsl:stylesheet>

Sie sollten diese Transformation mit jedem XSLT Prozessor wie Sablotron, Xalan oder SAXON ausführen können. Da ich bereits die Programmbibliothek libxslt installiert hatte, konnte ich deren XSLT Prozessor xsltproc verwenden:
xsltproc evtxsort.xsl mylog.xml > mylog.sorted.xml
Die Protokolldatei ist jetzt übersichtlich mit Einrückungen formatiert und ihre Datensätze sind nach der EventRecordID in aufsteigender Reihenfolge sortiert.

Sie können diese Transformation leicht an Ihre eigenen Vorstellungen anpassen, zum Beispiel die Einträge in Absteigender Reihenfolge sortieren, oder nach der EventID (der Art des Ereignisses) sortieren, oder einen zusammenfassenden Bericht erstellen, usw. Den Möglichkeiten sind kaum Grenzen gesetzt.

• Im Modul Node0x0d.pm habe ich einen zu restriktiven Test entfernt. Der Parser reagiert jetzt flexibler auf unbekannte Datentypen. Ich danke Rob Hulley und Adrian Forschner für die Meldung der Fehler und die Bereitstellung von Testdaten.
• Das Modul Evtx.pm aktualisiert jetzt selbsttätig einen Zeiger auf den aktuell verarbeiteten Block. Über die Methode get_current_chunk() kann der Wert jederzeit abgerufen werden.
• Die Module Evtx.pm und Chunk.pm werten zusätzliche Felder aus den Köpfen der Datei und der einzelnen Blöcke aus. Dank an Rob Hulley für einen Patch.
• Das Programm evtxinfo.pl zeigt diese Eigenschaften an. Außerdem nennt es jeweils den ersten und letzten Datensatz in einem Block, und zwar auf die vorliegende Datei und das gesamte Protokoll bezogen:

$ ./evtxinfo.pl sample4.evtx 
Information from file header:
Format version  : 3.1
Flags           : 0x00000000
         File is: CLEAN
     Log is full: NO
Current chunk   : 2 of 16
Next Record#    : 5276

Information from chunks:
Chunk file (first/last)     log (first/last)     
----- --------------------- ---------------------
    1       4681       4976       4902       5197
    2       4977       5054       5198       5275
    3        593        888        814       1109
    4        889       1135       1110       1356
    5       1136       1431       1357       1652
    6       1432       1727       1653       1948
    7       1728       2023       1949       2244
    8       2024       2312       2245       2533
    9       2313       2608       2534       2829
   10       2609       2904       2830       3125
   11       2905       3200       3126       3421
   12       3201       3496       3422       3717
   13       3497       3792       3718       4013
   14       3793       4088       4014       4309
   15       4089       4384       4310       4605
   16       4385       4680       4606       4901

25.02.2010: Bitte beachten Sie auch die Ankündigung der Version 1.0.3.

FTK3 zeigt Prozesse, Netzwerk-Sockets, in den Speicher geladene Programmbibliotheken (DLL) und Handles. Letztere lassen auf geöffnete Dateien ebenso schließen wie auf aktive Threads eines Prozesses.

Für einen ersten Test lasse ich FTK3 ein Speicherabbild untersuchen, in dem ein Netcat-Listener mit dem FUto-Rootkit versteckt wurde. Der Listener und sein Socket werden sofort erkannt. Ich vermisse allerdings einen Hinweis auf die manipulierten Datenstrukturen.

Leider steht FTK3 mit diesen Funktionen aber noch weit hinter dem Stand der Forschung zurück. Manipulationen an der Registry im Arbeitsspeicher, in den Kernel geladene Module und maliziöse Aktivitäten bleiben so meist unerkannt.

Interessant könnte eine Funktion zum Vergleich zweier Speicherabbilder sein. Genauere Tests werden zeigen, ob sich mit dieser Funktion Veränderungen am ausgeführten Kernel und der Systemkonfiguration erkennen lassen.

Ich freue mich über die Entscheidung von AccessData, Funktionen zur Speicheranalyse in die Oberfläche von FTK zu integrieren. Dies wird hoffentlich vielen neuen Anwendern einen Zugang zu den Methoden der Speicheranalyse erleichtern.

Auch die Verarbeitung von Partitionen der Dateisysteme JFS und UFS, sowie des Logical Volume Managers LVM2 wurde erweitert.

Schließlich kann jetzt auch der FTK Imager den Hauptspeicher des lokalen Computers sichern. Hierzu erstellt der FTK Imager zunächst eine Datei (ad_driver.sys) und lädt diese dann als Treiber \Device\addriver in den Betriebssystemkern. Hierzu benötigt man zumindest lokale Administratorrechte.

Es erscheint fraglich, ob ein komplexes Programm mit grafischer Benutzerschnittstelle wie der
FTK Imager zur Sicherung volatiler Daten geeignet ist. Auf einem Testsystem führte der
Start des FTK Imager zu Lesezugriffen auf 70 DLLs und zugehörige Dateien. Eine umfassendere Untersuchung der Ressourcennutzung ist hier angeraten.

Nach der ersten Ausführung des FTK Imagers ließ sich kein weiteres Speicherabbild mehr
erstellen. Fälschlicherweise behauptet der FTK Imager, dass mit diesem Betriebssystem kein
Speicherabbild erstellt werden könne. Beenden und Neustart des Imagers behebt das Problem.

Am Rande bemerkt empfehle ich auch nicht, dem Vorschlag des FTK Imagers zu folgen und binäre Daten in einer Datei mit der Extension ".txt" zu speichern.

Bei mh SERVICE (noch ohne Preisangabe), arina electronic (540 SFr für das Kit mit Kabeln und Netzteil) und Forensic Computers (329 USD für die Bridge, 399 USD für das Kit) listen den T9 bereits.

In der Detailansicht des Tastaturpuffers wird deutlich, dass für gewöhnliche Zeichen jeweils zwei Bytes abgelegt werden: der ASCII-Code des Zeichens und der beim Drücken der Taste erzeugte Scancode. Für das Zeichen "1" sind das zum Beispiel der ASCII-Wert 0x31 und der Scancode 0x02. Allerdings gibt es auch Ausnahmen. Für die Eingabetaste (Return) wird so nur der Scancode hinterlegt. Außerdem berücksichtigt dieser Mechanismus natürlich nicht das deutsche Tastaturlayout. Es ist die Aufgabe des Betriebssystems, die Zeichen entsprechend umzusetzen.

Leider enthalten längst nicht alle Abbilder die Speicherseite mit den Daten des BIOS. In Crash Dumps und mittels LiveKd erstellten Abbildern fehlt diese Speicherseite leider immer. Bei win32dd von Matthieu Suiche lässt sie sich mit der Option "-t 1" in das Abbild aufnehmen.

Für eigene Experimente stelle ich gerne das Template für den 010 Editor (Abbildung oben) und ein Plugin für das Speicheranalyse-Framework Volatility bereit.

Microsofts Debugger "WinDbg" ermöglicht auf sehr einfache Weise die Auflistung aller Objektklassen des Kernels. Hierzu muss man lediglich alle Elemente des Verzeichnisses \ObjectTypes abfragen:

kd> !object \ObjectTypes
Object: e1004ab0  Type: (812be278) Directory
    ObjectHeader: e1004a98 (old version)
    HandleCount: 0  PointerCount: 25
    Directory Object: e1004dc0  Name: ObjectTypes

    Hash Address  Type          Name
    ---- -------  ----          ----
     00  812be278 Type          Directory
     01  8128f5e0 Type          Mutant
         81292c68 Type          Thread
     03  81293c28 Type          FilterCommunicationPort
     05  812b5e70 Type          Controller
     07  8128eca0 Type          Profile
         8128f980 Type          Event
         812be448 Type          Type
     09  8128e560 Type          Section
         8128f7b0 Type          EventPair
         812be0a8 Type          SymbolicLink
     10  8128e730 Type          Desktop
     11  8128ee70 Type          Timer
     12  812b5730 Type          File
         8128e900 Type          WindowStation
     16  812b5ad0 Type          Driver
     18  812b0e70 Type          WmiGuid
         8128ead0 Type          KeyedEvent
     19  812b5ca0 Type          Device
         81292040 Type          Token
     20  81292398 Type          DebugObject
     21  812b5900 Type          IoCompletion
     22  81292e38 Type          Process
     24  812b5040 Type          Adapter
     26  8128b980 Type          Key
     28  81292a98 Type          Job
     31  812b68c0 Type          WaitablePort
         812b6a90 Type          Port
     32  8128f410 Type          Callback
     33  81293df8 Type          FilterConnectionPort
     34  8128e040 Type          Semaphore

Für jede Klasse nennt der Debugger die Basisadresse. Einzelheiten über die Klasse zeigen dann die Kommandos !object und "display type" (dt):

kd> !object 81292e38
Object: 81292e38  Type: (812be448) Type
    ObjectHeader: 81292e20 (old version)
    HandleCount: 0  PointerCount: 1
    Directory Object: e1004ab0  Name: Process

kd> dt _OBJECT_TYPE 81292e38 
ntdll!_OBJECT_TYPE
   +0x000 Mutex            : _ERESOURCE
   +0x038 TypeList         : _LIST_ENTRY [ 0x81292e70 - 0x81292e70 ]
   +0x040 Name             : _UNICODE_STRING "Process"
   +0x048 DefaultObject    : (null) 
   +0x04c Index            : 5
   +0x050 TotalNumberOfObjects : 0x15
   +0x054 TotalNumberOfHandles : 0x4e
   +0x058 HighWaterNumberOfObjects : 0x16
   +0x05c HighWaterNumberOfHandles : 0x52
   +0x060 TypeInfo         : _OBJECT_TYPE_INITIALIZER
   +0x0ac Key              : 0x636f7250
   +0x0b0 ObjectLocks      : [4] _ERESOURCE

WinObj

Möchten Sie sich einen Eindruck von der Objekthierarchie verschaffen und hierfür lieber eine graphische Oberfläche verwenden, dann ist
WinObj von Mark Russinovich möglicherweise das richtige Programm für Sie. Die Objektklassen sind wiederum im Verzeichnis "\ObjectTypes" zu finden.

Volatility

Letztlich habe ich mich entschlossen, selbst ein Plugin für das Speicheranalyse-Framework Volatility zu schreiben. Leider musste ich dazu auch einige Dateien des Frameworks ändern; das Plugin läuft also nicht mit der Standard-Distribution. Bitte entpacken Sie das Archiv im Basisverzeichnis von Volatility (aber vergessen Sie nicht, vorher eine Sicherungskopie zu erstellen!).

Das Plugin enthält ein paar kleine Tricks, um die Struktur _OBJECT_HEADER korrekt zu interpretieren und um physische Adressen in virtuelle Adressen des Kernels umzurechnen; letztgenannte Funktion ist deutlich vom Modul "strings" der Volatility-Distribution inspiriert.

Das Plugin gibt die folgenden Informationen aus:

• Phys.Addr - physische Adresse des ObjT Blocks im Pool
• Obj Type - Zeiger auf die Definition der Klasse "ObjectType". Der Wert ist abhängig vom jeweiligen System und kann sich auch nach einem Neustart ändern. Während einer laufenden Sitzung sollten aber alle Objekte der selben Klasse auf die selbe Definition verweisen.
• #Ptr - Anzahl der Zeiger auf das ObjectType Objekt
• #Hnd - Anzahl der Handles für das ObjectType Objekt
• Objects - aktuelle und maximale Anzahl von Objekten dieser Klasse
• Handles - aktuelle und maximale Anzahl von Handles auf Objekte dieser Klasse
• Pool alloc - Pool Tag und Pool Typ (auslagerbar/nicht auslagerbar) für Objekte dieser Klasse
• TypePtr - virtuelle Adresse des Kernels des ObjectType Objektes
• Name - Name der Klasse

Hier ist ein Beispiel für die Programmausgabe, das durch Ausführung des Plugins mit einem populären Speicherabbild aus dem NIST CFReDS Projekt erzeugt wurde:
python volatility objtypescan -f xp-laptop-2005-06-25.dd

Ich muss eingestehen, dass diese Informationen im Rahmen einer forensischen Untersuchung des Arbeitsspeichers eher nicht hilfreich sind. Ich verwende das Plugin eher als Hilfsmittel bei der Entwicklung anderer Tools. Die Maximalstände der Objekt- und Handle-Zahlen können allerdings erste Anhaltspunkte auf einen ungewöhnlichen Systemzustand geben.

Wie ein Bauplan beschreibt die Struktur _OBJECT_TYPE eine Klasse von Objekten:

kd> dt _OBJECT_TYPE
struct _OBJECT_TYPE, 12 elements, 0x190 bytes
   +0x000 Mutex            : _ERESOURCE
   +0x038 TypeList         : _LIST_ENTRY
   +0x040 Name             : _UNICODE_STRING
   +0x048 DefaultObject    : Ptr32 Void
   +0x04c Index            : Uint4B
   +0x050 TotalNumberOfObjects : Uint4B
   +0x054 TotalNumberOfHandles : Uint4B
   +0x058 HighWaterNumberOfObjects : Uint4B
   +0x05c HighWaterNumberOfHandles : Uint4B
   +0x060 TypeInfo         : _OBJECT_TYPE_INITIALIZER
   +0x0ac Key              : Uint4B
   +0x0b0 ObjectLocks      : [4] _ERESOURCE

_OBJECT_TYPE_INITIALIZER legt weitere Einzelheiten über die Klasse fest und enthält Details ihrer Implementierung, zum Beispiel Behandlungsroutinen für Standardereignisse:

kd> dt _OBJECT_TYPE_INITIALIZER
struct _OBJECT_TYPE_INITIALIZER, 20 elements, 0x4c bytes
   +0x000 Length           : Uint2B
   +0x002 UseDefaultObject : UChar
   +0x003 CaseInsensitive  : UChar
   +0x004 InvalidAttributes : Uint4B
   +0x008 GenericMapping   : _GENERIC_MAPPING
   +0x018 ValidAccessMask  : Uint4B
   +0x01c SecurityRequired : UChar
   +0x01d MaintainHandleCount : UChar
   +0x01e MaintainTypeList : UChar
   +0x020 PoolType         : _POOL_TYPE
   +0x024 DefaultPagedPoolCharge : Uint4B
   +0x028 DefaultNonPagedPoolCharge : Uint4B
   +0x02c DumpProcedure    : Ptr32     void 
   +0x030 OpenProcedure    : Ptr32     long 
   +0x034 CloseProcedure   : Ptr32     void 
   +0x038 DeleteProcedure  : Ptr32     void 
   +0x03c ParseProcedure   : Ptr32     long 
   +0x040 SecurityProcedure : Ptr32     long 
   +0x044 QueryNameProcedure : Ptr32     long 
   +0x048 OkayToCloseProcedure : Ptr32     unsigned char

Objekte werden gewöhnlich mit ihre Startadresse identifiziert. Als Beispiel soll der System-Prozess dienen. Er hat unter Windows XP immer die PID 4, so dass man ihn hierüber im Debugger auswählen kann:

kd> !process 4 0
Searching for Process with Cid == 4
PROCESS 812927c0  SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000
    DirBase: 00039000  ObjectTable: e1000a80  HandleCount: 216.
    Image: System

Seine Startadresse ist in deisem Beispiel 0x812927c0. Hierüber können wir jetzt die für alle Klassen gemeinsamen Daten des Objekts einsehen:

kd> !object 812927c0
Object: 812927c0  Type: (81292e38) Process
    ObjectHeader: 812927a8 (old version)
    HandleCount: 2  PointerCount: 57

Das Objekt gehört zur Klasse der Prozesse ("Process") und beginnt an der Adresse 0x812927c0. Beides war in diesem Fall natürlich bereits bekannt, aber dies ist die Bestätigung, dass wir die Daten richtig interpretieren. Wenn Sie die Ausgabe des Debuggers genau betrachten, dann werden Sie feststellen, dass der Objekt-Header an einer niedrigeren Adresse als das Objekt selbst steht, nämlich an 0x812927a8.

Andere Objekte enthalten möglicherweise auch andere Informationen, wie zum Beispiel einen Verweis auf ein Directory, welches dann wiederum auf das Objekt verweist, einen Namen und im Fall der hier dargestellten symbolischen Verknüpfung auch den Namen des Ziels der Verknüpfung:

Object: e13ad800  Type: (812be0a8) SymbolicLink
    ObjectHeader: e13ad7e8 (old version)
    HandleCount: 0  PointerCount: 1
    Directory Object: e10076a0  Name: ScsiPort1
    Target String is '\Device\Ide\IdePort1'

Der Name des Ziels gehört zu den spezifischen Informationen dieser Klasse, er wird deshalb im Rumpf des Objekts gespeichert. Der Name des Objektes selbst und das übergeordnete Verzeichnis sind jedoch Eigenschaften, die auch viele andere Klassen aufweisen. Deshalb werden diese Informationen in dem allgemeinen Objekt-Header und einer seiner Erweiterungen abgelegt.

Zurück zur Routine ObCreateObject. Bevor sie Speicher für das Objekt belegt, trägt sie einige Meta-Daten über das zu erstellende Objekt zusammen und ruft dazu ObpCaptureObjectCreateInformation auf. Diese wiederum ruft weitere Funktionen auf. SeCaptureSecurityDescriptor überprüft zunächst gründlich die Eingabedaten, bevor sie einen ausreichend großen Speicherbereich im Paged Pool des Kernels reserviert und mit der Marke "SeSc" versieht. Schließlich kopiert die Routine den Security Descriptor des neuen Objektes aus den ihr übergeben Objekt-Attributen in diesen Speicherbereich.

Die genannten Marken ("pool tags") wurden eingeführt, um den Speicherverbrauch von Routinen zu überwachen und Softwareentwickler auf mögliche Fehler hinzuweisen. Bei der forensischen Untersuchung eines Arbeitssppeicherabbildes sind diese Marken sehr hilfreich, um Objekte bestimmter Klassen zu lokalisieren.

Später ruft ObpCaptureObjectCreateInformation dann ObpCaptureObjectName auf, um in ähnlicher Weise den Namen des Objekts zu speichern. Den hierfür benötigten Speicherbereich reserviert eine weitere Routine, ObpAllocateObjectNameBuffer. Als Markierung vergibt sie die Zeichenfolge "ObNm". Neben dem Namen wird hier auch ein Verweis auf das übergeordnete Verzeichnis abgelegt.

Schließlich benötigen wir auch noch Speicher für den Rumpf des Objektes mit seinen klassen-spezifischen Daten. Hierum kümmert sich ObpAllocateObject. Die Funktion ermittelt den gewünschten Pool (einer wird stets im Speicher gehalten, Teile des anderen können bei Bedarf auf die Festplatte ausgelagert werden) aus der Struktur _OBJECT_TYPE. Auch das Pool Tag entnimmt sie dieser Struktur. Dabei setzt die Funktion das höchstwertigste Bit des Pool Tags, um eine Verwendung durch das Betriebssystem anzuzeigen. Der Microsoft Debugger markiert diese Speicherblöcke dann als geschützt ("protected"). Allerdings schützt dieses Vorgehen nur gegen eine versehentliche Verwendung eines Tags durch Software anderer Hersteller, zum Beispiel eines Gerätetreibers. Microsofts Dokumentation verlangt zwar, dass nur reine ASCII-Zeichen (7 Bit) in Tags verwendet werden. Allerdings kann man die entsprechende Routine ExAllocatePoolWithTag auch erfolgreich mit einem "unsauberen" Tag aufrufen. Entsprechende Beispiele findet man unter anderem im Windows XP SP2 MP Kernel, zum Beispiel in der Routine CmpAllocateKeyControlBlock.

Sobald ObCreateObject seine Arbeit beendet hat, enthält der Arbeitsspeicher die folgenden Strukturen (von niedrigeren zu höheren Adressen):

1. _POOL_HEADER, 0x08 Bytes
2. _OBJECT_QUOTA_CHARGES, 0x10 Bytes, optional
3. _OBJECT_HANDLE_DB, 0x08 Bytes, optional
4. _OBJECT_NAME, 0x10 Bytes, optional, verweist auf Speicherblock mit "ObNm" Pool Tag
5. _OBJECT_CREATOR_INFO, 0x10 Bytes, optional
6. _OBJECT_HEADER, 0x18 bytes, kann auf einen Speicherblock mit "SeSc" Pool Tag verweisen
7. Rumpf des Objekts, das Objekt wird durch diese Adresse identifiziert!