Afschermen van Bibliotheekinterfaces in Windows
tegen Aanvallen
Bert Abrath
Promotor: prof. dr. ir. Bjorn De Sutter
Begeleiders: ir. Stijn Volckaert, dr. Jonas Maebe, dr. Bart Coppens
Masterproef ingediend tot het behalen van de academische graad van
Master of Science in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Elektronica en Informatiesystemen
Voorzitter: prof. dr. ir. Jan Van Campenhout
Faculteit Ingenieurswetenschappen en Architectuur
Academiejaar 2013-2014
Voorwoord
In de eerste plaats wil ik mijn promotor, prof. dr. ir. Bjorn De Sutter, bedanken voor zijn ondersteuning en uitstekende feedback op deze scriptie. Ook wil ik mijn begeleiders, ir. Stijn Volckaert, dr. Bart Coppens en dr. Jonas Maebe, bedanken voor de hulp en inzicht die ze mij
hebben geboden. Specifiek bedank ik Stijn voor het delen van zijn kennis over de interne werking van Windows, en Bart en Jonas voor de hulp die zij geboden hebben toen ik worstelde
met problemen in Diablo. Naast mijn promotor en begeleiders zijn er nog twee mensen die op
een directe wijze een invloed hebben gehad op deze scriptie door ze uit vrije wil na te lezen:
Ronald en mijn zus, Margo.
Op indirecte wijze hebben er natuurlijk veel meer mensen bijgedragen aan deze scriptie. Zo
was er altijd een stimulerende werkomgeving met een goede sfeer en interessante verhalen
beschikbaar. Het afgelopen academiejaar heb ik dan ook veel bijgeleerd over AllyDBG, XOR
linked lists, GoT, en the A-Team, en heb ik een gezonde paranoia ten opzichte van willekeurige toetsaanslagen aangeleerd. Hiervoor dank ik Bart, Ronald, Stijn, Jens, Jonas en Sander.
Graag wil ik ook de mensen van de Werkgroep Ethical Hacking (van wie ik velen reeds vernoemd heb) bedanken voor het aanwakkeren van mijn interesse in beveiliging.
Een goede leefomgeving was natuurlijk ook belangrijk. Daarvoor dank ik mijn ouders, mijn
zussen, en mijn bijna 1-jarige neefje, Mathiz, dat altijd een interessante afleiding vormde en
er in zijn talloze pogingen nooit is in geslaagd mijn laptop, boeken of papieren, schade aan te
doen. Ook in Gent kon ik mij altijd thuis voelen. Ik wil mijn ganggenoten op kot danken voor
de vele jaren aan plezier. De gezelschapsspelletjes, andere spelletjes, zang- en danssessies,
kooksessies en veel meer zullen mij nog lang bijblijven. Naast mijn vele vrienden op kot wil
ik ook mijn andere vrienden doorheen de jaren bedanken voor de vele onvergetelijke verhalen
en het algemeen jolijt.
Bert Abrath
10 juni 2014
II
Toelating tot bruikleen
De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van
de scriptie te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen
van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.
The author gives permission to make this master dissertation available for consultation and
to copy parts of this master dissertation for personal use. In the case of any other use, the
limitations of the copyright have to be respected, in particular with regard to the obligation
to state expressly the source when quoting results from this master dissertation.
Bert Abrath
10 juni 2014
III
Afschermen van Bibliotheekinterfaces
in Windows tegen Aanvallen
door
Bert Abrath
Promotor: prof. dr. ir. Bjorn De Sutter
Begeleiders: ir. Stijn Volckaert, dr. Jonas Maebe, dr. Bart Coppens
Masterproef ingediend tot het behalen van de academische graad van
Master of Science in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Elektronica en Informatiesystemen
Voorzitter: prof. dr. ir. Jan Van Campenhout
Faculteit Ingenieurswetenschappen en Architectuur
Academiejaar 2013–2014
Samenvatting
Een dynamisch gelinkte applicatie bestaat uit een uitvoerbaar bestand en een aantal dynamische bibliotheken (die ook door andere applicaties gebruikt kunnen worden). Dynamisch
gelinkte applicaties hebben echter een beveiligingsprobleem: de interfaces tussen de verschillende componenten zijn perfecte aanknopingspunten voor reverse engineering. Om reverse
engineering tegen te gaan willen we het gebruik van deze interfaces afschermen. Het gebruik
van bibliotheekinterfaces door het uitvoerbaar bestand wordt in een eerste methode verborgen d.m.v. van encryptie.
In een tweede methode wordt de applicatie volledig statisch gelinkt, door alle gebruikte delen
uit de dynamische bibliotheken toe te voegen aan het uitvoerbaar bestand. Volledig statisch
gelinkte applicaties zijn echter niet compatibel met meerdere versies van Windows omdat
de interface die de Windows-kernel aanbiedt niet stabiel is. Daarom werd er in de tweede
methode voor gezorgd dat deze statisch gelinkte applicaties zichzelf kunnen aanpassen aan
de versie van Windows waarop ze uitgevoerd worden.
Beide methodes zijn als proof-of-concept ge¨ımplementeerd en kunnen nog niet gebruikt worden om realistische applicaties te herschrijven. Ze werden ge¨ımplementeerd op Diablo, een
raamwerk ontwikkeld binnen CSL om applicaties te herschrijven.
Trefwoorden: Beveiliging, bibliotheekinterfaces, reverse engineering, Windows, Diablo
IV
Protecting Library Interfaces in Windows
against Attacks
Bert Abrath
Supervisor(s): prof. dr. ir. Bjorn De Sutter, ir. Stijn Volckaert, dr. Jonas Maebe, dr. Bart Coppens
Abstract— Dynamically linked applications consist of an executable, and a number of dynamic libraries that can be used by
other executables. The benefits of this approach to creating applications notwithstanding, the interfaces between these components make the application more susceptible to reverse engineering. Consequently, from a security perspective it is preferable to
build statically linked applications. Fully statically linked applications however are not compatible with multiple versions of Windows. In this dissertation two methods are presented that protect the use of library interfaces from reverse engineering. These
methods have been implemented on the Diablo framework.
Keywords— security, protection, library interfaces, reverse engineering, Windows, Diablo
I. I NTRODUCTION
W
HEN a dynamic library is used in multiple applications, only one copy of the library has to be
present in memory and on disk. This can result in significant savings in memory usage and disk space. The
most important advantage however is in the area of
software engineering. Subdividing an application into
an executable and dynamic libraries makes it easier to
reuse existing functionality from other applications and
allows the components to be updated independently, because the interfaces between the components are fixed.
These fixed interfaces are good targets for reverse engineering however, making it preferable to build statically linked applications. In a fully statically linked application the – required parts of the – system libraries
are also a part of the executable and thus the application interacts directly with the kernel. Unfortunately,
the interface provided by the Windows kernel differs
between subsequent versions of Windows (and even between service packs). Consequently, applications use
the interface provided by the system libraries (the Windows API) in stead, as this interface is guaranteed to be
stable. As a result of the instability of the kernel interface, all Windows applications are dynamically linked
and thus more susceptible to reverse engineering.
II. R EVERSE ENGINEERING
Reverse engineering of software is the process of trying to understand an application at a higher level of
abstraction from lower level information such as executable code. There are numerous reasons for reverse
engineering an application, but here we will assume the
role of the reverse engineer being filled by an attacker
with malicious goals. In general there are two techniques a reverse engineer can use: static analysis and
dynamic analysis.
Static analysis is the process of analyzing an application without executing it. The executable file will be
analyzed by disassembling the binary code it contains,
constructing a control flow graph (CFG) and using this
information to gain a deeper understanding of the application. In analyzing dynamically linked application the
meta-information contained within the components can
especially be of use. Meta-information is what we call
the information present in these components that allow
them to dynamically link with – and use functionality
from – other components.
Dynamic analysis on the other hand involves executing the application and observing its dynamic behavior
in order to analyze it. A technique often used to analyze
dynamically linked applications is hooking. Dynamically linked applications depend on components being
found and used through their interfaces at runtime. A
potential attacker can thus build a fake component that
offers the same interface as a real component, and trick
the application into using his component in stead of the
real one. The fake component can then forward all function calls to the real component so the application continues executing normally and is unaware of any danger.
However, the attacker would then be able to intercept all
communication between the components, allowing him
to reverse engineer the application more effectively.
III. D IABLO
Diablo is a link-time binary rewriting framework developed within CSL. Applications can be build on top of
this framework, in our case we implemented two methods to protect a binary from reverse engineering on top
of it. Diablo works at linker-level, which means that it
takes the place of the linker in the build process. The
object files generated by the compiler are taken by Diablo which uses it to emulate the linker process. This
results in a binary that is the same as the original binary,
but some information that is used by the linker and unrecoverable from the resulting binary will be kept. This
information allows Diablo to build an accurate representation of the application upon which transformations
and analysis can be applied.
IV. E NCRYPTION OF META - INFORMATION
The first implemented method is aimed at obstructing the use of meta-information during static analysis.
As this information has to be present in the components in order to allow them dynamically link with other
components, we can’t simply remove it. In stead Diablo rewrites the executable so the meta-information
is still present, but in an encrypted form. On disk
the executable will seem to have no interface with any
other component, and there will be no meta-information
present to use in static analysis. At runtime the application will use the encrypted meta-information to adjust
itself and reconstruct the interfaces. As the interfaces
are still present at runtime the application will still be
vulnerable to dynamic analysis through hooking.
V. S TATIC LINKING
From a security eye-point it would be preferable
to make applications statically linked, as no metainformation would be present in the executable and
hooking would be impossible. Therefore a second
method was implemented that transforms a dynamically
linked application into a statically linked one by linking
the relevant portions of the dynamic libraries into the
executable. To overcome the instability of the Windows
kernel interface, the application adapts itself to the interface of the kernel on which it is running. This way
we can enjoy the security advantages of static linking
while retaining compatibility across different versions
of Windows.
VI. E VALUATION
The methods were implemented as proof-of-concept
and there are several limitations in the implementation
that hinder the rewriting of realistic applications. The
overhead introduced by the methods was evaluated and
reckoned to be unnoticeable except in extreme cases.
VII. C ONCLUSION
Dynamically linked applications are at an increased
risk to reverse engineering. In this dissertation two
methods to protect the use library interfaces between
dynamically linked components against revere engineering were proposed and implemented. These methods are only proof-of-concept and can’t yet be used to
rewrite applications of a realistic scale, but the overhead
they introduce is limited.
Inhoudsopgave
1 Inleiding
1.1
1
Probleemstelling
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
De dynamisch gelinkte softwarestapel . . . . . . . . . . . . . . . . . .
1
1.1.2
Voor- en nadelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.1.3
Statisch gelinkte softwarestapel . . . . . . . . . . . . . . . . . . . . .
3
1.2
Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2 Gerelateerd werk
2.1
2.2
2.3
2.4
2.5
6
Linken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.1
Het buildproces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.2
Objectbestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.3
Het linkerproces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.4
Statisch linken versus dynamisch linken . . . . . . . . . . . . . . . . .
9
Diablo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.1
Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.2
Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.3
Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Disassembleren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.1
Lineair disassembleren . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.2
Recursief disassembleren . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.3
IDA Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Reverse engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.1
Statische analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.2
Dynamische analyse . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.3
Bestaande oplossingen . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Het PE-formaat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.5.1
18
Dynamisch linken . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VII
2.6
2.7
2.5.2
Laden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.5.3
Rebasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
De Windows-systeembibliotheken . . . . . . . . . . . . . . . . . . . . . . . .
22
2.6.1
De verschillende API’s . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.6.2
Het API-set-schema . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
De kernel-interface in Windows . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.7.1
Systeemoproepen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.7.2
Syscall en sysenter . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.7.3
Instabiliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.7.4
Systeemoproepen en systeembibliotheken . . . . . . . . . . . . . . . .
28
2.7.5
WoW64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3 Encrypteren van meta-informatie
30
3.1
De algemene werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2
Het encrypteren van de meta-informatie . . . . . . . . . . . . . . . . . . . .
31
3.3
De glue code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.3.1
Aanpassingen in Diablo
. . . . . . . . . . . . . . . . . . . . . . . . .
33
3.3.2
De initialisatiefunctie . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.3.3
De laadfunctie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Beperkingen en mogelijke uitbreidingen . . . . . . . . . . . . . . . . . . . . .
37
3.4.1
De eenrichtingsfuncties . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4.2
Uitbreiden ondersteuning uitvoerbare bestanden . . . . . . . . . . . .
38
3.4.3
Dynamische aanvallen . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.4
4 Statisch linken
4.1
40
Toevoegen van DLL’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.1.1
Bepalen van de benodigde DLL’s . . . . . . . . . . . . . . . . . . . .
40
4.1.2
Reconstrueren van relocaties . . . . . . . . . . . . . . . . . . . . . . .
41
Disassembleren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.2.1
Implementatie van recursief disassembleren . . . . . . . . . . . . . . .
42
4.2.2
Sprongtabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.3
Statisch linken van dynamisch gelinkte bestanden . . . . . . . . . . . . . . .
43
4.4
Verwijderen van overbodige code en data . . . . . . . . . . . . . . . . . . . .
45
4.5
Initialisatieroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.6
Partieel statisch linken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.7
Beperkingen en mogelijke uitbreidingen . . . . . . . . . . . . . . . . . . . . .
47
4.7.1
47
4.2
Iteratief bepalen van benodigde DLL’s . . . . . . . . . . . . . . . . .
VIII
4.7.2
Opsplitsen data-secties . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.7.3
Onderscheid code en data . . . . . . . . . . . . . . . . . . . . . . . .
49
4.7.4
Initialisatie van de systeembibliotheken . . . . . . . . . . . . . . . . .
50
5 Compatibiliteit
51
5.1
Algemene werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.2
Glue code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.2.1
Aanpassingen in Diablo
. . . . . . . . . . . . . . . . . . . . . . . . .
51
5.2.2
Initialisatiefunctie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.2.3
Laadfunctie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.3
Windows 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.4
Beperkingen en mogelijk uitbreidingen . . . . . . . . . . . . . . . . . . . . .
54
5.4.1
Grafische systeemoproepen . . . . . . . . . . . . . . . . . . . . . . . .
54
5.4.2
Verandering structuur SCW . . . . . . . . . . . . . . . . . . . . . . .
54
5.4.3
Veranderingen van system services . . . . . . . . . . . . . . . . . . .
55
5.4.4
32-bits Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6 Implementatie
57
6.1
Inwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.2
Encrypteren van meta-informatie . . . . . . . . . . . . . . . . . . . . . . . .
57
6.3
Statisch linken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
6.4
Compatibiliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.5
SVN-statistieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
7 Evaluatie
61
7.1
Encrypteren van meta-informatie . . . . . . . . . . . . . . . . . . . . . . . .
61
7.2
Statisch linken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
7.2.1
Beperkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
7.2.2
Nutteloze code en data . . . . . . . . . . . . . . . . . . . . . . . . . .
62
7.2.3
Evaluatie overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
8 Conclusie
65
Bibliografie
66
IX
Hoofdstuk 1
Inleiding
In dit inleidend hoofdstuk wordt het probleem dat deze scriptie poogt op te lossen in algemene
bewoordingen uitgelegd. Er worden een aantal methodes voorgesteld om dit probleem op te
lossen, en er wordt een overzicht gegeven van de rest van de scriptie.
1.1
1.1.1
Probleemstelling
De dynamisch gelinkte softwarestapel
We beginnen met een algemeen beeld te schetsen van een dynamisch gelinkte softwarestapel
(zie Figuur 1.1). Onderaan vinden we de kernel, de belangrijkste component in de stack. De
kernel beheert de machine en de bronnen waarover de machine beschikt. Hij zorgt ervoor
dat meerdere applicaties tegelijkertijd op de machine kunnen uitvoeren zonder met elkaar te
interfereren. De kernel voert uit in kernel-modus, dit houdt in dat hij de totale controle over
de machine heeft. Applicaties voeren uit in user-modus, in deze modus zijn ze beperkt in
hun acties. Als een applicatie een geprivilegieerde actie wil ondernemen (invoer van een muis
krijgen, meer geheugenpagina’s laten alloceren, uitvoer naar een scherm printen etc.) moet
deze aan de kernel vragen om dit voor haar te doen d.m.v. systeemoproepen (system calls).
Net boven de kernel vinden we de systeembibliotheken. Deze maken – net als de kernel – deel
uit van het besturingssysteem en bieden functionaliteit aan die door de andere componenten
uit de softwarestapel gebruikt kunnen worden. Zo bieden ze een abstractie aan van de systeemoproepen, zodat deze op een gemakkelijkere manier door andere componenten gebruikt
kunnen worden. Naast deze abstractie bezitten ze ook eigen functionaliteit voor gebruik door
andere componenten.
Een applicatie (bv. een tekstverwerker, een kalender of een internet browser) bestaat uit
een uitvoerbaar bestand (“APP” op de figuur) en de dynamische bibliotheken waarvan dit
bestand afhankelijk is. Deze bibliotheken kunnen zowel systeembibliotheken als andere dynamische bibliotheken (ontwikkeld door de ontwikkelaar(s) van de applicatie of door een derde
partij, “LIB” op de figuur) zijn. Om hun functionaliteit ten dienste van andere componenten
te stellen bieden deze dynamische bibliotheken een interface aan die aan bepaalde conventies
voldoet en stabiel (t.t.z. niet veranderd) is.
Als laatste bespreken we de stuurprogramma’s (drivers). Een stuurprogramma stuurt een spe-
1
Figuur 1.1: Een algemeen beeld van een dynamisch gelinkte softwarestapel.
cifiek stuk hardware (zoals een muis, een toetsenbord of een beeldscherm) aan, en kan invoer
ophalen van dit stuk hardware of uitvoer ernaartoe sturen. Stuurprogramma’s kunnen zowel
in kernel- als in user-modus uitvoeren. Dit hangt af van de situatie en het besturingssysteem.
1.1.2
Voor- en nadelen
Een dynamisch gelinkte softwarestapel heeft een aantal voordelen. Doordat de interface tussen dynamisch gelinkte componenten vast staat, kan ´e´en van deze componenten gemakkelijk
vervangen worden door een andere component met dezelfde interface. Een dynamische bibliotheek kan bijvoorbeeld vervangen worden door een nieuwere versie van deze bibliotheek
waarin een aantal bugfixes zijn gebeurd, zonder dat de andere componenten die er afhankelijk
van zijn aangepast moeten worden. Doordat meerdere applicaties van eenzelfde dynamische
bibliotheek gebruik kunnen maken, wordt er ook uitgespaard op vlak van opslagruimte en
geheugengebruik. Een goed voorbeeld hiervan zijn de systeembibliotheken. Deze worden door
quasi elke applicatie op het systeem gebruikt, maar er is slechts ´e´en kopie van aanwezig in
het geheugen en op de harde schijf.
Het gebruik van dynamisch linken heeft echter ook een aantal nadelen. In deze scriptie zullen
we vooral aandacht besteden aan nadelen op vlak van beveiliging. Zo zijn de interfaces van
dynamische bibliotheken perfecte aanknopingspunten om aan reverse engineering te doen.
Deze aanknopingspunten zijn bij verschillende vormen van reverse engineering nuttig. We
onderscheiden twee vormen van reverse engineering: bij statische analyse wordt de applicatie geanalyseerd zonder ze (ook echt) uit te voeren, bij dynamische analyse wordt ze wel
uitgevoerd. Om het gebruik van elkaars interfaces toe te laten, bezitten de componenten
meta-informatie die gebruikt kan worden tijdens statische analyse.
Aangezien de interface van een component gekend is, kan een potenti¨ele aanvaller een valse
2
Figuur 1.2: Een voorbeeld van een hook.
Figuur 1.3: Een algemeen beeld van een statisch gelinkte softwarestapel.
component construeren die dezelfde interface aanbiedt als de echte component, en andere
componenten deze valse component laten gebruiken in plaats van de echte component. De
valse component kan alle functieoproepen doorsturen naar de echte component. Op deze
manier blijft de applicatie werken en lijkt het alsof er niets mis is, maar de aanvaller is nu
goed geplaatst om de communicatie tussen de twee echte componenten af te luisteren. Deze
techniek wordt vaak gebruikt bij dynamisch analyse. We noemen dit hooking. Een voorbeeld
hiervan valt te zien op Figuur 1.2. De hook – aanwezig tussen applicatie en bibliotheek – is
rood gekleurd.
1.1.3
Statisch gelinkte softwarestapel
Een mogelijke oplossing is om de applicatie volledig statisch te linken (zie Figuur 1.3). Alle
componenten waaruit de applicatie bestaat zijn nu samengevoegd tot ´e´en grote component.
Deze is enkel afhankelijk van de kernel zelf, en maakt geen gebruik van dynamische interfaces.
De beveiligingsnadelen van dynamisch linken zijn dus niet meer aanwezig.
Nu we een applicatie hebben die rechtstreeks afhankelijk is van de kernel, moeten we ons wel
3
Figuur 1.4: De instabiele kernel-interface op Windows.
vragen beginnen stellen over de stabiliteit van de interface tussen de applicatie en de kernel
(de kernel-interface). Een ontwikkelaar wil natuurlijk dat zijn applicatie op verschillende
versies van het besturingssysteem werkt. Als er een nieuwe versie van het besturingssysteem
uitkomt – met een nieuwe kernel – dan willen we dat de applicatie ook op deze nieuwe versie
werkt. Omdat een volledig statisch gelinkte applicatie rechtstreeks gebruik maakt van de
kernel-interface, willen we dus ook dat de kernel-interface achterwaarts-compatibel is. Op
Linux is dit het geval [1]. De kernel-interface kan wel uitbreiden, maar verandert voor de rest
niet.
Op Windows daarentegen is de kernel-interface niet stabiel (zie Figuur 1.4). Een volledig statisch gelinkte applicatie zal dus enkel werken op die versie van Windows waarvoor ze gelinkt
is. Applicaties die met meerdere versies van Windows compatibel willen zijn, moeten daarom
de systeembibliotheken gebruiken. Aangezien deze deel uitmaken van het besturingssysteem
zijn ze aangepast om gebruik te maken van de specifieke versie van de kernel-interface, en
de interface die de systeembibliotheken aanbieden is wel stabiel. Door het gebruik van bibliotheekinterfaces is de applicatie wel kwetsbaarder voor reverse engineering, wat we eigenlijk
wilden voorkomen.
1.2
Doelstellingen
In deze scriptie worden twee methodes gepresenteerd om uitvoerbare bestanden te herschrijven met als doel hun gebruik van bibliotheekinterfaces af te schermen tegen reverse engineering. De uitvoerbare bestanden die worden herschreven zijn meer bepaald 32-bits uitvoerbare
bestanden geschreven voor de x86-versie van Windows.
In de eerste methode wordt de meta-informatie ge¨encrypteerd. Het gebruik van bibliotheekinterfaces wordt zo verborgen en statische analyse wordt tegengegaan. Omdat de interfaces
tijdens de uitvoering nog steeds gebruikt worden, blijft de applicatie wel kwetsbaar voor hooking. In de tweede methode wordt de applicatie volledig statisch gelinkt. Dit gebeurt door
die delen van de dynamische bibliotheken die de applicatie gebruikt toe te voegen aan het
uitvoerbaar bestand. De bibliotheekinterfaces zijn dan verdwenen en het uitvoerbaar bestand
is enkel afhankelijk van de kernel. Om met de instabiliteit van de kernel-interface overweg
te kunnen, is de applicatie in staat zichzelf tijdens de uitvoering aan te passen aan de specifieke versie van de kernel waarop ze uitgevoerd wordt. Zo wordt ook dynamische analyse
tegengegaan.
4
Om uitvoerbare bestanden te herschrijven maken we gebruik van het Diablo-raamwerk. Dit
binnen CSL ontwikkelde raamwerk maakt het mogelijk om uitvoerbare bestanden op het
niveau van de linker te herschrijven. Bij de op Diablo ge¨ımplementeerde toepassingen beschikt
men normaal gezien over de broncode van de applicatie of over de objectbestanden waaruit de
applicatie is opgebouwd. We beschikken echter over broncode noch objectbestanden voor de
dynamische bibliotheken die we in de tweede methode willen toevoegen aan het uitvoerbaar
bestand. Deze fundamentele beperking leidt tot een aantal problemen in de implementatie.
1.3
Overzicht
In Hoofdstuk 2 wordt het gerelateerd werk besproken en wordt de probleemstelling uitgediept.
Vervolgens wordt in Hoofdstuk 3 de eerste eerder besproken methode voorgesteld. De tweede
methode wordt in twee hoofdstukken uitgelegd: Hoofdstuk 4 gaat over het eigenlijke statisch
linken, en Hoofdstuk 5 over het verzorgen van compatibiliteit met verschillende versies van
Windows. In Hoofdstuk 6 wordt het werk geleverd tijdens de implementatie besproken. De
twee methoden worden ge¨evalueerd in Hoofdstuk 7 en de scriptie wordt besloten met een
conclusie in Hoofdstuk 8.
5
Hoofdstuk 2
Gerelateerd werk
Dit hoofdstuk bestaat uit twee grote delen. In het eerste deel wordt gerelateerd werk besproken dat meer algemeen is, het tweede deel is daarentegen Windows-specifiek. Van een aantal
onderwerpen uit het eerste deel wordt toegelicht hoe deze op Windows werken, en er wordt
meer Windows-specifieke informatie gegeven waarvan gebruik gemaakt wordt in de rest van
de scriptie.
2.1
Linken
Aangezien we bestanden op linkerniveau gaan herschrijven, krijgen we te maken met een
proces waar in hedendaagse opleidingen snel aan voorbijgegaan wordt: dat van het linken. In
deze sectie bespreken we kort de manier waarop een uitvoerbaar bestand gegenereerd wordt
en de rol die de linker daarin speelt in Figuur 2.1. Het merendeel van de sectie is gebaseerd
op Levine’s boek ‘Linkers & Loaders’ [2].
2.1.1
Het buildproces
Het genereren van een uitvoerbaar bestand op basis van broncode in een bepaalde programmeertaal – het buildproces – gebeurt in een aantal stappen. Twee belangrijke stappen zijn die
van het compileren (uitgevoerd door de compiler) en het linken (uitgevoerd door de linker).
Als voorbeeld beschouwen we een op Windows uitvoerbaar bestand dat gegenereerd wordt
op basis van C-broncode (zie Figuur 2.1). Per bronbestand wordt er door de compiler een
objectbestand gegenereerd. Dit bestand bevat de instructies en plaats voor de – al dan niet
ge¨ınitialiseerde – statische variabelen.
De objectbestanden die de compiler gegenereerd heeft dienen vervolgens als invoer voor
de linker, die deze combineert tot het uitvoerbaar bestand. Niet enkel de net gegenereerde
objectbestanden dienen als invoer. Er wordt namelijk ook gebruik gemaakt van bibliotheken.
Een bibliotheek is een verzameling reeds gecompileerde code die hergebruikt kan worden door
meerdere applicaties. Ons voorbeeld maakt – zoals quasi alle applicaties geschreven in C –
gebruik van de C-standaardbibliotheek, waarin men de functies printf, malloc, abs etc. vindt.
6
Figuur 2.1: Een compiler zet bronbestanden om in objectbestanden, die de linker combineert
tot een uitvoerbaar bestand.
2.1.2
Objectbestanden
Een objectbestand bestaat uit headers (die de rest van het bestand beschrijven), een aantal
secties met verschillende eigenschappen, en informatie die enkel gebruikt wordt bij het linken.
Er bestaan verschillende secties:
• de .text-sectie: in deze sectie vinden we de uitvoerbare code.
• de .data-sectie: deze sectie bevat data die zowel leesbaar als schrijfbaar is.
• de .rdata-sectie: de data in deze sectie is leesbaar, maar niet schrijfbaar. De inhoud van
de sectie blijft dus hetzelfde doorheen de hele uitvoering van de applicatie.
• de .bss-sectie: in tegenstelling tot andere secties is deze sectie niet echt aanwezig in
het bestand. De sectie bevat data waarvan de waarde op nul ge¨ınitialiseerd wordt en
is zowel leesbaar als schrijfbaar. Aangezien geweten is dat de sectie enkel nullen bevat,
houden we in de headers enkel de grootte ervan bij zonder de sectie zelf te includeren in
het bestand. Als een uitvoerbaar bestand met een .bss-sectie in het geheugen geladen
wordt zal er een sectie met de juiste grootte gecre¨eerd en op nul ge¨ınitialiseerd worden.
Alle secties die enkel doorgaans enkel data bevat (zoals .data, .rdata en .bss) noemen we
data-secties.
Een objectbestand bevat twee soorten informatie waarvan de linker gebruik maakt: symboolinformatie en relocatie-informatie. Een symbool is de naam van een functie of een variabele
7
Figuur 2.2: Een voorbeeld van een aantal relocaties.
die gedefinieerd wordt in een objectbestand. Een objectbestand bevat enerzijds informatie
over symbolen die in het objectbestand zelf gedefinieerd worden en anderzijds over symbolen die ge¨ımporteerd moeten worden uit andere objectbestanden (of die gedefinieerd worden
door de linker). Stel bijvoorbeeld dat de functie foo ge¨ımplementeerd wordt in foo.obj, en
aangeroepen wordt vanuit main.obj. Dan is foo een symbool dat gedefinieerd is in foo.obj,
en ge¨ımporteerd wordt in main.obj.
Binnenin een objectbestand zijn er plaatsen in de ene sectie die plaatsen in een andere sectie refereren. Als we bijvoorbeeld een functie hebben die een statisch gealloceerde variabele
incrementeert, leidt dit tot een instructie in de .text-sectie waarvan het operand een adres
in de .data-sectie is. Deze referenties worden in het uiteindelijke uitvoerbaar bestand voorgesteld als adressen. Op het moment dat de compiler het objectbestand genereert kunnen deze
adressen nog niet berekend worden. Dit gebeurt later door de linker in een proces genaamd
relocatie. Om deze adressen te kunnen berekenen wordt er relocatie-informatie bijgehouden,
deze bestaat uit een lijst van relocaties die moeten gebeuren. Het voorbeeld met de statisch
gealloceerde variabele leidt tot een relocatie die voorgesteld wordt op Figuur 2.2. Het adres
gebruikt door de inc-instructie is nog niet berekend en staat in het rood. Er wijst wel een
relocatie van deze operand naar de offset (offsetNaar1 ) binnen de .data-sectie waarop de
variabele zich bevindt. Zodra het uiteindelijke adres van de .data-sectie gekend is, wordt
het adres van de variabele berekend en weggeschreven op de positie van de operand. In de
relocatie-informatie wordt de positie van deze operand ook voorgesteld als een offset binnen
een sectie. Relocaties komen niet enkel voor tussen secties, een relocatie kan ook wijzen van
een plaats binnen een sectie naar een symbool. Het adres van het symbool – dat gevonden
moet worden door de linker – wordt dan weggeschreven op de plaats binnen de sectie. Op
Figuur 2.2 wijst de onderste relocatie naar een symbool.
2.1.3
Het linkerproces
In deze sectie wordt het linkerproces voorgesteld zoals het verloopt indien er statisch gelinkt
wordt. Tijdens het linkerproces worden alle objectbestanden samengevoegd tot een uitvoerbaar bestand, en worden de uiteindelijke adressen berekend. De eerste fase in dit proces is die
van symboolresolutie. Voor alle in objectbestanden ge¨ımporteerde symbolen moeten er definities gevonden worden. Een definitie specificeert een bepaalde offset binnen een bepaalde
sectie waarop een symbool gevonden kan worden. Indien een symbool door een bepaald objectbestand ge¨ımporteerd wordt maar nergens – of meerdere keren – gedefinieerd wordt, leidt
8
dit tot een linkerfout.
Alle gelijknamige secties uit de objectbestanden worden samengevoegd zodat er nog maar
´e´en .text-sectie, ´e´en .data-sectie etc. overblijft. Naast het uitvoerbaar bestand kan de linker
ook nog de zogenaamde linker map genereren. Hierin valt onder meer te vinden op welk adres
binnen de resulterende secties de oorspronkelijke secties (of subsecties) uit de objectbestanden
geplaatst zijn.
Daarna worden de eigenlijke relocaties uitgevoerd. De adressen worden berekend en weggeschreven, ook voor ge¨ımporteerde symbolen. Tijdens de symboolresolutie zijn alle relocaties
die naar een symbool wijzen namelijk al vertaald naar relocaties die naar een offset binnen
een sectie wijzen.
Het eindresultaat van dit proces is een uitvoerbaar bestand waarin alle symbooladressen
berekend zijn en waaruit de symboolinformatie dus kan verwijderd worden. Zoals gezegd is
dit alles enkel van toepassing indien we volledig statisch linken. Indien we dynamisch linken
is het namelijk nog mogelijk om tijdens de uitvoering symbolen op te zoeken.
2.1.4
Statisch linken versus dynamisch linken
De procedure die in Sectie 2.1.3 werd besproken is die van het statisch linken. Een volledig
statisch gelinkt uitvoerbaar bestand moet geen symboolinformatie meer bevatten omdat alle
symbolen reeds gevonden zijn, en het is niet afhankelijk van andere componenten (uitgezonderd de kernel). Het uitvoerbaar bestand kan echter ook dynamisch gelinkt zijn. In dit geval
bevat het wel nog symboolinformatie – de zogeheten meta-informatie – die het de applicatie
mogelijk maakt om tijdens de uitvoering (of “dynamisch”) symbolen op te zoeken in dynamische bibliotheken en deze te gebruiken. Deze dynamische bibliotheken worden bij het
opstarten van de applicatie in de adresruimte van de applicatie geladen. Als er andere applicaties opstarten die gebruik maken van eenzelfde bibliotheek wordt deze in alle gerelateerde
adresruimtes geladen op copy-on-write pagina’s. Dit wil zeggen dat alle processen eenzelfde
fysieke geheugenpagina delen, tenzij ze er zelf aanpassingen op aanbrengen. Zodra een proces
een copy-on-write pagina beschrijft, wordt deze gekopieerd naar een pagina die enkel door
dat specifieke proces gebruikt wordt.
Het gebruik van dynamisch linken heeft zijn voordelen. Het voornaamste voordeel is op
vlak van software engineering. Delen van een applicatie kunnen op een gemakkelijke wijze
hergebruikt worden in een andere applicatie (zelfs delen die door iemand anders ontwikkeld
zijn). Als meerdere applicaties eenzelfde dynamisch bibliotheek gebruiken is er maar ´e´en
fysieke kopie van die bibliotheek aanwezig op de harde schijf, en bij het uitvoeren meestal
maar ´e´en kopie in het fysieke geheugen. Het eigenlijke uitvoerbaar bestand is ook kleiner
aangezien er meer code en data aanwezig is in dynamische bibliotheken, en deze bibliotheken
kunnen ge¨
updatet worden zonder dat er iets moet veranderen aan het uitvoerbaar bestand.
Er zijn echter ook nadelen aan het gebruik van dynamisch linken verbonden. Dynamische
gelinkte applicaties presteren iets slechter vanwege indirectie (voor het specifieke geval van
9
Windows wordt dit uitgelegd in Sectie 2.5.2, en verschillende versies van eenzelfde dynamische
bibliotheek kunnen leiden tot compatibiliteitsproblemen (e.g. DLL hell [3]). Daarnaast is er nu
meta-informatie aanwezig in de bestanden die gebruikt kan worden bij statische analyse van
de applicatie. Bovendien is het vertrouwen op componenten die dynamisch gevonden worden
gevaarlijk. Dit maakt namelijk een nieuwe klasse aan aanvallen mogelijk die gebruikt kunnen
worden bij dynamische analyse. Voor deze scriptie zijn vooral deze twee laatste nadelen van
belang.
2.2
Diablo
De linker is de eerste component in het buildproces van een applicatie die het overzicht
heeft over het volledige uitvoerbare bestand. In het bestand dat de linker produceert is de
relocatie-informatie die in het linkerproces gebruikt wordt niet meer aanwezig. De symboolinformatie kan die niet met dynamisch symbolen te maken heeft kan ook verwijderd zijn. Als
we uitvoerbare bestanden willen herschrijven door enkel gebruik te maken van de uitvoerbare
bestanden zelf, beschikken we dus over minder informatie. Bijgevolg is een tool die op linkerniveau werkt in de beste positie om over de grenzen van de oorspronkelijke objectbestanden
heen optimalisaties toe te passen en uitvoerbare bestanden te herschrijven. Een voorbeeld
hiervan is het Diablo-raamwerk, dat in deze scriptie gebruikt wordt [4].
2.2.1
Werking
De eerste stap die Diablo onderneemt bij het herschrijven van een uitvoerbaar bestand is
het linkerproces emuleren. Hiervoor wordt gebruik gemaakt van de objectbestanden die als
invoer dienden bij het oorspronkelijke linkerproces en van de linker map die bij dit proces
gegenereerd werd (zie Sectie 2.1.3). Tijdens het emuleren wordt er een parent-object (dat
een voorstelling van het uitvoerbaar bestand vormt) opgebouwd uit de objectbestanden. Dit
parent-object bestaat uit parent-secties die opgebouwd zijn uit secties afkomstig van de verschillende objectbestanden (zogenaamde subsecties). De symbool- en relocatie-informatie uit
de objectbestanden wordt gebruikt om de adressen binnen het parent-object te berekenen, en
vervolgens door Diablo in datastructuren bijgehouden. Uiteindelijk wordt er gecontroleerd of
het resultaat van het ge¨emuleerde linkerproces overeenkomt met het te herschrijven bestand.
Vervolgens worden alle .text-secties in het parent-object gedisassembleerd en wordt er een
controleverloopgraaf opgesteld op basis van de gedisassembleerde instructies en de relocatieinformatie. Deze controleverloopgraaf is een gerichte graaf met knopen en pijlen. Aan de hand
van de relocatie-informatie wordt er ook een gerichte graaf opgebouwd die de afhankelijkheden tussen de verschillende data-secties voorstelt. Deze twee grafen samen noemen we de
aangevulde controleverloopgraaf of ACVG, die als een representatie van de applicatie dient.
Het is deze representatie die we zullen aanpassen om de applicatie te herschrijven. Diablo
zal dan op basis van de aangepaste representatie een nieuw, herschreven uitvoerbaar bestand
genereren.
De controleverloopgraaf opgebouwd door Diablo bevat als knopen basisblokken of BBL’s.
Een BBL is een blok van instructies die altijd samen uitgevoerd worden. Dit impliceert dat
10
Figuur 2.3: Een voorbeeld van een deel van een controleverloopgraaf.
enkel de eerste instructie in het blok het doel kan zijn van een controleverloopinstructie, en
dat enkel de laatste instructie in het blok een controleverloopinstructie kan zijn. Het BBL
dat het beginpunt van de applicatie vormt, wordt de beginknoop van de controleverloopgraaf
genoemd.
De pijlen in de graaf stellen het controleverloop voor. Zo zijn er sprong-pijlen die een sprong
van ´e´en BBL naar een andere BBL voorstellen. Een conditionele sprong wordt voorgesteld
door twee pijlen die vertrekken vanuit het BBL: een sprong-pijl voor het geval waarin de
sprong genomen wordt en een doorval-pijl voor het geval waarin de sprong niet genomen
wordt (het doorvalpad). Een functieoproep wordt voorgesteld door een call-pijl die van een
BBL met als laatste instructie een functieoproep naar het eerste BBL van de opgeroepen
functie gaat. Deze call-pijl heeft een corresponderende return-pijl die van het laatste BBL
van de functie naar het BBL volgende op die met de functieoproep gaat. Figuur 2.3 toont
een deel van een controleverloopgraaf. De groene pijlen zijn sprong-pijlen, de zwarte zijn
doorval-pijlen en de rode is een call-pijl.
Indien het doel van een controleverloopinstructie een register of een adres opgeslagen in het
geheugen is, dan spreken we over indirect controleverloop. Het uiteindelijke doeladres (en
bijhorende BBL) kan in dat geval niet altijd door Diablo bepaald worden. Dit wordt binnen
de controleverloopgraaf gemodelleerd d.m.v. een helleknoop. In deze knoop komen pijlen
toe vanuit alle BBL’s die resulteren in indirect controleverloop, en er gaan pijlen vanuit de
helleknoop naar alle BBL’s die een doel kunnen zijn van indirect controleverloop.
11
Eens de controleverloopgraaf opgebouwd is, wordt deze onderverdeeld in functies. Deze functies zijn groepen van BBL’s die ruwweg overeenkomen met de oorspronkelijke procedures in
de applicaties. Het onderverdelen in functies gebeurt door de controleverloopgraaf te overlopen (beginnende vanaf het beginpunt van de applicatie) en te zoeken naar call-pijlen.
2.2.2
Structuur
Diablo kan bestanden herschrijven die bedoeld zijn voor verschillende platformen en verschillende architecturen. Om dit mogelijk te maken bestaat het raamwerk uit een algemeen
gedeelte en een aantal platform- en architectuur-specifieke backends. Er bestaan verschillende
formaten voor uitvoerbare bestanden en objectbestanden, zoals het PE-formaat gebruikt op
Windows en het ELF-formaat gebruikt op Linux. Voor het inlezen van deze bestanden bezit
Diablo dus een PE-backend en een ELF-backend. Het emuleren van het linkerproces gebeurt
gebeurt bijvoorbeeld grotendeels in algemene code, maar om de .text-secties te disassembleren wordt er gebruik gemaakt van architectuur-specifieke backends. In deze scriptie wordt er
gebruik gemaakt van de i386 -backend (i386 is een andere naam voor x86).
Op dit raamwerk kunnen er applicaties gebouwd worden. Een voorstelling van zo’n Diablogebaseerde applicatie met het Diablo-raamwerk en zijn backends valt te zien op Figuur 2.4.
In het kader van deze masterproef heb ik een Diablo-gebaseerde applicatie geschreven.
2.2.3
Toepassingen
Diablo is doorheen de jaren voor veel verschillende toepassingen gebruikt, enkele hiervan
worden kort besproken.
Een eerste toepassing is compactie na het linken, waarbij Diablo gebruikt wordt om uitvoerbare bestanden te verkleinen [4][5][6]. Voor een doorsnee uitvoerbaar bestand zijn er in
de door Diablo opgebouwde ACVG knopen aanwezig die niet bereikbaar zijn vanaf de beginknoop. Elke onbereikbare knoop die een BBL is, bestaat uit instructies die niet bereikbaar
zijn vanuit het beginpunt en dus nooit uitgevoerd kunnen worden. Elke onbereikbare knoop
die een subsectie is, bestaat uit data die tijdens de uitvoering van de applicatie onmogelijk gebruikt kan worden. Onbereikbare knopen kunnen dus zonder problemen door Diablo
verwijderd worden om een kleiner uitvoerbaar bestand te bekomen. We noemen dit het elimineren van onbereikbare code en data. Er zijn in Diablo nog verdere optimalisaties en analyses
ge¨ımplementeerd die het mogelijk maken een uitvoerbaar bestand nog meer te verkleinen,
maar die zijn voor deze scriptie niet van belang [5][6].
Uitvoerbare bestanden kunnen ook herschreven worden met het oog op beveiliging. Zo is
Diablo gebruikt om herschreven uitvoerbare bestanden te genereren die zichzelf dynamisch
aanpassen [7]. Deze techniek zorgt ervoor dat een bepaald geheugenbereik meerdere, verschillende code-sequenties bevat doorheen de uitvoering van de applicatie. Op deze manier wordt
het moeilijker voor een potenti¨ele aanvaller om aan reverse engineering te doen. Diablo wordt
ook gebruikt om aan code-diversificatie te doen [8]. Het doel is hier om patch-gebaseerde exploits tegen te gaan door – op basis van eenzelfde broncode – uitvoerbare bestanden te
genereren die op vlak van uitvoerbare code sterk verschillen. Om dit bereiken wordt on12
Figuur 2.4: De structuur van een Diablo-gebaseerde applicatie[4].
der meer de controleverloopgraaf sterk aangepast en wordt direct controleverloop verborgen
achter indirect controleverloop.
2.3
Disassembleren
Als we willen weten welke instructies er in een .text-sectie zitten moeten we deze disassembleren. Dit kan op twee manieren: lineair of recursief, met elk zijn eigen voor- en nadelen [9].
2.3.1
Lineair disassembleren
Een eerste manier om een .text-sectie te disassembleren is lineair disassembleren. Dit houdt
in dat er, vanaf het beginadres van de sectie, instructie per instructie gedisassembleerd wordt.
Op het beginadres van de sectie disassembleren we de eerste instructie en determineren zijn
lengte. Zo krijgen we het adres van de volgende instructie, die op zijn beurt disassembleren
enzoverder. De aard van de gedisassembleerde instructies is hierbij niet van belang.
13
Figuur 2.5: Een voorbeeld van het lineair disassembleren van een .text-sectie waarin data
aanwezig is.
Deze manier van disassembleren is gemakkelijk te implementeren, maar komt in de problemen
indien er data aanwezig is in de .text-sectie. In Figuur 2.5 bijvoorbeeld wordt de functie
GeefVijfTerug ge¨exporteerd. Deze maakt gebruik van de interne functie GeefEenterug en
de gebruikte variabelen zijn als data tussen de twee functies in opgeslagen. Indien we hier
vanaf het begin van de sectie lineair beginnen te disassembleren, dan worden de data bytes als
instructiebytes aanzien en tot valse instructies gedisassembleerd. Dit zou geen groot probleem
vormen in het geval van een RISC-instructieset, waar alle instructies dezelfde lengte hebben.
De x86-architectuur heeft echter een CISC-instructieset waarbij instructies een verschillende
lengte hebben. Bij het disassembleren van de databytes kan het gebeuren dat er een instructie
gedisassembleerd wordt die zowel data- als echte instructiebytes bevat, met als gevolg dat de
daaropvolgende gedisassembleerde instructies niet overeenkomen met de eigenlijke instructies.
2.3.2
Recursief disassembleren
Bij recursief disassembleren beginnen we met disassembleren op adressen waarvan we zeker
weten dat er instructies op te vinden zijn, zoals het beginadres van een applicatie, het adres
van de initialisatieroutine van een bibliotheek, en de adressen van ge¨exporteerde functies.
Van op elk van deze adressen beginnen we met instructies lineair te disassembleren, met dat
verschil dat in het geval dat de net gedisassembleerde instructie een controleverloopinstructie
is, we het controleverloop zullen volgen. Op deze manier proberen we te voorkomen dat data
verkeerdelijk gedisassembleerd wordt tot instructies. In Figuur 2.6 zien we een voorbeeld van
recursief disassembleren. De enige ge¨exporteerde functie is GeefVijfTerug. Er wordt begonnen
met disassembleren op het adres van deze functie, het controleverloop wordt gevolgd, alle
instructies worden gedisassembleerd en de data niet.
Indien de uitvoerbare code geobfusceerd is, is het wel mogelijk dat er data verkeerdelijk gedisassembleerd wordt [10]. Er kunnen bijvoorbeeld conditionele sprongen ge¨ıntroduceerd worden
die eigenlijk altijd genomen of nooit genomen worden. Als het beginadres van het pad dat
eigenlijk nooit genomen wordt data bevat, blijft de applicatie correct uitvoeren maar wordt er
14
Figuur 2.6: Een voorbeeld van het recursief disassembleren van een .text-sectie, met stappen
genummerd in volgorde.
verkeerdelijk data gedisassembleerd. Net zoals bij het opstellen van een controleverloopgraaf
vormt indirect controleverloop een struikelblok voor het recursief disassembleren. Indien we
bijvoorbeeld een ‘call eax’-instructie tegenkomen dan kan het controleverloop meestal niet
gevolgd worden (tenzij eventueel via constantenpropagatie). Van alle adressen waarop er geen
instructies gedisassembleerd zijn, wordt er verwacht dat deze data bevatten. Vanwege indirect
controleverloop worden er bij recursief disassembleren dus veel instructies niet gedisassembleerd en beschouwd als data. In principe zou een methode die voor alle mogelijke .text-secties
de aanwezige code en data perfect kan onderscheiden ook in staat zijn het stopprobleem op
te lossen. Bijgevolg kunnen we onmogelijk zo’n methode construeren [11].
2.3.3
IDA Pro
IDA Pro (Interactive Disassembler Professional ) is een populaire, recursieve disassembler die
m.b.v. een aantal bijkomende technieken een zeer goede nauwkeurigheid in het onderscheiden
van code en data haalt [12]. E´en van deze technieken is Fast Library Identification and
Recognition Technology of FLIRT. Dit houdt in dat statisch gelinkte code die afkomstig is
uit bibliotheken gemakkelijk herkend wordt a.d.h.v. een databank met signaturen van gekende
functies. Het herkennen van deze reeds gekende functies beperkt het werk dat IDA levert bij
het disassembleren van een uitvoerbaar bestand, en vergemakkelijkt ook het werk van een
reverse engineer. De werking van deze gekende functies is namelijk duidelijk uitgelegd in
specificaties en handleidingen. Reverse engineering is dus niet meer nodig. Daarnaast wordt
er ook gebruik gemaakt van heuristieken om pointers naar code te herkennen [12]. Op deze
wijze kunnen ook bepaalde instructies die enkel via indirect controleverloop bereikbaar zijn
gedisassembleerd worden.
IDA Pro maakt ook gebruik van PDB -bestanden (Program DataBase). Een PDB-bestand
bevat debugging-informatie voor een specifiek PE-bestand, zoals onge¨exporteerde symbolen.
Voor DLL’s van Microsoft-makelij zijn de bijhorende PDB-bestanden online te vinden. IDA
download deze automatisch en gebruikt ze om tot een beter resultaat te komen.
15
2.4
Reverse engineering
Reverse engineering van software is het proberen te begrijpen hoe een applicatie op een hoger niveau werkt [13]. Om dit te doen beschikt een reverse engineer doorgaans enkel over
het uitvoerbaar bestand en de verwante dynamische bibliotheken, beiden bestaande uit uitvoerbare code en data. Er zijn verschillende redenen om aan reverse engineering te doen,
zowel goedaardig als kwaadaardig. De ontwikkelaars van de applicatie kunnen proberen hun
eigen verloren gegane broncode te reconstrueren, of een aanvaller kan een poging wagen om
beschermde algoritmes of datastructuren aanwezig in een uitvoerbaar bestand te kopi¨eren
en te gebruiken voor zijn eigen doeleinden. Antivirus-software kan proberen te achterhalen
of een uitvoerbaar bestand kwaadaardige doeleinden heeft. Verder zijn er tools die bugs in
applicaties opsporen zodat deze gefixed kunnen worden, maar aanvallers kunnen deze zwakheden (en een verbeterd begrip van de werking van de applicatie) omzetten in een succesvolle
exploit.
Reverse engineering kan op twee manieren: statische analyse en dynamische analyse.
2.4.1
Statische analyse
Bij statische analyse wordt een applicatie geanalyseerd zonder deze ook daadwerkelijk uit
te voeren. Er wordt dus gekeken naar de uitvoerbare code in het uitvoerbaar bestand. Deze
wordt gedisassembleerd en er wordt een controleverloopgraaf opgesteld. De resulterende statische representatie van de applicatie wordt gebruikt om – met de hand of automatisch –
de applicatie te analyseren. Hierbij komt symboolinformatie aanwezig in het bestand (om
dynamische symbolen te gebruiken of om debuggen gemakkelijker te maken) van pas. Het
gebruik van dynamische symbolen (meta-informatie) in een functie helpt een reverse engineer
deze functie te begrijpen indien de betekenis van dit symbool gekend is. Aangezien symbolen
namen van functies of variabelen zijn, kan symboolinformatie op zich al veelzeggend zijn.
Het is bijvoorbeeld duidelijk wat een oproep naar de functie ‘CreateFile’ doet. Doordat de
interface aangeboden door een dynamische bibliotheek vast staat, zal een oproep naar deze
functie vanuit eender welk bestand in de toekomst ook altijd hetzelfde blijven doen.
Statische analyse heeft echter zijn beperkingen als het gaat om begrijpen wat een bepaald
stuk code doet. Virusscanners kunnen malware bijvoorbeeld detecteren door in uitvoerbare
code patronen te herkennen die geassocieerd zijn met gekende malware [14], maar deze methode kan niet overweg met polymorfisme. Polymorfisme houdt in dat er vele verschillende
versies van ´e´en virus worden gegenereerd die allen hetzelfde gedrag hebben, maar syntactisch
verschillen [15]. Daarnaast gaat statische analyse er ook van uit dat het statische en dynamische beeld van een applicatie overeenkomen, wat niet per se zo is. De uitvoerbare code in
een uitvoerbaar bestand kan dynamisch aangepast worden [7], en zowel het disassembleren
van uitvoerbare code als het opstellen van een controleverloopgraaf kan bemoeilijkt worden
d.m.v. obfuscatie [16] [10]. Een goede reverse engineer maakt dus ook gebruik van dynamische
analyse.
16
2.4.2
Dynamische analyse
Dynamische analyse houdt in dat we een applicatie analyseren terwijl ze uitvoert. Dit kan
nieuwe inzichten verschaffen en een aantal problemen waar statische analyse last van heeft
oplossen, maar het is in het algemeen ook meer werk. Malware kan bijvoorbeeld statische
analyse bemoeilijken, maar door ze in een beschermde omgeving uit te voeren kan de malware
wel gemakkelijk dynamisch geanalyseerd worden [17][18]. In tegenstelling tot statische analyse
is de vergaarde informatie wel enkel geldig voor een specifieke uitvoering van de applicatie,
en ze levert dus geen volledig beeld van de applicatie [19].
Een techniek die vaak gebruikt wordt tijdens dynamische analyse is API-hooking [20]. Omdat
de interface aangeboden door een dynamische bibliotheek gekend is, kan een reverse engineer
zelf een bibliotheek maken die – een deel van – dezelfde interface aanbiedt. De reverse engineer
kan er dan voor zorgen dat zijn eigen bibliotheek gebruikt wordt in plaats van de oorspronkelijke bibliotheek, en kan zo op een gemakkelijk manier zijn eigen code laten uitvoeren in
een applicatie. De geplaatste ‘hooks’ laten ook toe dynamisch het gebruik van functies uit
bibliotheken waar te nemen (op het einde van de geplaatste hook moeten de echte functies
dan ook opgeroepen worden om een correct verloop van de applicatie te verzekeren).
2.4.3
Bestaande oplossingen
Als we een applicatie willen beschermen tegen reverse engineering kunnen we gebruik maken
van obfuscatie [21]. Een ontwikkelaar kan echter enkel die componenten die hij zelf levert
obfusceren. Obfuscatie is dus geen volledige oplossing voor een dynamisch gelinkte applicatie,
doordat deze nog steeds kwetsbaar is aan de interfaces (vanwege de meta-informatie en APIhooking). Een logische oplossing is dus om het aantal interfaces te verkleinen, door minder
dynamische bibliotheken te gebruiken en meer statisch te linken. Het liefst zouden we volledig
statisch gelinkte applicaties gebruiken, maar die zijn niet compatibel met meerdere versies
van Windows (zie Sectie 2.7).
Prelinking is een proces op Linux waarbij de indeling van de adresruimte van een proces al
statisch (voor de uitvoering) vastgelegd wordt [22]. De adressen van de dynamische bibliotheken (en hun ge¨exporteerde symbolen) binnen de adresruimte van het proces liggen al
vast en kunnen dus op de juiste plaatsen weggeschreven worden. De applicatie zal bijgevolg
sneller opstarten omdat deze adressen niet meer dynamisch berekend moeten worden. Indien
sommige adressen niet up-to-date zijn (omdat een dynamische bibliotheek veranderd is t.o.v.
diegene waartegen er gelinkt werd) worden deze opnieuw berekend. Import Binding is een
gelijkaardig proces op Windows [23]. Deze processen zorgen ervoor dat dynamisch gelinkte
applicaties sneller kunnen opstarten. Ze vormen wel geen beveiliging tegen reverse engineering
aangezien de adressen toch nog dynamisch berekend worden indien een bepaalde bibliotheek
veranderd is.
Slinky is een systeem voorgesteld door Collberg et al. dat de voordelen van statisch en
dynamisch linken met elkaar combineert [24]. Alle uitvoerbare bestanden zijn volledig statisch
gelinkt, maar gemeenschappelijke delen worden op de schijf en in het geheugen gedeeld. Dit
gebeurt door voor elke codepagina een digest te genereren die deze pagina uniek identificeert.
Aan de hand van deze digest wordt bij het installeren van een nieuwe applicatie gekeken of
17
deze codepagina reeds op het systeem aanwezig is, en bij het opstarten van de applicatie of
de codepagina al in het geheugen geladen is. Aangezien de applicatie volledig statisch gelinkt
is, is het beveiligingsprobleem dat deze scriptie poogt op te lossen ook verdwenen. Slinky is
echter enkel een oplossing op Linux. Volledig statisch gelinkte applicaties zijn namelijk niet
compatibel met alle versies van Windows wegens de instabiele kernel-interface. Daarnaast
vereist Slinky ook een aantal aanpassingen in de kernel, iets wat in het geval van Windows
om duidelijke redenen niet mogelijk is in deze scriptie.
Er bestaan een aantal tools voor Windows zoals PEBundle [25], MoleBox [26] en DLLPackager [27] die simpelweg de dynamische bibliotheken waarvan het uitvoerbaar bestand
afhankelijk is samen met dit bestand mee inpakken. Er wordt dan nog extra code aan het
uitvoerbaar bestand toegevoegd om dynamisch deze bibliotheken weer uit te pakken en de
nodige symbolen op te zoeken. De resulterende applicatie is niet echt statisch gelinkt en
hoewel ze minder meta-informatie bevat is ze nog steeds vatbaar voor API-hooking. Deze
oplossingen zullen ook nooit de de systeembibliotheken aan het uitvoerbaar bestand toevoegen, en de interface tussen de systeembibliotheken en de rest van de applicatie zal dus blijven
bestaan.
2.5
Het PE-formaat
Windows gebruikt voor uitvoerbare bestanden het PE-formaat, waarbij de PE staat voor
Portable Executable. In deze sectie worden een aantal eigenschappen van het PE-formaat
uitgelegd die van belang zijn in deze scriptie. Net zoals objectbestanden bestaat een bestand
van dit formaat uit headers die de rest van het bestand beschrijven en uit een aantal secties.
De secties die gebruikt worden, zijn doorgaans dezelfde als diegene die in objectbestanden
gebruikt worden (met dezelfde eigenschappen). Er zijn ook een aantal extra mogelijke secties zoals .edata (voor ge¨exporteerde symbolen), .idata (voor ge¨ımporteerde symbolen) en
.reloc. Voor meer informatie dan in deze sectie gegeven wordt, zie de ‘Microsoft PE/COFF
Specification’ [28].
2.5.1
Dynamisch linken
Het PE-formaat biedt ondersteuning voor dynamisch linken. Het formaat wordt namelijk niet
enkel gebruikt voor uitvoerbare bestanden (exe’s) maar ook voor dynamische bibliotheken
(Dynamic-Link Libraries of DLL’s). Een PE-bestand kan symbolen exporteren en importeren, het exporteert symbolen die in het bestand gedefinieerd zijn zodat andere bestanden
ze kunnen gebruiken, en importeert symbolen uit andere PE-bestanden die deze exporteren. Zowel uitvoerbare bestanden als DLL’s importeren meestal symbolen, maar enkel DLL’s
exporteren doorgaans symbolen.
De meta-informatie aanwezig in het formaat die het mogelijk maakt om dynamisch te linken
vinden we in de export- en importtabellen. De exporttabellen bevatten de symbolen die de
DLL exporteert met hun adres relatief t.o.v. de base (dit adres noemen we een Relative Virtual
Address, of RVA). De base (of het basisadres) van een PE-bestand is het adres waarop het
in het geheugen geladen wordt. Dit adres is niet altijd hetzelfde. De importtabellen bevatten
18
Figuur 2.7: Een voorbeeld van de importtabellen van een PE-bestand.
Figuur 2.8: Een voorbeeld van de exporttabellen van een PE-bestand.
de namen van de DLL’s waaruit er symbolen ge¨ımporteerd worden (de exporterende DLL),
en per ge¨ımporteerde DLL is er een lijst van symbolen die er uit ge¨ımporteerd worden.
Een deel van de importtabellen valt te zien in het voorbeeld op Figuur 2.7. Veel van de voor
deze uitleg niet relevante velden zijn niet aanwezig op de figuur. Per ge¨ımporteerde DLL is
er een Import Descriptor aanwezig in de tabellen. In het voorbeeld wordt enkel de Import
Descriptor voor user32.dll getoond. De Import Lookup Table (of ILT ) bestaat uit RVA’s naar
de informatie die we nodig hebben om symbolen te importeren. De uit user32 ge¨ımporteerde
symbolen zijn GetMessage, LoadIcon en TranslateMessage. Op de figuur is ook de Import
Address Table (of IAT ) aanwezig, waarvan we het nut in Sectie 2.5.2 wordt uitgelegd.
Het importeren van een symbool kan op twee manieren: via naam (zoals in het voorbeeld)
of via ordinaal. Indien een symbool ge¨ımporteerd wordt via naam wordt deze naam in de
importtabellen bijgehouden. Om het adres van een symbool te berekenen wordt deze naam
opgezocht binnen de Export Name Table of ENT van de juiste DLL. Deze tabel bevat een
alfabetisch gesorteerde lijst van ge¨exporteerde symboolnamen. Eens deze naam gevonden
is, wordt de index ervan binnen de ENT gebruikt als een index in de ordinaaltabel. Op deze
index in de ordinaaltabel vinden we dan de ordinaal die gebruikt wordt als index in de Export
Address Table of EAT. Deze tabel bestaat uit een reeks RVA’s (t.o.v. het basisadres van de
exporterende DLL), ´e´en voor elk ge¨exporteerd symbool. De gevonden RVA, opgeteld met het
basisadres van de exporterende DLL levert het symbooladres. Een voorbeeld van een deel
van de exporttabellen valt te zien op Figuur 2.8. De procedure om het adres van het symbool
LoadIcon te berekenen wordt hier voorgesteld a.d.h.v. de rode genummerde pijlen.
19
Figuur 2.9: Een voorbeeld van een dynamisch gelinkt PE-bestand.
Bij import via ordinaal dient de ordinaal (die in de importtabellen bijgehouden wordt) direct
als index in de EAT. Op deze manier wordt het symbooladres dus iets sneller gevonden. Als
er echter een nieuwe versie van de DLL gemaakt wordt, kan het zijn dat de index van het
symbool in de EAT verandert. Import via ordinaal is dus niet even toekomstbestendig als
import via naam en wordt nauwelijks gebruikt (voornamelijk in de systeembibliotheken).
Een andere eigenschap van het PE-formaat die quasi enkel in de systeembibliotheken gebruikt
wordt is export forwarding (of export-doorverwijzing). Als een DLL een export doorverwijst
wil dit zeggen dat het symbool wel ge¨exporteerd wordt door de DLL, maar niet echt aanwezig is in de DLL. Het symbool is een alias voor een ander symbool in een andere DLL,
en de informatie om dit symbool in de andere DLL op te zoeken is aanwezig in de eerste DLL in plaats van het symbool zelf. Deze informatie vind men dan in een string van
de vorm “DLLNAAM.FunctieNaam”. Het door kernel32 ge¨exporteerde symbool HeapAlloc
wordt bijvoorbeeld doorverwezen naar “NTDLL.RtlAllocateHeap”.
2.5.2
Laden
PE-bestanden worden in het geheugen geladen door de loader, die deel uitmaakt van het
besturingssysteem. Niet alleen het PE-bestand zelf maar ook de DLL’s waaruit het symbolen
importeert, worden in het geheugen geladen en de adressen van de ge¨ımporteerde symbolen
worden berekend. De ge¨ımporteerde DLL’s kunnen natuurlijk zelf ook symbolen importeren
zodat nog andere DLL’s waarvan zij afhankelijk zijn ook in het geheugen geladen zullen
worden, enzoverder. Eens een PE-bestand geladen is wordt het beginpunt (indien aanwezig)
aangeroepen. Bij een uitvoerbaar bestand is dit het begin van de uitvoering, bij een DLL is
dit een initialisatieroutine.
De adressen van de ge¨ımporteerde symbolen worden bij het laden van het PE-bestand gevonden en weggeschreven in de IAT (zie Figuur 2.7). De IAT bevatte van tevoren dezelfde RVA’s
als de ILT (zie Sectie 2.5.1). Deze worden dus overschreven met de eigenlijke adressen van de
symbolen. Alle instructies die gebruik maken van een ge¨ımporteerd symbool hebben als ´e´en
van hun operanden een locatie in de IAT (zie als voorbeeld Figuur 2.9). Een operand kan op
20
indirecte wijze gebruikt worden. Het operand zelf wordt dan niet als een waarde beschouwd,
maar als het adres van een waarde. Het is deze waarde die door de instructie gebruikt wordt.
Alle instructies die een ge¨ımporteerd symbool gebruiken, maken dus indirect gebruik van een
operand.
De IAT is een veelgebruikte vector voor aanvallen. De adressen van ge¨ımporteerde functies
kunnen namelijk gemakkelijk overschreven worden. Deze techniek staat bekend als IAThooking, wat een variatie is op API-hooking [29]. Het adres van de echte ge¨ımporteerde
functie in de IAT wordt overschreven met het adres van een door een aanvaller geschreven
functie. Het overschrijven gebeurt door ge¨ınjecteerde code (bv. via DLL injection [30]) of
vanuit een ander proces.
2.5.3
Rebasing
Een laatste eigenschap van het PE-formaat die we moeten aanhalen, is dat bestanden in
het formaat rebaseable zijn. PE-bestanden bevatten absolute geheugenadressen die berekend
zijn met de veronderstelling dat het bestand op een specifiek adres in het geheugen geladen
wordt (de base, of het basisadres). Deze absolute adressen worden onder meer gebruikt om
naar data op een bepaald adres te refereren. Bij een uitvoerbaar bestand kan ervan uitgegaan
worden dat het basisadres waarop het bestand berekend is ook datgene is waarop het geladen
wordt (meestal 0x400000). Bij een DLL is dit niet per se het geval.
Het is gemakkelijk mogelijk dat in ´e´en van de adresruimtes van de applicaties waarin de DLL
gebruikt wordt het basisadres reeds gebruikt wordt door een andere DLL. In dit geval moeten
alle absolute adressen in de DLL herberekend worden. Dit proces heet rebasing. Om dit te
kunnen doen wordt er een lijst met RVA’s voor de locaties van alle absolute adressen binnen
het bestand bijgehouden in de .reloc-sectie (zogenaamde base relocaties).
In het voorbeeld op Figuur 2.10 maakt een inc-instructie (gelegen in de .text-sectie) gebruik
van een statisch gealloceerde variabele (gelegen in de .data-sectie). De DLL is berekend op
0x6000000 als basisadres. De inc-instructie maakt gebruik van een absoluut adres voor de
variabele (0x6002008) voor rebasing), en er is een base relocatie die naar het adres van
dit absoluut adres wijst. Indien het adres 0x6000000 bezet is en de daarom op basisadres
0x7000000 geladen wordt, moet er aan rebasing gedaan worden. Het absoluut adres van de
variabele wordt dan herberekend (als 0x7002008) en het oude adres in de inc-instructie wordt
overschreven.
DLL’s kunnen – na rebasing – op eender welk geheugenadres geladen worden. De mogelijkheid om een component (ook uitvoerbare bestanden) op eender welk geheugenadres te laden
heeft ook een voordeel op beveiligingsvlak. Als namelijk de adresruimte van een proces willekeurig ingedeeld is dan wordt het voor een aanvaller moeilijker om een exploit te schrijven
die het proces op een effectieve manier aanvalt [31][32]. Met een willekeurige indeling willen
we zeggen dat de DLL’s en het uitvoerbaar bestand op een willekeurig basisadres geladen
worden voor elke instantie van de applicatie. We noemen deze techniek Address Space Layout
Randomization of ASLR en base relocaties maken deze techniek mogelijk op Windows [33].
21
Figuur 2.10: Een voorbeeld van rebasing.
Om op andere platformen zoals Linux (waarop ASLR ook gebruik wordt) het laden van
een component op een willekeurig geheugenadres toe te laten wordt er gebruik gemaakt van
Position Independent Code of PIC [2]. Door een extra indirectie toe te voegen kunnen uitvoerbare bestanden en dynamische bibliotheken daar op eender welk geheugenadres geladen
worden zonder dat er een extra proces zoals rebasing aan te pas komt. De code voert zonder
probleem uit op elk adres, maar presteert iets slechter vanwege de indirectie.
2.6
De Windows-systeembibliotheken
De systeembibliotheken zijn een onderdeel van het Windows-besturingssysteem en verschillen
qua inhoud (en soms ook qua structuur) tussen de verschillende versies. Ze bieden wel een
stabiele interface aan voor gebruik door applicaties, maar weinig van wat zich achter deze
interface bevindt is officieel gedocumenteerd en/of gegarandeerd stabiel. We zullen kort de
structuur en verschillende interfaces van de systeembibliotheken bespreken. Hierbij baseren
we ons op Windows 8/8.1.
De belangrijkste systeembibliotheken met hun onderlinge afhankelijkheden zijn te zien op
Figuur 2.11. Een bibliotheek is afhankelijk van een andere bibliotheek als ze symbolen importeert uit de andere bibliotheek. Dit wordt aangeduid met een pijl van de eerste bibliotheek
naar de tweede.
2.6.1
De verschillende API’s
In de eerste versie van Windows NT waren er subsystemen aanwezig voor drie gebruiksomgevingen: Windows, POSIX en OS/2. Dit gebruik van subsystemen maakte het mogelijk om
applicaties die bedoeld zijn voor verschillende gebruiksomgevingen op eenzelfde besturingssysteem uit te voeren. Hoewel er nog altijd een subsysteem voor Unix-gebaseerde applicaties
(SUA) bestaat is het Windows-subsysteem overduidelijk het belangrijkste. Bepaalde functionaliteit is enkel in het Windows-subsysteem ge¨ımplementeerd zodat andere subsystemen
deze enkel kunnen aanroepen via het Windows-subsysteem, en quasi alle applicaties voor het
22
Figuur 2.11: De belangrijkste Windows-systeembibliotheken met onderlinge afhankelijkheden.
Windows-besturingssysteem worden voor dit subsysteem geschreven. De API aangeboden
door dit subsysteem staat bekend als de Windows API (specifiek voor 32-bit applicaties de
Win32 API ), en is goed gedocumenteerd [33].
De symbolen ge¨exporteerd door kernel32, user32 en gdi32 zijn een onderdeel van de Windows API. Naast deze DLL’s zijn er nog veel meer (minder belangrijke) systeembibliotheken
wiens interfaces deel zijn van de Windows API. kernel32 biedt functionaliteit aan om gebruik te maken van typische kerneldiensten die te maken hebben met het bestandssysteem,
het beheren van processen en threads, geheugenbeheer et cetera. Het manipuleren van de
Windows gebruikersinterface (i.e. van menu’s, vensters e.d.) gebeurt via user32, terwijl gdi32
functionaliteit aanbiedt om uitvoer te genereren op grafische hardware (bv. een lijn tekenen).
Op een lager niveau vinden we de grotendeels ongedocumenteerde Native API [33][34][35].
Deze wordt gebruikt door de verschillende subsystemen om de kernel aan te spreken, en
door zogenaamde native applicaties die niet binnen een subsysteem uitvoeren (zoals bv.
drivers). De Native API kan aangeroepen worden vanuit zowel kernel- als user-modus. In
kernel-modus bestaat deze uit functies ge¨exporteerd door ntoskrnl.exe (de kernel-image), in
user-modus uit gelijknamige door ntdll ge¨exporteerde functies die eenvoudige wrappers zijn
rond systeemroepen naar de eigenlijke functies (ge¨ımplementeerd in de kernel). Naast de
Native API bevat ntdll loaderfunctionaliteit en algemene functionaliteit die door de subsystemen gebruikt wordt zoals een aantal functies uit de C-standaardbibliotheek en functies die
communicatie tussen de subsystemen mogelijk maakt. Aangezien ntdll zich architecturaal net
boven de kernel bevindt, importeert ze geen symbolen. Communicatie met de kernel verloopt
23
Figuur 2.12: Een aantal voorbeelden van het API-set-schema.
via systeemoproepen.
2.6.2
Het API-set-schema
Bij de introductie van Windows 7 en Windows 8 vond er een heuse reorganisatie van de
systeembibliotheken plaats. Omdat de door de applicaties gebruikte API stabiel moet blijven
is dit allemaal onder de oppervlakte gebeurd, en is dit niet echt door Microsoft gedocumenteerd. Er werd functionaliteit verplaatst tussen DLL’s, er kwamen DLL’s bij (zoals KernelBase, die functionaliteit bevat die eerder in kernel32 zat), en het API-set-schema werd
ge¨ıntroduceerd [36][37][38][39][40].
Het API-set-schema is een mechanisme dat voor een ontkoppeling zorgt tussen de plaats
waar een API gedefinieerd wordt en de plaats waar deze ge¨ımplementeerd wordt. Er wordt
gebruik gemaakt van API-sets, zogenaamde groepen van ge¨exporteerde functies met een
gemeenschappelijke functionaliteit (bv. alle functionaliteit die met tijd en data te maken
heeft). Voor elke API-set bestaat er een virtuele DLL die de functies waaruit de set bestaat
exporteert. Deze virtuele DLL’s hebben een naam die altijd begint met “api-” (bv. apims-win-core-datetime-l1-1-0 ). Deze virtuele DLL’s bestaan niet echt, en a.d.h.v. het APIset-schema wordt er dynamisch bepaald in welke DLL de eigenlijke implementatie van alle
functies uit de API-set aanwezig is (de implementatie-DLL of logische DLL). Het API-setschema zelf is aanwezig in een sectie van ApiSetSchema.dll, .apiset genaamd. In Figuur 2.12
links valt een voorbeeld te zien van een DLL die importeert uit api-ms-win-core-datetimel1-1-0, waarvan de bijhorende logische DLL kernel32 is. De echte DLL’s worden voorgesteld
met rechthoeken, de virtuele met ruiten. Een gestreepte pijl duidt het gebruik van het APIset-schema aan, een volle pijl de feitelijke afhankelijkheid die daaruit volgt.
Er is echter een uitzondering. In het geval dat DLL importeert uit een virtuele DLL waarvoor
de normale logische DLL dezelfde is als de importerende DLL, bevindt de implementatie zich
niet in de normale logische DLL maar in een andere DLL. Zo is er bijvoorbeeld de APIset api-ms-win-core-file-l1-1-0.dll waarvoor kernel32 normaliter de logische DLL is. Indien
kernel32 zelf echter uit deze API-set importeert, is de bijhorende logische DLL KernelBase.
Deze twee voorbeelden zijn ook te zien op Figuur 2.12.
24
Het gebruik van het API-set-schema (door te importeren uit virtuele DLL’s) gebeurt doorgaans enkel door DLL’s van Microsoft-makelij (de systeembibliotheken en anderen die hierop
bouwen).
2.7
De kernel-interface in Windows
De interface die de kernel aan applicaties aanbiedt noemen we de kernel-interface. Naast
deze interface biedt de kernel natuurlijk ook nog interfaces aan voor gebruik door andere
componenten uit de kernel-modus (zoals drivers), maar deze zijn niet van belang voor deze
scriptie. Net zoals een bibliotheekinterface bestaat uit ge¨exporteerde symbolen, bestaat de
kernel-interface uit de systeemoproepen die mogelijk zijn.
2.7.1
Systeemoproepen
Als een applicatie een geprivilegieerde actie wil ondernemen, moet deze aan de kernel vragen
dit voor haar te doen. Dit gebeurt via een systeemoproep. De systeembibliotheken bieden
simpele wrapper-functies aan als abstractie voor systeemoproepen. We noemen deze System
Call Wrappers of SCW’s. We nemen als voorbeeld van een geprivilegieerde actie het alloceren
van meer virtueel geheugen. In dit voorbeeld is de naam van de gebruikte SCW NtAllocateVirtualMemory. Het aanroepen van een SCW (en dus het uitvoeren van een systeemoproep)
leidt ertoe dat er in de kernel-modus een functie zal opgeroepen worden om de gevraagde
actie te ondernemen. Deze opgeroepen functie noemen we de system service [41][42]. System
services hebben dezelfde namen als de SCW’s die hun user-modus abstractie vormen, de in
het voorbeeld opgeroepen system service heet dus ook NtAllocateVirtualMemory.
Aangezien kernel en applicatie in verschillende modi uitvoeren, moet er bij een systeemoproep
van modus gewisseld worden. In vroegere tijden gebeurde dit op x86 d.m.v. een interruptinstructie, maar Intel en AMD hebben voor dit doeleind allebei een gespecialiseerde instructie
ontwikkeld (respectievelijk sysenter en syscall ) die gebruikt wordt op modernere versies van
Windows [33]. Welke manier er ook gebruikt wordt om van modus te wisselen, op een zeker
moment wordt de routine KiFastCallEntry in kernel-modus opgeroepen [43][44]. Deze routine
handelt de systeemoproep af door te beslissen welke system service er gevraagd is, en deze
uit te voeren.
Om ervoor te zorgen dat KiFastCallEntry kan beslissen welke system service er exact gevraagd wordt, wordt er net voor het uitvoeren van een systeemoproep een waarde in het
eax-register geplaatst (de System Call Ordinal of SCO). Dit is een 32-bits waarde, maar niet
al deze bits worden echt gebruikt. Figuur 2.13 toont de indeling van de bits in de SCO. Om
uit te kunnen leggen hoe een systeemoproep afgehandeld wordt (en hoe de SCO hierbij van
pas komt), leggen we eerst een aantal kernel-structuren uit.
Een System Service Dispatch Table of SSDT is een tabel bestaande uit adressen van system
services. De System Service Number of SSN (zie Figuur 2.13) wordt gebruikt als 12-bits index
in deze tabel om de gevraagde system service op te roepen [45][46]. Er zijn minstens twee
SSDT’s aanwezig in de kernel: ´e´en voor gewone system services en ´e´en voor grafische system
25
Figuur 2.13: De indeling van de SCO.
Figuur 2.14: De verschillende structuren die gebruikt worden bij het afhandelen van een
systeemoproep.
services. Deze laatste SSDT noemen we de Shadow SSDT, en de bijhorende system services
zijn niet ge¨ımplementeerd in de kernel-image maar in win32k.sys. Daarnaast is elke thread
geassocieerd aan een Service Descriptor Table of SDT. Deze bestaan uit (maximaal) vier
System Service Tables of SST’s. Een SST bestaat uit het adres van een SSDT en wat gerelateerde informatie (onder meer over de argumenten voor elke system service). Op Figuur 2.14
wordt een beeld van al deze structuren weergegeven.
Er zijn slechts twee mogelijke SDT’s: KeServiceDescriptorTable en KeServiceDescriptorTableShadow. De eerste wordt gebruikt door gewone threads (systeemthreads), de tweede door
threads die grafische functionaliteit gebruiken (GUI-threads). Van zodra een systeemthread
probeert grafische functionaliteit te gebruiken, wordt deze omgezet naar een GUI-thread en
wordt de KeServiceDescriptorTableShadow zijn SDT. KeServiceDescriptorTable heeft slechts
´e´en SST, deze is voor de gewone SSDT. KeServiceDescriptorTableShadow heeft er twee: ´e´en
voor de gewone SSDT en ´e´en voor de Shadow-SSDT. De keuze voor een specifieke SST (en
dus SSDT) gebeurt a.d.h.v. een index van 2 bits in de SCO (de SST-index, zie Figuur 2.13).
Samengevat kunnen we zeggen dat de SDT thread-afhankelijk is, de SST bepaald wordt
a.d.h.v. de SDT en de SST-index, en de system service opgeroepen wordt op basis van de
SST en de SSN.
26
2.7.2
Syscall en sysenter
Er bestaan twee gespecialiseerde instructies om op een x86-processor een systeemoproep uit
te voeren. Indien de processor in 32-bits modus uitvoert, moet de sysenter-instructie uitgevoerd indien het om een Intel-processor gaat, en de syscall-instructie indien het om een
AMD-processor gaat (deze ondersteunen elkaars instructies niet). Deze instructies hebben
een gelijkaardige werking maar verschillen enigszins en zijn niet zomaar verwisselbaar. Alvorens sysenter uit te voeren moet het adres van de top van de stapel opgeslagen worden (dit
gebeurt in het edx-register). Bij de syscall-instructie is dit niet nodig [47][33]. Uit compatibiliteitsoverwegingen maken de systeembibliotheken geen direct gebruik van deze instructies.
In plaats daarvan bevatten de SCW’s een indirecte oproep naar een kleine routine die door
de kernel wordt ingesteld bij het opstarten: SystemCallStub. SystemCallStub zal de juiste
instructie bevatten om een systeemoproep uit te voeren, en indien nodig het adres van de
top van de stapel in het edx-register plaatsen. In het algemeen ziet een van deze indirectie
gebruik makende SCW er als volgt uit:
mov
mov
call
ret
eax, SCO
edx, offset SharedUserData!SystemCallStub
dword ptr [edx]
In 64-bits modus ondersteunen Intel-processors de syscall-instructie wel. Alle systeemoproepen vanuit 64-bits modus gebeuren dan ook via syscall, zonder indirectie:
mov
syscall
ret
2.7.3
eax, SCO
Instabiliteit
Zoals vermeld in de inleiding is de interface aangeboden door de Windows-kernel niet stabiel
over verschillende versies. Het probleem is niet dat de system services die aangeboden worden
en de argumenten die deze gebruiken veranderen. Deze zijn inderdaad niet gegarandeerd om
hetzelfde te blijven, maar in de praktijk veranderen ze nauwelijks. De SCO verbonden aan een
specifieke system service daarentegen verandert wel tussen verschillende versies van Windows.
Deze kan zelfs veranderen bij het uitbrengen van een nieuwe service pack, en de SCO’s voor
dezelfde system services verschillen bv. ook tussen Windows 8 en Windows 8.1. Een tabel met
SCO’s voor alle systeemoproepen op alle recente versies van Windows kan online gevonden
worden [48].
Om een volledig statisch gelinkte applicatie compatibel te maken met verschillende versies
van Windows is het dus voornamelijk van belang om ervoor te zorgen dat de applicatie op
elke versie de gepaste SCO’s gebruikt.
27
Figuur 2.15: De architectuur van de WoW64-laag.
2.7.4
Systeemoproepen en systeembibliotheken
Er zijn een aantal systeembibliotheken die SCW’s bevatten. Zo is er ntdll dat de Native
API bevat (zie Sectie 2.6.1). Deze API bestaat uit ge¨exporteerde SCW’s waarvan de namen
allemaal beginnen met een “Nt” zoals NtAllocateVirtualMemory, NtWritefile en NtCreateProcess. Deze SCW’s vormen een abstractie voor de gelijknamige system services, allen
ge¨ımplementeerd in de kernel-image. De adressen van deze system services zijn te vinden in
de gewone SSDT, en de SCO voor deze systeemoproepen bevat dus als SST-index altijd 0.
Daarnaast zijn er ook (voornamelijk onge¨exporteerde) SCW’s in user32 (namen beginnende
met “NtUser”) en gdi32 (namen beginnende met “NtGdi”). De bijhorende system services
zijn ge¨ımplementeerd in win32k.sys en hun adressen zijn te vinden in de Shadow SSDT.
Bijgevolg bevat de SCO voor deze systeemoproepen altijd een 1 als SST-index.
2.7.5
WoW64
WoW64 is de afkorting voor Win32 on Windows 64-bit, de emulator die het mogelijk maakt
om Win32-applicaties (bedoeld voor een 32-bits Windows) uit te voeren op een 64-bits Windows [49]. Deze emulator is eigenlijk een laag tussen de 32-bits applicatie en het 64-bits
besturingssysteem, bestaande uit drie DLL’s: wow64, wow64cpu en wow64win [50]. In de
adresruimte van elke 32-bits applicatie zijn dus naast de 32-bits systeembibliotheken ook nog
de 64-bits WoW64-bibliotheken en een 64-bits versie van ntdll aanwezig, hoewel de applicatie
van deze laatste twee geen weet heeft (zie Figuur 2.15). De 32-bits systeembibliotheken op
een 64-bits Windows zijn zeer gelijkaardig aan die van een 32-bits Windows, maar er is een
belangrijk verschil: ze doen zelf geen systeemoproepen [51].
Als we een 32-bits systeembibliotheek op een 64-bits Windows 8/8.1 beschouwen, dan ziet
een SCW er als volgt uit (vergelijk met Sectie 2.7.2):
mov
call
ret
eax, SCO
large dword ptr fs:0xC0
De SCO ziet er in dit geval ook net iets anders uit (zie Figuur 2.16). De bovenste 16 bits
vormen een index die gebruikt wordt door de WoW64-laag (de WoW64-index ), en er schieten
28
Figuur 2.16: De indeling van de SCO voor WoW64.
nog maar twee bits over die ongebruikt zijn (aangeduid met “ONG.”).
De indirecte call-instructie die de sysenter- of syscall-instructie vervangt in de 32-bits systeembibliotheken heeft als doeladres een ‘far jump’-instructie in wow64cpu. Dit soort instructie
springt naar een specifiek adres in een specifiek segment. In dit geval springt de instructie
naar de functie CpupReturnFromSimulatedCode binnen wow64cpu, in een 64-bits segment.
Dit is dus het punt waarop de CPU overschakelt naar 64-bits modus. Alvorens de syscallinstructie uit te voeren, moeten de argumenten (die nu op een 32-bits stapel staan) aangepast
worden om correct gebruikt te worden door de 64-bits kernel. De exacte manier waarop dit
gebeurt, hangt af van de WoW64-index. Eens de systeemoproep uitgevoerd is, wordt het
resultaat aangepast tot hetgeen een 32-bits kernel zou hebben teruggeven. Hierna wordt er
terug overgeschakeld naar 32-bits modus en wordt de WoW64-laag verlaten.
De gebruikte SCO wordt niet aangepast door de WoW64-laag. Dit impliceert dat op een
64-bits Windows de SCO’s die de 32-bits en 64-bits systeembibliotheken gebruiken voor een
specifieke system service dezelfde zijn. De SCO’s die de 32-bits systeembibliotheken op een
32-bits en een 64-bits Windows gebruiken verschillen wel.
29
Hoofdstuk 3
Encrypteren van meta-informatie
In dit hoofdstuk wordt de methode voorgesteld die – door het encrypteren van meta-informatie
– als doel heeft om de interfaces tussen een uitvoerbaar bestand en alle gebruikte bibliotheken
te verbergen. Dit is voordelig op vlak van beveiliging. De meta-informatie aanwezig in dynamisch gelinkte uitvoerbare bestanden kan namelijk gebruikt worden bij het statisch analyseren van de applicatie. In de besproken methode wordt de meta-informatie in ge¨encrypteerde
vorm opgeslagen zodat dynamisch linken nog mogelijk blijft, maar statische analyse sterk bemoeilijkt wordt. Eerst wordt de algemene werking besproken, vervolgens wordt de methode
in meer detail uitgewerkt en tot slot komen de beperkingen en mogelijke uitbreidingen van
de methode aan bod.
3.1
De algemene werking
Het doel van de methode is om op basis van het oorspronkelijk uitvoerbaar bestand door Diablo een herschreven bestand te laten genereren waarin de meta-informatie in ge¨encrypteerde
vorm is opgeslagen. Aan de hand van deze ge¨encrypteerde meta-informatie zal de applicatie tijdens het uitvoeren de benodigde symbolen vinden (op het moment dat ze nodig zijn).
De meta-informatie wordt niet simpelweg dynamisch gedecrypteerd naar zijn oorspronkelijke vorm, deze zou namelijk bij het uitvoeren van de applicatie gemakkelijk uit het geheugen gehaald kunnen worden om vervolgens te gebruiken in een statische analyse. In plaats
daarvan worden de ge¨ımporteerde symbolen gevonden op basis van de ge¨encrypteerde metainformatie, zonder deze te decrypteren.
Om een herschreven bestand te genereren dat hiertoe in staat is, maakt Diablo twee grote
aanpassingen aan het uitvoerbaar bestand. Ten eerste worden de importtabellen (die de
meta-informatie bevatten) uit het oorspronkelijke bestand verwijderd en in ge¨encrypteerde
vorm toegevoegd aan het nieuwe bestand. Ten tweede wordt er extra code aan het bestand
toegevoegd. Deze code – de zogenaamde glue code – staat in voor het dynamisch vinden van
de benodigde symbolen op basis van de ge¨encrypteerde meta-informatie.
De glue code bevat – naast een aantal hulpfuncties – twee hoofdfuncties. De eerste is de initialisatiefunctie die het nieuwe beginpunt van de applicatie wordt. Deze initialiseert een aantal
variabelen die door de rest van de glue code gebruikt worden, waarna ze naar het oorspronkelijke beginpunt van de applicatie springt. Daarnaast is er ook de laadfunctie die instaat
voor het dynamisch opzoeken van de ge¨ımporteerde symbolen op basis van de ge¨encrypteerde
30
Figuur 3.1: De algemene werking van de methode.
meta-informatie. Diablo vervangt elke instructie die gebruik maakt van ge¨ımporteerde symbolen (dit is een indirecte instructie die gebruik maakt van de IAT, zie Sectie 2.5.2) door een
oproep naar de laadfunctie. Eens de laadfunctie opgeroepen zal deze de instructie (die nu een
call-instructie is) terug herschrijven naar de instructie die er eigenlijk moet staan, namelijk
de directe variant van de (indirecte) oorspronkelijke instructie. De instructie die er eigenlijk
moet staan noemen we de eigenlijke instructie.
De algemene werking wordt nog eens voorgesteld op Figuur 3.1. Deze figuur toont ook een
voorbeeld van het controleverloop van de oorspronkelijke en de herschreven applicatie, voorgesteld door de nummering.
3.2
Het encrypteren van de meta-informatie
Voor het encrypteren wordt er gebruik gemaakt van eenrichtingsfuncties. Dit zijn functies
waarvan de uitvoer gemakkelijk te berekenen is gegeven de invoer, maar waarvoor het zeer
moeilijk is de invoer terug te vinden gegeven de uitvoer. Het is deze uitvoer die bijgehouden
wordt in het herschreven bestand en gebruikt zal worden om toch nog de ge¨ımporteerde symbolen te kunnen vinden. De specifieke vorm van eenrichtingsfuncties die in de implementatie
gebruikt wordt is die van een hashfunctie, met als uitvoer een hashwaarde.
De informatie die we zeker nodig hebben om dynamisch ge¨ımporteerde symbolen te kunnen
vinden bestaat uit de namen van de DLL’s waaruit we symbolen importeren en de namen
(of ordinalen) van deze symbolen zelf. In de huidige implementatie is er enkel ondersteuning
voor import via naam en niet via ordinaal, omdat er niet veel uitvoerbare bestanden zijn die
nog van het laatste gebruik maken. Zo’n uitvoerbare bestanden bestaan echter wel en om
alle uitvoerbare bestanden te kunnen herschrijven zou ook ondersteuning voor import via
ordinaal voorzien moeten worden. Er wordt in de glue code een tabel voorzien die de hash
bevat voor de naam van elke gebruikte DLL, zodat de glue code deze kan laden. Deze tabel
noemen we de DLL-tabel.
31
Figuur 3.2: De structuur van een element in de DYNIMP-tabel. De groottes van de velden
zijn niet op schaal.
Om elke oproep naar de laadfunctie te kunnen herschrijven naar de eigenlijke instructie wordt
er ook een tabel voorzien – de DYNIMP-tabel – die een element bevat voor elke instructie die
een ge¨ımporteerd symbool gebruikt. Dit element bevat alle informatie die nodig is voor het
herschrijven. Figuur 3.2 toont de structuur van dit element. De hash van het terugkeeradres en
de salt worden gebruikt door de laadfunctie om te identificeren welk element uit de DYNIMPtabel ze moet gebruiken. De hash van de symboolnaam en de index in de DLL-tabel worden
gebruikt om het symbooladres dynamisch te berekenen, en alle andere velden worden gebruikt
om de ‘call laadfunctie’-instructie te herschrijven.
De laadfunctie moet als ze aangeroepen wordt in staat zijn te identificeren welk element
uit de tabel te gebruiken. Een mogelijkheid zou zijn om Diablo net voor de oproep naar de
laadfunctie een instructie te laten toevoegen die een bepaalde waarde in een register plaatst
op basis waarvan deze identificatie kan gebeuren. We verkiezen echter zo weinig mogelijk
aanpassingen in de oorspronkelijke code aan te laten brengen door Diablo, omdat we bij het
dynamisch herschrijven deze aanpassingen weer ongedaan moeten maken. De identificatie
gebeurt daarom op basis van het terugkeeradres, dat bij een functieoproep automatisch op
de stapel geplaatst wordt.
Als we de terugkeeradressen rechtstreeks in de tabel zouden opslaan, zou het mogelijk zijn om
gewoon door naar de tabel te kijken af te leiden op welke locaties in de code er ge¨ımporteerde
symbolen gebruikt worden. Om dit ietwat te bemoeilijken zijn ook de terugkeeradressen
ge¨encrypteerd d.m.v. een eenrichtingsfunctie. Aangezien we met 32-bits adressen werken en
de uitvoerwaarden ook een grootte van 32 bits hebben, zijn de invoerruimte en de uitvoerruimte van de functie even groot. Dit is negatief voor de kwaliteit van een eenrichtingsfunctie
en daarom wordt er gebruik gemaakt van een salt [52]. Een salt bestaat uit extra – willekeurig
gegenereerde – bytes die aan de invoer toegevoegd worden waardoor de invoerruimte vergroot
wordt. De formule voor de oorspronkelijke eenrichtingsfunctie is h(x), met x als invoer en
het resultaat van functie als uitvoer (of hash). Indien we gebruik maken van een salt wordt
deze formule h(x, r()). Hierbij is r() een functie die geen invoer heeft maar een willekeurige
waarde als uitvoer heeft. De uitvoer van deze functie dient als extra invoer voor de eenrichtingsfunctie. Het gebruik van salts maakt het ook mogelijk om, in geval van botsingen tussen
de uitvoerwaarden, nieuwe uitvoerwaarden te genereren op basis van dezelfde (echte) invoer,
maar met nieuwe salts.
32
3.3
3.3.1
De glue code
Aanpassingen in Diablo
Het toevoegen van de glue code gebeurt in Diablo na het emuleren van het linkerproces,
maar voor het disassembleren van de .text-secties en het opbouwen van de ACVG. Op dit
punt voegen we de objectbestanden die de glue code bevatten toe aan het parent-object,
zodat we veranderingen kunnen maken in de ACVG en verbindingen kunnen maken tussen
de oorspronkelijke applicatie en de glue code.
Na het opbouwen van de controleverloopgraaf wordt deze door Diablo onderverdeeld in functies. Knopen die niet bereikbaar zijn vanaf de beginknoop worden geen onderdeel van een
functie. Indien geen van de BBL’s waaruit een functie bestaat bereikbaar is vanuit de beginknoop, zal deze groep BBL’s niet als een functie herkend worden door Diablo. Dit is
natuurlijk het geval voor de knopen uit de glue code, er zijn namelijk nog geen verbindingen
tussen de glue code en de oorspronkelijke code. Bijgevolg zullen de initialisatiefunctie noch
de laadfunctie (noch enige hulpfuncties) herkend worden. Omdat het ons voordelig uitkomt
als functies als zodanig herkend worden maken we gebruik van de force reachable-vlag die
Diablo dwingt een specifiek symbool als bereikbaar te beschouwen, waardoor de verwante
functie herkend wordt.
Er moeten een aantal veranderingen gebeuren in de controleverloopgraaf om de glue code
echt aan de applicatie toe te voegen. Zo moet de initialisatiefunctie het beginpunt worden en
op het einde naar het oorspronkelijke beginpunt springen. Ten tweede moet elke instructie
die gebruik maakt van ge¨ımporteerde symbolen vervangen worden door een oproep naar de
laadfunctie. Deze instructies worden bepaald door alle bestaande relocaties te overlopen en
die relocaties te zoeken die van een instructie naar een locatie binnen de IAT wijzen. Voor
elke instructie die gebruik maakt van een ge¨ımporteerd symbool wordt er een element aan
de DYNIMP-tabel toegevoegd alvorens de instructie te vervangen.
Er zijn twee gevallen, afhankelijk van wat voor soort instructie we vervangen. Indien het een
controleverloopinstructie is, zal deze zich aan het einde van zijn BBL bevinden. In dit geval
vervangen we de uitgaande pijl door een call-pijl met als eindknoop het eerste BBL van de
laadfunctie. De oorspronkelijke eindknoop van deze pijl is een helleknoop. Het operand is
namelijk een adres dat opgeslagen ligt binnen de IAT, en er is dus sprake van indirect controleverloop. Een voorbeeld waarin de controleverloopinstructie in kwestie een call-instructie
is, is voorgesteld in Figuur 3.3.
In het tweede geval hebben we te maken met een instructie die geen controleverloopinstructie is, en dus niet noodzakelijk de laatste instructie binnen zijn BBL is. Mochten we deze
instructie vervangen door een call naar de laadfunctie dan zou dit resulteren in een call in
het midden van een BBL, wat niet toegestaan is. Daarom zullen we in dit geval het BBL net
na de instructie opsplitsen in twee BBL’s en de nodige aanpassingen maken. Een voorbeeld
van dit geval waarin de te vervangen instructie een mov-instructie is, valt eveneens te zien in
Figuur 3.3.
33
Figuur 3.3: Voorbeelden voor het vervangen van instructies die ge¨ımporteerde symbolen gebruiken.
Bij het vervangen van de oorspronkelijke instructie door een call-instructie moet er ook
rekening gehouden worden met een eventueel verschil in lengte tussen de call-instructie (5
bytes) en de eigenlijke instructie die na het oproepen van de laadfunctie de call-instructie zal
vervangen. Indien de eigenlijke instructie langer is dan 5 bytes wordt er extra plaats voorzien
door middel van padding bytes (NOP-instructies).
3.3.2
De initialisatiefunctie
De initialisatiefunctie bootst de initialisatie na die bij het opstarten van een nieuwe applicatie plaatsvindt. De DLL’s waarvan de applicatie afhankelijk is, worden in de adresruimte
van het proces geladen en hun initialisatieroutines worden uitgevoerd. In tegenstelling tot
de normale initialisatie worden de adressen van de ge¨ımporteerde symbolen nog niet door
de initialisatiefunctie berekend en op de juiste plaats weggeschreven. Dit zal op een later
moment (voor elk afzonderlijk gebruik van een symbool) gebeuren bij het aanroepen van de
laadfunctie.
Het volledige proces om een DLL te laden is een ingewikkelde taak waarvoor ook medewerking van de kernel vereist is. We kunnen dit volledige proces laten uitvoeren d.m.v. ´e´en
functie-aanroep, namelijk die van de ge¨exporteerde functie LoadLibrary[53] uit een van de
systeembibliotheken, kernel32. LoadLibrary zal ons het adres teruggeven waarop de DLL is
geladen, wat we voor later gebruik zullen bijhouden.
Er zijn nog meer plaatsen in de glue code waar het ons voordelig uitkomt om gebruik te
maken van de functionaliteit die kernel32 aanbiedt, zoals bijvoorbeeld bij het herschrijven
van instructies. Het vinden van de symbolen die de glue code nodig heeft uit kernel32 gebeurt
op dezelfde wijze als waarop het vinden van de ge¨ımporteerde symbolen voor de eigenlijke
applicatie gebeurt, namelijk op basis van gehashte symboolnamen. Rest wel de vraag hoe
we kernel32 kunnen laden als we nog niet beschikken over de functionaliteit om een DLL te
34
laden.
In feite is kernel32 reeds aanwezig in de adresruimte van het proces. Bij het opstarten van
een applicatie zal Windows namelijk een aantal systeembibliotheken automatisch laden, zelfs
als de applicatie hieruit geen symbolen importeert (en zelfs als de applicatie in het geheel
geen symbolen importeert). E´en van deze systeembibliotheken is kernel32. kernel32 is dus wel
degelijk aanwezig in de adresruimte van ons proces, het enige wat ons nog rest is het basisadres ervan te vinden. Dit is een probleem dat men ook tegenkomt bij Windows-shellcodes.
Op het moment dat een shellcode aan zijn uitvoering begint, is kernel32 reeds aanwezig in de
adresruimte van het aangevallen proces, maar kent de shellcode het adres ervan niet. Aangezien de shellcode de functionaliteit van kernel32 wil gebruiken voor zijn eigen doeleinden
is de eerste stap in de uitvoering dus dit adres te vinden. Er bestaat een algemene manier
om dit te doen die gebruik maakt van het Process Environment Block (PEB) [54] [55]. Deze
methode wordt ook in de initialisatiefunctie gebruikt.
Eens de initialisatiefunctie over het adres van kernel32 beschikt worden de adressen berekend van alle symbolen die de glue code hieruit gebruikt. kernel32 exporteert de functie
GetProcAddress [56] die gegeven het adres van een DLL en een symboolnaam het adres van
het symbool berekent, maar doordat we met hashes werken in plaats van de eigenlijke namen
kunnen we deze functie niet gebruiken. Daarom is er in de glue code een functie aanwezig
met dezelfde functionaliteit als GetProcAddress, maar dan op basis van de hashwaarde van
een symboolnaam. Deze functie overloopt alle namen in de ENT van de exporterende DLL en
vergelijkt per naam de resulterende hashwaarde met de hashwaarde van de symboolnaam die
we zoeken. Indien deze twee gelijk zijn hebben we het gezochte symbool (en bijhorend adres)
gevonden. Het is echter ook mogelijk dat we te maken hebben met een ge¨exporteerd symbool
dat doorverwezen wordt (zie Sectie 2.5.1). In dit geval is het bijhorend adres niet dat van het
symbool zelf – gezien het niet aanwezig is in de DLL – maar het adres van een string van
de vorm “DLLNAAM.FunctieNaam” [28]. We kunnen deze informatie nu gebruiken om de
eigenlijke DLL te laden via LoadLibrary – als de DLL reeds geladen is zal LoadLibrary gewoon het adres teruggeven zonder de DLL nog eens te laden – en vervolgens GetProcAddress
gebruiken om het adres te vinden van het symbool waarnaar er doorverwezen wordt.
Nu we beschikken over de nodige functionaliteit uit kernel32 kunnen we beginnen de DLL’s
waarvan de applicatie afhankelijk is te vinden en te laden. Aangezien we weer enkel de
gehashte namen hebben en niet de namen zelf, kunnen we niet meteen de functie LoadLibrary
gebruiken. Er zijn twee plaatsen van waarop DLL’s geladen kunnen worden bij het opstarten
van een applicatie: de system32 -map en de map waarin de applicatie zelf aanwezig is. Eerst
lopen we door de system32-map en vergelijken per DLL de hash van hun naam met de
hash van de gezochte naam. Indien er geen match gevonden wordt doen we hetzelfde bij
applicatiemap. Vervolgens gebruiken we de gevonden naam als argument in LoadLibrary en
overschrijven in de DLL-tabel de hash van de naam met het adres van de DLL.
Op het einde van de initialisatiefunctie springen we naar het oorspronkelijke beginpunt van
de applicatie en wordt er aan de uitvoering van de echte applicatie begonnen.
35
Figuur 3.4: Voorbeelden van het herschrijven van instructies die ge¨ımporteerde symbolen
gebruiken.
3.3.3
De laadfunctie
De laadfunctie zal, eens ze opgeroepen wordt, de call-instructie vanaf waar ze is opgeroepen
herschrijven naar de eigenlijke instructie aan de hand van de informatie in de DYNIMP-tabel.
Zie Figuur 3.4 voor een aantal voorbeelden hiervan.
In het begin van de laadfunctie worden alle caller-saved registers op de stapel geplaatst en
deze registers krijgen terug hun oorspronkelijke waarde op het einde van de laadfunctie.
Normaal gezien worden deze registers (indien nodig) op de stapel geplaatst net voor een callinstructie. De ‘call laadfunctie’-instructie is echter door Diablo aan de applicatie toegevoegd
en de oorspronkelijke instructie was niet per se een call-instructie. Daarom zal de laadfunctie
voor alle zekerheid de caller-saved registers veilig stellen.
De eerste, echte stap is bepalen welk element uit de DYNIMP-tabel benodigd is. Dit gebeurt
aan de hand van het terugkeeradres, zoals beschreven in Sectie 3.2. Nadat het juiste element
gevonden is, zoeken we (m.b.v. de index in het element) het basisadres op van de DLL waaruit
het symbool ge¨ımporteerd wordt. Dit adres wordt samen met de hash van de symboolnaam
gebruikt om het adres van het symbool te berekenen.
Om de ‘call laadfunctie’-instructie te kunnen herschrijven moet eerst het geheugenbereik
waarop we willen schrijven schrijfbaar gemaakt worden. Hiervoor gebruiken we de VirtualProtect [57] functie uit kernel32 die de geheugenbescherming aanpast voor alle geheugenpagina’s met minstens ´e´en byte in het gevraagde bereik. Het gevraagde geheugenbereik begint
op het adres van de ‘call laadfunctie’-instructie en heeft de lengte van de instructie waarmee we deze willen vervangen. Deze lengte valt te vinden in het gevonden element uit de
tabel en is minstens vijf bytes (minstens ´e´en byte opcode en altijd vier voor een adres) en
hoogstens vijftien bytes (de maximale lengte van een x86-instructie [47]). Het geheugenbereik
wordt leesbaar, schrijfbaar ´en uitvoerbaar gemaakt. Dit geheugen moet ook uitvoerbaar zijn
in het geval dat we een ‘call laadfunctie’-instructie willen overschrijven die zich per toeval op
eenzelfde pagina bevindt als stukken van de glue code die ook uitgevoerd moeten worden.
Nu het geheugen schrijfbaar is kunnen we de eigenlijke instructie wegschrijven en op de juiste
plaats binnen de instructie het adres van het symbool – dat als operand dient – wegschrijven.
36
Alle informatie om dit te doen is aanwezig in het element uit de DYNIMP-tabel. Indien de
eigenlijke instructie een controleverloopinstructie is (valt te vinden in de tabel) moet niet het
adres van het symbool maar een EIP-relatieve offset naar dit adres weggeschreven worden.
Eens de instructie aangepast is, wordt VirtualProtect nogmaals opgeroepen om het geheugenbereik weer de oude geheugenbescherming te geven. Omdat zelf-aanpassende code tot
problemen met de instructiecaches kan leiden, doen we een oproep naar FlushInstructionCache [58]. Uiteindelijk wordt het terugkeeradres van de stapel gehaald, aangepast naar het
adres van de herschreven instructie, en terug op de stapel geplaatst. De laadfunctie keert dus
terug naar de herschreven instructie zodat de normale uitvoering kan hervatten.
Elke ‘call laadfunctie’-instructie wordt dus hoogstens ´e´en keer uitgevoerd, en het uitvoeren
resulteert in het overschrijven van deze instructie met de eigenlijke instructie. Op deze manier
wordt de overhead ge¨ıntroduceerd door de methode geminimaliseerd. De herschreven instructie maakt ook direct gebruik van het adres van ge¨ımporteerd symbool. Dit in tegenstelling
tot de oorspronkelijke, indirecte variant uit de oorspronkelijke applicatie die dit adres uit de
IAT haalde. Het verwijderen van deze indirectie heeft een positief effect op de prestatie van
de applicatie.
3.4
3.4.1
Beperkingen en mogelijke uitbreidingen
De eenrichtingsfuncties
Een eerste beperking in de huidige implementatie heeft te maken met het gebruik van eenrichtingsfuncties om de meta-informatie te encrypteren. We vertrouwen erop dat deze functies
sterk genoeg zijn zodat het niet mogelijk is om op basis van de uitvoer de invoer af te leiden.
De huidige gebruikte eenrichtingsfuncties zijn eerder van functioneel nut dan dat ze cryptografisch sterk zijn. Zelfs indien we gebruik maken van ingewikkeldere eenrichtingsfuncties zal
het niet onmogelijk zijn om de invoer te achterhalen aan de hand van de uitvoer doordat de
invoerruimte in de praktijk zeer klein is. Er zijn maar een beperkt aantal namen van DLL’s
die de applicatie kan gebruiken en per DLL is er een beperkt aantal namen van ge¨exporteerde
symbolen.
In een normaal gebruiksgeval is het berekenen van eenrichtingsfunctie voor al zijn invoerwaarden een uitdaging die een grote hoeveelheid rekenkracht en tijd vereist. Omdat de feitelijke
invoerruimte in dit geval veel kleiner is dan de theoretische invoerruimte – bestaande uit
alle mogelijke strings – kan een aanvaller wel binnen een redelijke termijn voor alle mogelijk
invoerwaarden de hashwaarde berekenen. Het zou dus mogelijk zijn voor een aanvaller om
alle mogelijk hashwaardes te berekenen, en zo de hashwaardes uit de DYNIMP-tabel en de
DLL-tabel te vertalen naar de bijhorende symboolnamen respectievelijk DLL-namen. Het
gebruik van salts zou hier ook niet zoveel helpen als men zou verwachten. Stel dat er 3000
DLL’s aanwezig zijn in de systeemmap en de applicatiemap tezamen waarvan een applicatie
mogelijk gebruik maakt. Als we salts gebruiken moet de aanvaller voor elke gebruikte DLL
afzonderlijk de namen van al deze DLL’s hashen en vergelijken. Stel dat de applicatie gebruik
maakt van 100 DLL’s – voor het merendeel van de applicaties al een grove overschatting –
dan komt dit neer op de hashfunctie 300000 keer uitvoeren, wat met de rekenkracht van de
37
huidige processoren binnen de tijdspanne van enkele seconden gebeurd is. Eens de gebruikte
DLL’s gekend zijn kan de aanvaller beginnen met de gebruikte symbolen te achterhalen. Deze
stap zou via een gelijkaardige procedure gebeuren binnen een gelijkaardig tijdsbestek. Het
toevoegen van salts kan wel helpen om van eventuele botsingen tussen de hashwaardes van
de DLL-namen en symboolnamen binnen een DLL te voorkomen.
Het is dus mogelijk om met enige moeite de meta-informatie toch nog te reconstrueren
en aan statische analyse te doen. Een mogelijke uitbreiding om dit te vermijden is om de
ge¨encrypteerde meta-informatie nogmaals te encrypteren d.m.v. white-box cryptografie [59].
De ge¨encrypteerde meta-informatie zal dan nooit volledig zichtbaar zijn in het geheugen, en
deze observeren gaat enkel via dynamische analyse.
3.4.2
Uitbreiden ondersteuning uitvoerbare bestanden
In de huidige implementatie is er nog geen ondersteuning voor uitvoerbare bestanden die
aan import via ordinaal doen of die variabelen importeren, omdat dit eigenschappen zijn van
het PE-formaat die niet vaak gebruikt worden. Om alle uitvoerbare bestanden te kunnen
herschrijven, zouden deze eigenschappen wel ondersteund moeten worden. Lichte aanpassingen in DYNIMP-tabel en de glue code zouden volstaan om ook import via ordinaal te
ondersteunen.
Momenteel wordt enkel het importeren van functies ondersteund. Het adres van een ge¨ımporteerde
functie kan maar in drie instructies gebruikt worden: een call, een jmp, of een mov. In het
laatste geval wordt het adres in een register geplaatst voor snellere toegang, wat voordelig is
als de functie vaker opgeroepen zal worden. Een ge¨ımporteerde variabele kan echter in zeer
veel instructies gebruikt worden: inc, dec, add, sub, mul, imul, div, idiv, or, xor, cmp, et
cetera. Voor al deze gevallen zou nog ondersteuning geschreven moeten worden.
3.4.3
Dynamische aanvallen
De applicatie is natuurlijk nog altijd kwetsbaar voor dynamische analyse via hooking. Daarnaast zijn er ook een aantal dynamische aanvallen die het mogelijk maken de meta-informatie
te reconstrueren. Als de applicatie lang genoeg aan het uitvoeren is, zullen de adressen
van – het merendeel van – de ge¨ımporteerde symbolen berekend zijn. Een geheugendump
van de applicatie op dit moment stelt een aanvaller dus – mits enige moeite – in staat de
symbooladressen te achterhalen uit de herschreven oproepen naar de laadfunctie. Van deze
symbooladressen worden dan vervolgens de bijhorende symbolen afgeleid, voor gebruik bij
statische analyse. Een mogelijke manier om dit tegen te gaan zou zijn om een mechanisme
te implementeren waarbij de instructies die gebruik maken van ge¨ımporteerde symbolen tijdens de uitvoering periodiek terug herschreven worden naar oproepen naar de laadfunctie.
In het extreme geval worden deze instructies zelfs nooit herschreven door de laadfunctie. De
laadfunctie wordt dan elke keer opgeroepen en zal dan instaan voor het uitvoeren van de
benodigde instructie alvorens terug te keren. Dit alles komt de prestatie van de applicatie
echter niet ten goede.
Het is ook mogelijk voor een aanvaller om de ge¨ımporteerde symbolen te achterhalen zonder
38
de applicatie volledig uit te voeren. Door middel van reverse engineering kan het adres van
de laadfunctie achterhaald worden, en via statische analyse kunnen alle oproepen naar de
laadfunctie (en hun terugkeeradres) gevonden worden. Als een aanvaller eerst de initialisatiefunctie laat uitvoeren en dan de laadfunctie voor elk terugkeeradres laat oproepen, wordt de
laadfunctie gebruikt om de ge¨ımporteerde symbolen voor de aanvaller te vinden. Dit vereist
natuurlijk wel dat er een aantal aanpassingen aan het uitvoerbaar bestand gebeuren.
Om ook de kwetsbaarheid ten opzichte van deze aanvallen (en dynamische analyse) te verminderen, moeten we in het geheel af van het gebruik van dynamische linken en een applicatie
cre¨eren die slechts uit ´e´en component bestaat. Dit is dan ook wat we zullen doen in Hoofdstuk 4.
39
Hoofdstuk 4
Statisch linken
Om dynamische analyse tegen te gaan willen we uitvoerbare bestanden zo herschrijven dat
ze niet meer afhankelijk zijn van andere componenten (behalve de kernel). In dit hoofdstuk
bespreken we de methode van het statisch linken, die exact dat als doel heeft. De herschreven uitvoerbare bestanden zijn slechts compatibel met ´e´en versie van Windows, namelijk
die versie waarop ze door Diablo gemaakt zijn. Een methode om ze compatibel te maken
met meerdere versies van Windows wordt later besproken in Hoofdstuk 5. Eerst worden de
verschillende stappen in de methode van het statisch linken overlopen, vervolgens bespreken
we partieel statisch linken, en we eindigen met de beperkingen en mogelijke uitbreidingen
van de methode.
4.1
Toevoegen van DLL’s
We willen een herschreven uitvoerbaar bestand cre¨eren dat enkel (rechtstreeks) interageert
met de kernel en niet afhankelijk is van DLL’s. Aangezien het oorspronkelijk uitvoerbaar
bestand natuurlijk wel afhankelijk is van DLL’s moeten we een manier vinden om de delen
die we nodig hebben uit deze DLL’s aan het uitvoerbaar bestand toe te voegen. Een DLL toevoegen gebeurt in Diablo door bij het parent-object (dat het uitvoerbaar bestand voorstelt)
een extra objectbestand (dat de DLL voorstelt) bij te linken. De eerste stap is natuurlijk te
bepalen welke DLL’s aan het uitvoerbaar bestand toe te voegen.
4.1.1
Bepalen van de benodigde DLL’s
De importtabellen van het uitvoerbaar bestand worden bekeken en de DLL’s waarvan het
uitvoerbaar bestand rechtstreeks afhankelijk is worden bepaald. Deze DLL’s worden aan een
lijst van benodigde DLL’s toegevoegd, de DLL’s uit deze lijst worden vervolgens ´e´en voor
´e´en als objectbestand ingelezen en aan het parent-object toegevoegd. Voor elke toegevoegde
DLL worden de importtabellen ook bekeken en de DLL’s waarvan het afhankelijk is (en
waarvan het uitvoerbaar bestand dus eventueel indirect afhankelijk is) bepaald en aan de
lijst van benodigde DLL’s toegevoegd. Het is mogelijk dat de delen die we nodig hebben
uit een bepaalde DLL (de delen die geassocieerd zijn met de uit die DLL ge¨ımporteerde
symbolen) geen uit andere DLL’s ge¨ımporteerde symbolen gebruiken, en dus eigenlijk niet
afhankelijk zijn van enige andere DLL. Dit is echter nog niet geweten op het moment dat we
proberen te bepalen van welke DLL’s het uitvoerbaar bestand (direct of indirect) afhankelijk
is. Daarom worden alle DLL’s waarvan het uitvoerbaar bestand eventueel afhankelijk is aan
40
het bestand toegevoegd, en de lijst van benodigde DLL’s bestaat dus niet per se uit DLL’s
die echt benodigd zijn, maar eerder uit DLL’s die eventueel benodigd zijn.
Bij het bepalen van de benodigde DLL’s moet natuurlijk ook rekening gehouden worden met
export forwarding (zie Sectie 2.5.1) en het API-set-schema (zie Sectie 2.6.2). Indien we een
symbool uit een DLL willen importeren dat eigenlijk doorverwezen wordt, dan is de DLL
waarnaar het doorverwezen wordt ook benodigd. Indien we een een symbool importeren uit
een virtuele DLL, dan is de bijhorende logische DLL benodigd.
In het geval dat het uitvoerbaar bestand afhankelijk is van kernel32 – zie Figuur 2.11 – zullen
naast kernel32 ook KernelBase en ntdll aan het bestand worden toegevoegd. Is het bestand
afhankelijk van bijvoorbeeld user32 dan zullen alle op de figuur aanwezige DLL’s aan het
bestand worden toegevoegd. Deze DLL’s bevatten veel code en data die in de applicatie
eigenlijk niet gebruikt wordt, omdat ze geassocieerd is aan symbolen die het oorspronkelijk
uitvoerbaar bestand niet importeerde. Het is zelfs mogelijk dat er DLL’s toegevoegd worden
waaruit de applicatie niets nodig heeft. In Sectie 4.4 wordt er besproken hoe we zo veel
mogelijk van deze overbodige code en data verwijderen.
4.1.2
Reconstrueren van relocaties
Alvorens het objectbestand dat de DLL voorstelt bij het parent-object bij gelinkt wordt,
wordt er nog een extra bewerking uitgevoerd. Er bestaan namelijk referenties die van ´e´en
sectie naar een andere sectie binnen een DLL gaan (voor een voorbeeld van zo’n referentie
zie Figuur 2.10). Als een DLL (of delen ervan) aan een uitvoerbaar bestand toegevoegd
wordt, moeten de referenties tussen de toegevoegde secties behouden blijven om te verzekeren
dat de toegevoegde delen correct blijven functioneren. Daarom moeten we een beeld van
deze referenties opbouwen. De enige informatie uit het PE-formaat die we hiervoor kunnen
gebruiken zijn de base relocaties (zie Sectie 2.5.3).
Een base relocatie wijst steeds naar een locatie binnen een sectie van een PE-bestand waarop
er een absoluut adres te vinden is. Deze absolute adressen wijzen naar een adres in een
tweede sectie van het bestand. Deze twee secties zijn meestal verschillend maar ze kunnen
ook dezelfde zijn, in welk geval het een interne referentie is. Voor elke base relocatie bepalen
we in Diablo deze twee secties en voegen aan de relocatie-informatie die Diablo bijhoudt een
relocatie toe die van het juiste adres in de eerste sectie naar het juiste adres in de tweede
sectie wijst. Alle relocaties tussen secties (en ook sommigen binnen secties) worden op deze
manier gereconstrueerd.
4.2
Disassembleren
Eens alle eventueel benodigde DLL’s aan het uitvoerbaar bestand zijn toegevoegd, begint Diablo de .text-secties te disassembleren en de ACVG te construeren. Om de .text-secties van
systeembibliotheken op een correcte manier te disassembleren moesten er echter een aantal
aanpassingen gebeuren in Diablo. In alle systeembibliotheken (behalve kernel32) is het namelijk zo dat de data die gewoonlijk aanwezig is in de .rdata-sectie, in de .text-sectie is geplaatst.
41
Deze data staat niet gewoon op het einde van de .text-sectie, maar is door de hele sectie verspreid. Daarnaast plaatst Visual Studio (de IDE waarmee de meeste Windows-applicaties
en ook de systeembibliotheken gemaakt worden) ook alle sprongtabellen (zie verder) in de
.text-sectie, in tegenstelling tot andere compilers die deze in de .rdata-sectie plaatsen.
Om correct met al deze data in de .text-secties om te gaan, moeten deze recursief gedisassembleerd worden (zie Sectie 2.3.2). Diablo bezat echter enkel functionaliteit om lineair te
disassembleren, en daarom heb ik ondersteuning geschreven voor recursief disassembleren.
Enkel .text-secties afkomstig uit DLL’s worden recursief gedisassembleerd. Zoals besproken
in Sectie 2.3.2 kan er niet altijd een perfect onderscheid tussen code en data gemaakt worden. Tenzij een bestand geobfusceerd is met als specifiek doel het belemmeren van recursief
disassembleren kunnen we er wel van uitgaan dat er geen data verkeerdelijk als code herkend
is. Vanwege indirect controleverloop zal er wel veel code als data herkend worden, dit veroorzaakt een probleem dat we in Sectie 4.3 zullen bespreken. Een mogelijke oplossing wordt
besproken in Sectie 4.7.3.
4.2.1
Implementatie van recursief disassembleren
Het is mogelijk dat een PE-bestand meerdere .text-secties bevat. In Diablo worden secties
afzonderlijk gedisassembleerd. Bij het recursief disassembleren is dit echter niet wenselijk,
omdat we bij het volgen van het controleverloop mogelijk bij een instructie in een andere .textsectie terecht zouden komen. Omdat secties afzonderlijk worden gedisassembleerd zouden we
het controleverloop niet kunnen volgen naar een andere sectie en zou de code in deze sectie
dus mogelijkerwijs niet gedisassembleerd worden. Om dit te vermijden wordt er (voor het
disassembleren) voor gezorgd dat er maar ´e´en .text-sectie meer aanwezig is in de DLL, dit
door alle .text-secties (indien er meerdere zijn) samen te voegen tot ´e´en sectie.
De adressen waarop we beginnen te disassembleren zijn die van de initialisatieroutine en de
ge¨exporteerde functies. Het is niet mogelijk om aan de hand van enkel het PE-bestand te
beslissen welke ge¨exporteerde symbolen functies zijn en welke variabelen zijn. Daarom wordt
er in Diablo een lijst gebruikt met alle door systeembibliotheken ge¨exporteerde symbolen
waarvan we uit ervaring weten dat ze variabelen zijn. Bij het disassembleren wordt er in deze
lijst opgezocht of een ge¨exporteerd symbool een variabele is of niet. Momenteel bevat deze
lijst nog maar ´e´en symbool.
Voor elk adres van een ge¨exporteerde functie of van de initialisatieroutine roepen we een functie op die lineair begint te disassembleren tot ze een reeds gedisassembleerde instructie tegenkomt, of een controleverloopinstructie disassembleert. Indien de controleverloopinstructie een
return-instructie is of een instructie die de uitvoering laat stoppen (zoals een interrupt), dan
stopt de disassembleerfunctie met disassembleren. Indien het een controleverloopinstructie
is die naar een andere plaats in de applicatie kan gaan, dan volgen we deze door de functie
recursief op te roepen met het doeladres als argument. Dit laatste doen we enkel in geval
van direct controleverloop aangezien het doel van indirect controleverloop niet gekend is. Het
doel zou eventueel nog via constantenpropagatie berekend kunnen worden, maar dit is niet
ge¨ımplementeerd.
42
Nadat alle instructies – in de mate van het mogelijke – gedisassembleerd zijn, wordt de rest
van de sectie in Diablo gekenmerkt als data. Voor elke locatie waarop er geen instructie
herkend is, zal Diablo een data-instructie genereren. Zo’n instructie is ´e´en byte groot en geeft
aan dat er op dat adres data aanwezig is. Als er op een later moment BBL’s gemaakt worden,
vormt elk contigu bereik van data-instructies ´e´en data-BBL.
4.2.2
Sprongtabellen
Indirect controleverloop kan doorgaans niet gevolgd worden bij het recursief disassembleren. Er is echter ´e´en vorm van indirect controleverloop dat we wel kunnen volgen, namelijk
hetgeen dat te maken heeft met sprongtabellen. Zo’n tabel bestaat uit een aantal adressen
waarheen gesprongen kan worden vanaf een indirecte jmp-instructie. Dit wordt gebruikt bij
het implementeren van switch-statements. Een voor een switch-statement gegenereerde, indirecte jmp-instructie kan er bijvoorbeeld als volgt uitzien: jmp [sprongtabel + 4 · case]. Hier
is sprongtabel het adres van de sprongtabel, 4 de lengte van een adres in bytes en case de
index in de tabel die overeenkomt met de specifieke case.
Sprongtabellen worden gevonden door mogelijke instructiepatronen die wijzen op de implementatie van een switch-statement te herkennen. Deze patronen eindigen altijd in een
indirecte jmp-instructie. Eens gevonden, wordt de disassembleerfunctie voor elk adres binnen de sprongtabel opgeroepen. Zo slagen we erin ook dit indirect controleverloop te volgen.
Doordat het vinden van sprongtabellen steunt op het herkennen van mogelijke patronen worden sommige sprongtabellen niet gevonden (bv. diegenen die geassocieerd zijn met ongekende
patronen en andere compilers).
De sprongtabellen zelf worden herkend als zijnde data in de .text-sectie en komen dus terecht
in data-BBL’s. Voor het verwijderen van overbodige code en data in Sectie 4.4 is het voordelig
als een data-BBL dat een sprongtabel bevat enkel die sprongtabel bevat. Daarom worden
de nodige aanpassingen gemaakt zodat eventuele data gelegen voor de sprongtabel in een
afzonderlijk data-BBL terechtkomt, en hetzelfde gebeurt voor eventuele data gelegen na de
sprongtabel.
4.3
Statisch linken van dynamisch gelinkte bestanden
In de vorige secties werd besproken hoe de benodigde DLL’s als objectbestanden aan het
parent-object werden toegevoegd en vervolgens de .text-secties van de toegevoegde DLL’s
en het uitvoerbaar bestand werden gedisassembleerd. Eens dat gebeurd is bouwt Diablo
een ACVG op die we gaan aanpassen. Omdat functies die niet bereikbaar zijn vanaf het beginknoop van de applicatie niet door Diablo herkend worden, gebruiken we de force reachablevlag op elke ge¨exporteerde functie die we nodig hebben (net als in Sectie 3.3.1). Omdat het
uitvoerbaar bestand en de DLL’s van elkaars functionaliteit gebruik maken via dynamisch
linken zijn er geen relocaties tussen secties afkomstig uit verschillende bestanden, en bevat de
opgebouwde ACVG geen verbindingen tussen de deelgrafen die deze verschillende bestanden
voorstellen. Om verbindingen te cre¨eren tussen deze niet onderling verbonden deelgrafen –
en alle bestanden feitelijk statisch te linken – moet elk dynamisch gebruik van een symbool
43
Figuur 4.1: Een voorbeeld van een relocatie op een data-instructie.
aangepast worden naar een statisch gebruik van het symbool.
Het bepalen van alle instructies die een dynamisch symbool gebruiken gebeurt analoog aan
de manier waarop dit bij het encrypteren van de meta-informatie in Sectie 3.3.1 plaatsvindt.
De relocatie-informatie bijgehouden in Diablo bestaat op dit moment niet enkel uit relocaties
binnen het oorspronkelijke uitvoerbare bestand maar ook uit relocaties binnen de toegevoegde
DLL’s. We lopen over alle relocaties en zoeken die relocaties die naar ´e´en van de IAT’s (elke
toegevoegde DLL kan ook een IAT hebben) wijzen. Deze relocaties zijn afkomstig van de
gezochte instructies, maar aangezien bij het recursief disassembleren niet alle instructies
herkend werden, is het mogelijk dat sommige van deze instructies data-instructies zijn.
Elke gevonden instructie (met als ´e´en van de operanden een adres in een IAT) zal aangepast worden om direct gebruik te maken van het adres van het corresponderende symbool,
behalve wanneer het een data-instructie is. Op Figuur 4.1 zien we een voorbeeld van zo’n
data-instructie waarvan een relocatie komt die naar de IAT wijst. Deze instructie is de eerste
van vier data-instructies die eigenlijk een adres binnen de IAT bevatten (0x00404018 in het
voorbeeld). De opcode-bytes van de eigenlijke instructie waarvan dit adres een operand bestaan uit data-instructies gelegen voor de instructie met de relocatie. Gezien deze eigenlijke
instructie niet gedisassembleerd is, kennen we zijn type noch de lengte van de opcode. De
instructie op dit moment in het proces nog proberen te disassembleren is niet gegarandeerd
om het juiste resultaat te geven. We weten namelijk niet of we de opcode van de eigenlijke
instructie bestaat uit ´e´en, twee of meerdere bytes. We kunnen de eigenlijke instructie dus niet
aanpassen, en relocaties komende van data-instructies worden daarom in de huidige implementatie gewoon verwijderd. Mocht deze instructie tijdens de uitvoering van de herschreven
applicatie toch uitgevoerd worden zou dit tot een fout leiden. Een mogelijke oplossing voor
dit probleem wordt voorgesteld in Sectie 4.7.3.
Elke echte instructie die gevonden wordt, wordt wel aangepast. Eerst wordt het gebruikte
ge¨ımporteerde symbool gevonden aan de hand van de locatie in de IAT waar de relocatie naar wijst. Met behulp van het ge¨ımporteerde symbool zoeken we het overeenkomstige
ge¨exporteerde symbool (waarvan de definitie aanwezig is in een toegevoegde DLL). Hierbij
wordt natuurlijk rekening gehouden met export forwarding en het API-set-schema, en zowel
44
import via naam als via ordinaal worden ondersteund. Eens het ge¨exporteerde symbool gevonden is, wordt er een statische verbinding gemaakt tussen het adres van het symbool en
de instructie die het gebruikt.
Er zijn twee manieren waarop deze verbinding gemaakt kan worden. Indien de instructie een
call of een jmp is, wordt de controleverloopgraaf aangepast zodat er een passende pijl van het
instructie-BBL naar het BBL geassocieerd aan het ge¨exporteerd symbool gaat. Dit zorgt er
ook voor dat de instructie aangepast wordt om direct in plaats van indirect gebruik te maken
van het operand. In de andere gevallen (indien het functie-adres als data gebruikt wordt, of
het symbool een variabele is) worden er geen aanpassingen gemaakt in de controleverloopgraaf. De relocatie zelf wordt aangepast om rechtstreeks naar het adres van het ge¨exporteerd
symbool te wijzen (in plaats van naar de IAT), en de instructie wordt aangepast van een
indirect naar een direct gebruik van het operand.
Op het einde van deze fase zijn de symbolen die van tevoren dynamisch gevonden werden nu
al gevonden, en zijn de nodige verbindingen tussen het oorspronkelijk uitvoerbaar bestand en
de toegevoegde DLL’s (onderling) gemaakt. De indirectie die aanwezig was om het gebruik
van dynamische symbolen mogelijk te maken is verdwenen, en er zijn geen relocaties meer
aanwezig die naar een IAT wijzen. Dit laatste is enkel zo omdat ook relocaties die van datainstructies kwamen verwijderd zijn.
4.4
Verwijderen van overbodige code en data
Het verwijderen van de overbodige uit DLL’s afkomstige code en data komt eigenlijk neer
op het elimineren van onbereikbare code en data (zie Sectie 2.2.3). Nadat alle nodige verbindingen gemaakt zijn, maken we dan ook gebruik van deze functionaliteit om de knopen
die niet verbonden zijn met de beginknoop (en dus niet gebruikt worden) uit de ACVG te
verwijderen. Na deze operatie zal er echter nog steeds veel overbodige code en data aanwezig
zijn.
Een DLL is – net als een uitvoerbaar bestand – linker-uitvoer. Alle adressen van symbolen
binnen het bestand zijn reeds berekend, met als gevolg dat er symboolinformatie (behalve over
dynamische symbolen) noch relocatie-informatie (behalve base relocaties) in afzonderlijke
structuren aanwezig is. Deze informatie wordt normaal gezien door Diablo gereconstrueerd
door het linkerproces te emuleren, en vervolgens gebruikt om een nauwkeurige representatie
van de interne afhankelijkheden van een bestand op te bouwen (zie Sectie 2.2.1). Omdat
we niet beschikken over de objectbestanden waaruit de toegevoegde DLL’s zijn opgebouwd
(laat staan de bijhorende linker maps), kunnen we het linkerproces voor deze DLL’s niet
emuleren. We kunnen enkel de relevante informatie die aanwezig is in het PE-formaat (de
base relocaties en de informatie over dynamische symbolen) gebruiken, en bijgevolg is de
opgebouwde representatie veel minder nauwkeurig dan normaal gezien. Het is dit gebrek aan
nauwkeurigheid in de representatie van de toegevoegde DLL’s die ons parten speelt bij het
verwijderen van overbodige code en data.
Van de data-secties afkomstig uit het uitvoerbaar bestand is geweten uit welke subsecties
45
(afkomstig uit de objectbestanden) deze zijn opgebouwd. Er wordt dus voor al deze subsecties
afzonderlijk gekeken of deze verbonden zijn met de beginknoop (en dus of ze verwijderd
kunnen worden). Voor de data-secties afkomstig uit toegevoegde DLL’s is dit niet het geval.
Deze bevatten slechts ´e´en subsectie (die qua inhoud gelijk is aan zijn parent-sectie) en er is
niets geweten over de oorspronkelijke subsecties waaruit ze zijn opgebouwd. Bijgevolg is het
zo dat er in realiteit subsecties zijn die niet verbonden zijn met de beginknoop (omdat deze
bijvoorbeeld bestaan uit data geassocieerd aan een niet-gebruikte ge¨exporteerde functie) en
dus eigenlijk verwijderd zouden kunnen worden, maar waarvan we niet weten dat ze bestaan.
Deze subsecties kunnen ook – als enige – verbonden zijn met andere subsecties of BBL’s
(in geval van functie-pointers in een data-sectie) die eigenlijk ook verwijderd zouden kunnen
worden, maar ook dit is niet mogelijk wegens het gebrek aan nauwkeurigheid.
Daarnaast leidt het recursief disassembleren ook tot onnauwkeurigheid. Alle bytes in een
.text-sectie die niet als onderdeel van een instructie zijn herkend, zijn gekenmerkt als data
en zitten in data-BBL’s. Deze data-BBL’s bestaan uit contigue geheugenbereiken die normaliter begrensd worden door echte BBL’s. Ze kunnen dus bestaan uit meerdere niet gedisassembleerde functies (of delen ervan) en data-subsecties die samengevoegd zijn. Om deze
nauwkeurigheid – enigszins – te verbeteren zijn alle sprongtabellen (waarvan we weten dat
ze eigenlijk afzonderlijke subsecties zijn) in afzonderlijke data-BBL’s geplaatst.
4.5
Initialisatieroutines
Eens een DLL in het geheugen geladen is wordt er – indien aanwezig – een initialisatieroutine
uitgevoerd [60][61]. Deze routine wordt niet alleen opgeroepen als een DLL aan een proces
wordt toegevoegd maar ook als ze eruit verwijderd wordt. Dit verwijderen gebeurt als het
proces eindigt, maar kan ook gebeuren tijdens de uitvoering (de DLL wordt dan gelost). Ook
voor elke nieuwe thread die start en elke oude thread die eindigt wordt de initialisatieroutine
opgeroepen. De context waarin ze opgeroepen wordt kan afgeleid worden van de argumenten,
en voor elk van deze situaties kan er verschillende code uitgevoerd worden. Op deze manier
wordt er aan initialisatie en finalisatie van een DLL gedaan, en is het mogelijk om Thread
Local Storage (TLS) te voorzien [62].
Er moet bij het inlijven van delen van een DLL bij het uitvoerbaar bestand voor gezorgd
worden dat de bijhorende initialisatieroutine op de juiste momenten aangeroepen wordt. In
de huidige implementatie wordt deze enkel aangeroepen bij het opstarten van de applicatie.
Er wordt voor gezorgd dat alle initialisatieroutines gevonden worden als functie door Diablo
(m.b.v. de force reachable-vlag), en aan de lijst met uit te voeren initialisatieroutines toegevoegd worden. Er wordt extra code toegevoegd die als nieuw beginpunt van de applicatie zal
dienen en deze initialisatieroutines met de juiste argumenten zal aanroepen.
De initialisatieroutine voor een DLL zou idealiter enkel aangeroepen worden indien de data
die ge¨ınitialiseerd wordt ook daadwerkelijk gebruikt wordt in de delen van de DLL die we
willen bijhouden. Het is echter moeilijk om dit te bepalen en daarnaast is het mogelijk dat de
routine functies oproept die een neveneffect hebben. Daarom verkiezen we om – zodra er ook
maar iets uit een DLL gebruikt wordt in het uiteindelijke bestand – haar initialisatieroutine bij
46
te houden, met als gevolg dat ook alle code en data geassocieerd aan die initialisatieroutine
niet verwijderd worden. We hebben echter in Sectie 4.1.1 gezien dat we niet van tevoren
weten of een DLL echt nodig is of niet, en in de huidige implementatie worden dus alle
initialisatieroutines (en verwante code en data) bijgehouden en uitgevoerd. Een mogelijke
uitbreiding die dit probleem oplost wordt besproken in Sectie 4.7.1.
4.6
Partieel statisch linken
Een volledig statisch gelinkt uitvoerbaar bestand dat gebruik maakt van systeemoproepen
zal normaal gezien enkel werken op de versie van Windows waarvoor het gelinkt is. Hoofdstuk 5 presenteert een methode die een volledig statisch applicatie compatibel maakt met
meerdere versies van Windows, maar in deze sectie bespreken we een tussenoplossing die
ge¨ımplementeerd werd: partieel statisch linken. Dit houdt in dat Diablo een uitvoerbaar
bestand genereert waarin alle niet-systeemspecifieke DLL’s zijn toegevoegd, waardoor het
bestand enkel nog maar afhankelijk is van de Windows API (t.t.z. de Win32-bibliotheken).
Het gebruik van deze API wordt dan verborgen via het encrypteren van meta-informatie.
Het bepalen van de nog uit Win32-bibliotheken te importeren symbolen gebeurt door (na
het statisch linken) alle relocaties te overlopen en diegene te zoeken die nog steeds naar een
IAT wijzen.
Als we geen Win32-bibliotheken toevoegen aan het uitvoerbaar bestand zijn er een aantal
moeilijkheden die we – meestal – kunnen vermijden: het API-set-schema, export forwarding,
de aanwezigheid van read-only data in de .text-sectie, en natuurlijk de aanwezigheid van systeemoproepen in het uitvoerbaar bestand. Om de meta-informatie te encrypteren gebruiken
we de methode voorgesteld in Hoofdstuk 3. Deze voegt glue code toe aan het bestand, we
gebruiken de initialisatiefunctie uit deze glue code om de mogelijke initialisatieroutines van
de toegevoegde DLL’s op te roepen.
Indien het oorspronkelijk uitvoerbaar bestand enkel gebruik maakt van Win32-bibliotheken is
er geen verschil tussen het encrypteren van meta-informatie en partieel statisch linken. Deze
tussenoplossing is dan ook enkel van nut indien er een DLL gebruikt wordt in de applicatie die
ontwikkeld werd door een derde partij. Delen van een zelf-ontwikkelde DLL zouden namelijk
beter op broncode-niveau aan het uitvoerbaar bestand toegevoegd kunnen worden.
4.7
4.7.1
Beperkingen en mogelijke uitbreidingen
Iteratief bepalen van benodigde DLL’s
In de huidige implementatie worden alle DLL’s toegevoegd waarvan het te herschrijven uitvoerbaar bestand eventueel afhankelijk is alvorens een ACVG op te bouwen en te bepalen
welke delen uit deze DLL’s we eigenlijk nodig hebben. Op deze manier worden er mogelijkerwijs DLL’s toegevoegd die uiteindelijk helemaal niet gebruikt blijken te worden. Dit is al bij
een aantal eenvoudige voorbeeldapplicaties gebleken, en is ook mogelijk bij meer ingewikkelde
applicaties. Indien een onnodige DLL een initialisatieroutine heeft, zal deze (samen met geassocieerde code en data) echter wel aanwezig zijn in het uiteindelijk uitvoerbaar bestand. Een
mogelijke uitbreiding van de huidige implementatie die het toevoegen van onnodige DLL’s
47
Figuur 4.2: Een voorbeeld van het gebruik van een afhankelijkheidsgraaf.
(op enkele uitzonderingen na) vermijdt, is om ze ´e´en voor ´e´en toe te voegen en voor elke DLL
afzonderlijk te bepalen welke delen eruit eigenlijk benodigd zijn. Dit zal het probleem met
de initialisatieroutines oplossen en de prestatie van de implementatie verbeteren.
Om de DLL’s iteratief toe te kunnen voegen moet er eerst een afhankelijkheidsgraaf opgesteld
worden die de afhankelijkheden tussen DLL’s voorstelt. Het opstellen van deze graaf wordt
dan de nieuwe eerste stap van de methode en wordt uitgevoerd in plaats van het bepalen
van de benodigde DLL’s. Dit opstellen gebeurt aan de hand van de importtabellen van de
DLL’s, en houdt rekening met export forwarding en het API-set-schema. Het uitvoerbaar
bestand wordt de beginknoop van de graaf, en elke DLL is bereikbaar vanaf deze knoop
(voor een voorbeeld van zo’n afhankelijkheidsgraaf, zie Figuur 4.2). Eens de graaf opgesteld is,
beginnen we met het toevoegen van DLL’s. We kiezen een DLL waarvan enkel het uitvoerbaar
bestand afhankelijk is, voegen deze toe, bouwen een ACVG op en verwijderen de onnodige
delen van de DLL. Alvorens de ACVG terug om te zetten naar gewone secties, passen we
de afhankelijkheidsgraaf aan. De net toegevoegde DLL wordt uit de graaf verwijderd en
nieuwe afhankelijkheden tussen het uitvoerbaar bestand en DLL’s (afkomstig van de nieuw
toegevoegde delen) worden aangebracht. Indien een knoop niet meer bereikbaar is vanaf de
beginknoop wordt deze uit de graaf verwijderd. Als de hele procedure doorlopen is en we
terug over gewone secties beschikken, kiezen we weer een DLL waarvan enkel het uitvoerbaar
bestand afhankelijk is, voegen deze toe etc. tot er geen DLL’s meer overblijven in de graaf.
In het voorbeeld op Figuur 4.2 wordt eerst DLL1 toegevoegd. Hierdoor wordt het uitvoerbaar
bestand afhankelijk van DLL2, dat vervolgens toegevoegd wordt. Beide DLL’s zijn afhankelijk
van DLL3, maar geen van de toegevoegde delen uit de eerste twee DLL’s is eigenlijk afhankelijk van DLL3. Bijgevolg wordt deze DLL niet toegevoegd, en belandt zijn initialisatieroutine
dus niet in het herschreven uitvoerbaar bestand.
Twee of meer DLL’s die van elkaar afhankelijk zijn (bv. user32 en gdi32 op Figuur 2.11)
vormen een uitzonderingsgeval. Deze vormen een cyclische deelgraaf die wel als ´e´en knoop
48
beschouwen en moeten aan het uitvoerbaar bestand tegelijkertijd toegevoegd worden. Deze
gevallen kunnen weer leiden tot initialisatieroutines die bijgehouden worden zonder dat de
bijhorende DLL eigenlijk gebruikt wordt, maar in de praktijk verwachten we geen al te complexe afhankelijkheidsgrafen omdat dit tegengesteld is aan de best practices op vlak van
softwarearchitectuur. Een blik op de architectuur van de systeembibliotheken en de architectuur van een aantal applicaties (VLC Media Player, Internet Explorer en Word) heeft deze
verwachtingen bevestigd.
4.7.2
Opsplitsen data-secties
We zouden liefst een nauwkeurigere representatie van de data-secties hebben. Een data-sectie
kan namelijk opgedeeld worden in de subsecties waaruit ze oorspronkelijk is opgebouwd, maar
bij de toegevoegde DLL’s ontbreekt de informatie om dit te doen. Indien er structuren in deze
secties aanwezig zijn die we kennen (bv. export- en importtabellen) kunnen we deze secties
wel in drie opsplitsen: ´e´en deel voor de gekende structuur, ´e´en deel erna, en de structuur zelf.
Export- of importtabellen kunnen gewoon verwijderd worden omdat deze niet meer gebruikt
worden.
4.7.3
Onderscheid code en data
Zoals gezegd in Sectie 2.3.2 kan er in principe geen perfect onderscheid gemaakt worden
tussen code en data. Onder bepaalde voorwaarden is dit echter wel mogelijk. Indien we er
bijvoorbeeld van uit kunnen gaan dat de gebruikte toolchain geen data in de .text-secties
van het bestand zal plaatsen moet er geen onderscheid gemaakt worden tussen code en data
en volstaat lineair disassembleren. In het geval van Visual Studio weten we dat de enige
data die normaal gezien in de .text-secties geplaatst wordt, bestaat uit sprongtabellen. Een
verbeterde versie van lineair disassembleren die alle sprongtabellen kan herkennen is ook in
staat om een perfect onderscheid te maken tussen code en data. De implementatie van lineair
disassembleren aanwezig in Diablo was hier niet toe in staat omdat ervan uitgegaan werd dat
sprongtabellen zich in .rdata-secties bevonden. Deze werd in het kader van deze masterproef
wel uitgebreid om sprongtabellen in de .text-secties te herkennen en kan dus – behalve indien
er gebruik gemaakt wordt van een onbekend sprongtabel-patroon – een perfect onderscheid
maken.
Bij de systeembibliotheken is er – per uitzondering – in de .text-secties ook read-only data
aanwezig naast de sprongtabellen. Een implementatie van recursief disassembleren werd geschreven om zo goed mogelijk code en data te onderscheiden, maar deze is niet perfect. Een
garantie op het dynamisch maken van een perfect onderscheid kan in dit geval niet gegeven
worden. Het zou wel mogelijk zijn om de .text-secties van de systeembibliotheken eenmalig
te laten disassembleren door IDA Pro (zie Sectie 2.3.3). IDA is namelijk beter in staat is om
code en data te onderscheiden dan de huidige disassembler in Diablo. Het gemaakte onderscheid zou wel nog niet perfect zijn. Eventuele fouten moeten handmatig verbeterd worden
om tot een perfect onderscheid te komen zodat het resultaat opgeslagen kan worden voor
gebruik door Diablo.
IDA Pro zou dus instaan voor het disassembleren van de .text-secties afkomstig uit de sys49
teembibliotheken, en Diablo voor de .text-secties afkomstig uit andere DLL’s en het uitvoerbaar bestand. Voor dit laatste volstaat lineair disassembleren aangevuld met sprongtabelherkenning, behalve voor bestanden die geobfusceerd zijn met als specifiek doel het disassembleren te belemmeren. Dit soort bestanden kan dan ook niet ondersteund worden.
4.7.4
Initialisatie van de systeembibliotheken
Er zijn drie systeembibliotheken die we speciaal behandelen op vlak van initialisatieroutines:
kernel32, KernelBase en ntdll (zie Sectie 2.6). Deze drie DLL’s worden in de adresruimte van
elke applicatie geladen, zelfs indien de applicatie ze niet gebruikt. Het herschreven uitvoerbaar bestand is van geen enkele DLL afhankelijk, maar deze drie DLL’s zullen toch geladen
en ge¨ınitialiseerd worden alvorens de applicatie begint uit te voeren. Er zal nooit gebruik
gemaakt worden van deze geladen DLL’s aangezien de benodigde delen uit deze DLL’s in
het uitvoerbaar bestand zelf aanwezig zijn. De uit deze DLL’s afkomstige delen die aan het
uitvoerbaar bestand zijn toegevoegd moeten natuurlijk wel ge¨ınitialiseerd worden.
De initialisatieroutines moeten in een specifieke volgorde aangeroepen worden: eerst die van
ntdll, dan KernelBase en tot slot kernel32. De initialisatieroutine van kernel32 maakt namelijk gebruik van functies ge¨ımporteerd uit KernelBase en ntdll, en die van KernelBase maakt
gebruik van functies ge¨ımporteerd uit ntdll. In tegenstelling tot bij andere DLL’s (zoals kernel32 en KernelBase) heeft ntdll geen initialisatieroutine die ingesteld staat als beginpunt in
de headers. ntdll exporteert een functie – LdrInitializeThunk – die ntdll initialiseert, maar
deze functie doet eigenlijk veel meer dan enkel ntdll initialiseren [63]. LdrInitializeThunk is
eigenlijk het beginpunt voor alle user-mode threads, en staat dus ook in voor het initialiseren van deze threads, alsook voor het initialiseren van het proces. Al deze initialisatiecode
(voor ntdll, de thread en het proces) is niet duidelijk gescheiden. LdrInitializeThunk in zijn
volledigheid uitvoeren is niet mogelijk vanwege de andere initialisatie die hij probeert uit
te voeren. Het is om deze reden dat deze drie DLL’s niet ge¨ınitialiseerd worden in de huidige implementatie. Een aantal door deze DLL’s ge¨exporteerde functies die vertrouwen op
ge¨ınitialiseerde data werken daarom nog niet.
Idealiter zouden we de stukken uit LdrInitializeThunk (en de functies die deze oproept)
vinden die instaan voor het initialiseren van ntdll en enkel deze stukken uitvoeren, alvorens
de initialisatieroutines van KernelBase en kernel32 uit te voeren. Om deze stukken te vinden
kan de broncode van ReactOS een goede referentie zijn [64]. ReactOS is een open-source
project dat als doel heeft om als vervanging te kunnen dienen voor de Windows NT familie
van besturingssystemen (met compatibiliteit voor applicaties en drivers). Ik heb de broncode
voor de ReactOS implementatie van ntdll en LdrInitializeThunk reeds bekeken en deze kan
zeker als referentie dienen om de Windows-versie beter te begrijpen.
50
Hoofdstuk 5
Compatibiliteit
Een volledig statisch gelinkte applicatie is enkel compatibel met die versie van Windows
waarop ze gelinkt is. Daarom wordt er in dit hoofdstuk een methode voorgesteld om deze
toch compatibel te maken met meerdere versies van Windows. Dit gebeurt door de applicatie
zichzelf dynamisch te laten herschrijven. De applicatie zal zichzelf aanpassen aan de specifieke
kernel die op het systeem aanwezig is. Ten eerste wordt de algemene werking van de methode
voorgesteld, vervolgens wordt er in meer detail gegaan, en als laatste worden de beperkingen
en mogelijke uitbreidingen van de methode besproken.
5.1
Algemene werking
In de huidige implementatie gaan we ervan uit dat de applicatie altijd uitgevoerd wordt in de
WoW64-omgeving (zie Sectie 2.7.5). Eerst ontwikkelen we een methode om compatibiliteit
met zowel Windows 8 als Windows 8.1 te voorzien. Het enige verschil tussen deze twee
versies is dat de SCO’s veranderd zijn, de systeemoproepen gebeuren op dezelfde wijze (zie
Sectie 2.7.1). In Sectie 5.3 wordt de methode uitgebreid om ook compatibiliteit met Windows
7 (waarop systeemoproepen enigszins anders gebeuren) te voorzien.
Om ervoor te zorgen dat een statisch gelinkt uitvoerbaar bestand op meerdere versies van
Windows werkt, moeten de SCW’s in het bestand zichzelf dynamisch kunnen aanpassen
aan een specifieke versie van Windows. Om dit mogelijk te maken wordt er net zoals in
Sectie 3.1 glue code aan het bestand toegevoegd. Deze glue code is gelijkaardig aan die bij
het encrypteren van meta-informatie en bevat ook een initialisatiefunctie en een laadfunctie.
De initialisatiefunctie zal het nieuwe beginpunt voor de applicatie worden, en elke SCW
zal aangepast worden om de laadfunctie op te roepen in plaats van een systeemoproep (of
vervangende instructie) uit te voeren. De laadfunctie past dan de SCW waarvan ze opgeroepen
werd aan, zodat deze nu een systeemoproep doet met de juiste SCO. Hoe we deze SCO bepalen
wordt uitgelegd in Sectie 5.2.2.
5.2
5.2.1
Glue code
Aanpassingen in Diablo
Het toevoegen van de glue code gebeurt op dezelfde wijze als in Sectie 3.3.1. De ACVG
wordt aangepast zodat de initialisatiefunctie het nieuwe beginpunt van de applicatie wordt,
alvorens naar het oorspronkelijke beginpunt van de applicatie te springen. Alle SCW’s worden
51
gevonden door alle door Diablo herkende functies te overlopen en die functies te zoeken
waarvan de naam begint met “Nt”. Op Windows 8/8.1 ziet een SCW uit een WoW64systeembibliotheek er als volgt uit:
mov
call
ret
eax, SCO
large dword ptr fs:0xC0
Na aanpassing door Diablo ziet een SCW er dan als volgt uit:
mov
call
nop
nop
ret
eax, SCW Hash
laadfunctie
SCW Hash is hierin de hash van de naam van de SCW. Deze wordt door de laadfunctie
gebruikt om de bijhorende SCO te vinden. De ‘call laadfunctie’-instructie zal dynamisch
door de laadfunctie terug herschreven worden naar de oorspronkelijke indirecte call-instructie.
Doordat deze instructie gebruik maakt van het fs-segment is ze twee bytes groter. Daarom
worden er na de call-instructie twee padding bytes (NOP-instructies) toegevoegd.
5.2.2
Initialisatiefunctie
De initialisatiefunctie zal – net als bij het encrypteren van meta-informatie – een aantal
variabelen initialiseren die door de rest van de glue code gebruikt worden. Om bijvoorbeeld
de SCW’s dynamisch te kunnen herschrijven moet de geheugenbescherming van een specifiek
geheugenbereik aangepast kunnen worden. Dit kan enkel via een systeemoproep naar de
NtProtectVirtualMemory system service. De bijhorende SCW maakt deel uit van de glue
code, maar om deze uit te kunnen voeren moet eerst de juiste SCO bepaald worden.
Om SCO’s te bepalen maken we gebruik van een hulpfunctie uit de glue code die als argument een gehashte SCW-naam neemt. De huidige implementatie ondersteunt enkel SCW’s
die deel uitmaken van de Native API, en die men dus kan vinden in ntdll. In Sectie 3.3.2
werd er verwezen naar een methode om het adres van kernel32 te vinden. Deze methode
kan ook gebruikt worden om het adres van ntdll te vinden. De hulpfunctie zal – gegeven de
gehashte naam en het adres van ntdll – alle namen in de ENT van ntdll hashen en deze vergelijken met de gehashte naam. Indien deze twee overeenkomen is de gezochte SCW gevonden.
We weten hoe een SCW er uitziet qua instructies, en weten dus dat de SCO (bestaande
uit vier bytes) te vinden valt op het adres van de SCW vermeerderd met ´e´en (de opcode
van de mov-instructie). Er worden dus nooit instructies uit de op het systeem aanwezige
systeembibliotheken uitgevoerd, enkel de SCO’s uit deze bibliotheken worden gebruikt.
52
Naast het initialiseren van een aantal variabelen staat de initialisatiefunctie ook in voor het
oproepen van de initialisatieroutines van de bibliotheken die aan het uitvoerbaar bestand
zijn toegevoegd (zie Sectie 4.5).
5.2.3
Laadfunctie
Om de SCW waarvan ze is opgeroepen te herschrijven, begint de laadfunctie met de juiste
SCO te bepalen m.b.v. de net besproken hulpfunctie en de hash van de SCW-naam. Deze
hashwaarde is net voor de oproep naar de laadfunctie in het eax-register geplaatst. Vervolgens
wordt NtProtectVirtualMemory opgeroepen om het geheugenbereik waarop er geschreven
gaat worden schrijfbaar, leesbaar een uitvoerbaar te maken. De nodige aanpassingen worden
gemaakt en NtProtectVirtualMemory wordt nogmaals opgeroepen om het geheugenbereik
zijn oude geheugenbescherming terug te geven. Aan het einde van de laadfunctie wordt er
terug naar de eerste instructie van de SCW gesprongen, zodat de normale uitvoering van de
applicatie kan hervatten.
Bij het encrypteren van de meta-informatie werd er na het herschrijven de functie FlushInstructionCache uitgevoerd (zie Sectie 3.3.3) omdat zelf-aanpassende code tot problemen met
de instructiecaches kan leiden. Omdat we geen functies willen importeren uit andere DLL’s
zullen we hier geen gebruik maken van deze functie. Op de x86-architectuur moeten de instructiecaches eigenlijk niet geflushed worden na het aanpassen van uitvoerbare code, maar
er moet wel rekening gehouden worden met het feit dat de CPU speculatief code uitvoert [47].
Het uitvoeren van een jmp-instructie alvorens het uitvoeren van herschreven instructies is voldoende om problemen met deze speculatieve uitvoering te vermijden. Aan deze voorwaarde
is voldaan aangezien we op het einde van de laadfunctie naar de eerste instructie van de SCW
springen.
5.3
Windows 7
Op Windows 7 zien SCW’s in een WoW64-omgeving er net iets anders uit. De WoW64-index
maakt geen deel uit van de SCO zoals op Windows 8/8.1, maar wordt afzonderlijk in het
ecx-register geplaatst. Daarnaast wordt het adres van het eerste argument op de stapel in
het edx-register geplaatst, en wordt er een waarde van de stapel gehaald na het uitvoeren
van de systeemoproep:
mov
mov
lea
call
add
ret
eax, SCO
ecx, WoW64 index
edx, [esp+4]
large dword ptr fs:0xC0
esp, 4
Om met deze verschillende manier om de WoW64-laag aan te roepen om te gaan, is de methode op een aantal punten aangepast. Ten eerste wordt op het moment dat Diablo de SCW’s
53
herschrijft ervoor gezorgd dat er voldoende NOP-instructies toegevoegd worden. Zo zal de
laadfunctie in staat zijn de SCW ook in deze stijl te herschrijven indien nodig. Daarnaast is
de initialisatiefunctie aangepast om vast te stellen of de applicatie wordt uitgevoerd op Windows 7. De hulpfunctie voor het bepalen van de SCO’s staat nu ook in voor het afzonderlijk
bepalen van de WoW64-index voor een specifieke SCW.
5.4
5.4.1
Beperkingen en mogelijk uitbreidingen
Grafische systeemoproepen
Momenteel worden enkel systeemoproepen naar system services uit de gewone SSDT ondersteund. Daarnaast bevat de Shadow SSDT de adressen voor grafische system services, en
de gelijknamige SCW’s zijn aanwezig in user32 en gdi32 (zie Sectie 2.7.4). Deze SCW’s zijn
echter moeilijker terug te vinden dan die uit ntdll. Sommigen worden wel ge¨exporteerd, maar
onder een andere naam. Als we user32 disassembleren met IDA Pro blijkt er bijvoorbeeld een
SCW te bestaan met interne naam NtGdiD3dContextCreate, die ge¨exporteerd wordt onder
een andere naam, namelijk DdEntry1. Andere SCW’s worden helemaal niet ge¨exporteerd, en
zijn dus interne functies die enkel vanuit andere ge¨exporteerde functies opgeroepen worden.
Er zijn twee uitbreidingen die moeten gebeuren worden om grafische systeemoproepen te
ondersteunen. Ten eerste moeten de bijhorende SCW’s in Diablo herkend worden zodat we
ze kunnen aanpassen. In de huidige implementatie gebeurt dit door te zoeken naar functies
waarvan de naam begint met ‘Nt’. Enkel functies waarop er een symbool staat krijgen namen in Diablo en de enige symboolinformatie waarover Diablo beschikt bij een toegevoegde
DLL heeft te maken met dynamische symbolen. Dit zorgt er voor dat we momenteel enkel
ge¨exporteerde SCW’s kunnen herkennen. Er zijn twee oplossingen voor dit probleem: het
patroon van een SCW herkennen, of gebruik maken van de onge¨exporteerde symbolen van de
systeembibliotheken via PDB-bestanden. Dit laatste wordt ook gedaan door IDA Pro, mochten we dus IDA gebruiken om de systeembibliotheken te disassembleren (zoals voorgesteld
in Sectie 4.7.3) dan zouden we al over deze symbolen beschikken.
De tweede uitbreiding die moet gebeuren is dat de glue code in staat moet zijn om de SCW’s
terug te vinden in de systeembibliotheken, zelfs als ze niet ge¨exporteerd worden. Een mogelijke
oplossing zou zijn om deze SCW’s op te zoeken via functie die deze SCW’s oproepen, die
wel ge¨exporteerd worden. We zouden in de glue code deze ge¨exporteerde functies kunnen
analyseren en het controleverloop kunnen volgen tot het patroon van een SCW herkend
wordt. In de huidige glue code is er reeds ondersteuning aanwezig om uitvoerbare code te
analyseren.
5.4.2
Verandering structuur SCW
De structuur van SCW’s is veranderd tussen Windows 7 en Windows 8. Eventueel toekomstige
veranderingen in deze structuur kunnen niet voorspeld worden en de glue code kan hier niet
op voorzien worden. Met deze methode kan dus geen compatibiliteit met toekomstige versies
van Windows verzekerd worden.
54
De uitvoerbare bestanden zijn zo herschreven dat er nooit code uitgevoerd wordt die zich niet
in het bestand zelf bevindt. Indien er code uitgevoerd zou worden uit een DLL die dynamisch
gevonden moet worden zou de applicatie kwetsbaar zijn voor hooking. Om compatibiliteit te
voorzien wordt er wel gebruik gemaakt van de SCO’s afkomstig uit die DLL’s. Een mogelijke
aanpassing om betere compatibiliteit met toekomstige versies van Windows te voorzien zou
zijn om in plaats van enkel van deze dynamisch gevonden SCO’s te gebruiken, de volledige
SCW’s te gebruiken. Dit komt weer neer op dynamisch linken met de systeembibliotheken
aanwezig op het systeem waarop de applicatie uitgevoerd wordt. Het gebruik van deze SCW’s
zou gemakkelijk verborgen kunnen worden via het encrypteren van meta-informatie, maar
hooking zou terug een mogelijkheid zijn. De geplaatste hooks zouden zich wel op het laagste niveau van de applicatie bevinden, net boven de kernel. Enkel de communicatie tussen
applicatie en kernel zou dus onderschept kunnen worden.
5.4.3
Veranderingen van system services
Het is mogelijk dat er tussen verschillende versies van Windows definities van system services
(qua argumenten) veranderen, of dat er system services vervangen worden door of samengenomen worden tot andere system services. Dit soort veranderingen vinden niet vaak plaats,
maar met dit soort uitzonderingen moet er wel rekening gehouden worden in de glue code.
Een voorbeeld van zo’n uitzondering vinden we in de functionaliteit die te maken heeft met
consolevensters.
kernel32 exporteert een aantal functies zoals GetConsoleMode, WriteConsoleA en AttachConsole die met consolevensters te maken hebben. In een WoW64-omgeving op Windows 7
zijn die functies eigenlijk SCW’s of roepen ze SCW’s op. Deze SCW’s gebruiken een SCO met
als SST-index 2, wat ons doet vermoeden dat deze gebruik maken van een derde, onbekende
SSDT (waarover ook op het internet niets valt te vinden). Op een 32-bits Windows 7 – net als
in een WoW64-omgeving op Windows 8/8.1 – worden deze functies ge¨ımplementeerd m.b.v.
van een functie (ConsoleClientCallServer genaamd op Windows 7 en ConsoleCallServer genaamd op Windows 8/8.1) die een oproep doet naar de Native API in ntdll.
Nog een voorbeeld van zo’n verandering heeft te maken met het schrijven naar een consolevenster. Hiervoor kan de functie WriteFile uit kernel32 opgeroepen worden met een argument dat aanduid dat er naar het consolevenster geschreven moet worden. Op Windows 7
zal er in de implementatie van WriteFile aan de hand van dit argument beslist worden om
een sprong te maken naar WriteConsoleA dan wel de NtWriteFile-SCW op te roepen. Op
Windows 8/8.1 wordt er geen onderscheid gemaakt tussen deze twee gevallen en gebeurt er
altijd een oproep naar NtWriteFile. Omdat deze functionaliteit gebruikt wordt door de ‘Hello
World!’-testapplicatie, is er in de glue code een oplossing aanwezig voor deze uitzondering.
Op Windows 8/8.1 zal de NtWriteFile-SCW opgeroepen worden en op Windows 7 de SCW
waar WriteConsoleA gebruik van maakt.
5.4.4
32-bits Windows
We gaan ervan uit dat de 32-bits applicatie altijd in een WoW64-omgeving (en dus op een
64-bits Windows) uitgevoerd wordt. Om er voor te zorgen dat de applicatie ook op een 3255
bits Windows zou kunnen uitvoeren, moeten er een aantal aanpassingen gebeuren. De glue
code moet aangepast worden om te bepalen of de applicatie uitgevoerd wordt in een WoW64omgeving, en indien niet of ze uitgevoerd wordt op een Intel-processor of een AMD-processor
(zie Sectie 2.7.2). Deze informatie wordt dan gebruikt om de SCW’s op de correcte wijze te
herschrijven.
56
Hoofdstuk 6
Implementatie
In dit hoofdstuk wordt het werk geleverd bij de implementatie besproken. Deze bespreking
wordt ingedeeld naargelang de verschillende fasen die er in mijn masterproef waren: eerst
het inwerken, vervolgens het implementeren van het encrypteren van meta-informatie, dan
de implementatie van statisch linken en uiteindelijk het implementeren van de methode om
compatibiliteit te voorzien. We be¨eindigen het hoofdstuk met een aantal statistieken gegenereerd met behulp van SVN, het versiebeheersysteem gebruikt voor Diablo. Alle functionaliteit
beschreven in dit hoofdstuk werd door mij ge¨ımplementeerd, tenzij anders vermeld.
6.1
Inwerken
Alvorens aan de eigenlijke implementatie te beginnen heb ik aanverwante literatuur (over
linken, het PE-formaat, Diablo etc.) gelezen en mijzelf vertrouwd gemaakt met het Diabloraamwerk. Omdat Diablo een redelijk steile leercurve heeft, heb ik veel tijd besteed aan
het lezen en debuggen van de broncode. Diablo had een PE-backend (zie Sectie 2.2.2) maar
deze bevond zich nog niet in een werkende staat. Er was ondersteuning voor het inlezen
van bestanden maar nog niet om deze ook weer weg te schrijven. Het implementeren van
deze functionaliteit vormde een relatief eenvoudige instap tot programmeren in Diablo. Bij
het emuleren van het linkerproces moest er voor gezorgd worden dat de importtabellen op
correcte wijze opgebouwd werden, en op het einde door Diablo ook correct weggeschreven
werden. De PE-backend is doorheen de rest van de masterproef nog verder uitgebreid en
verbeterd door zowel mij als mijn begeleider, Stijn Volckaert.
6.2
Encrypteren van meta-informatie
Opdat het uitvoerbaar bestand in staat zou zijn zichzelf aan te passen en de benodigde
symbolen te importeren wordt er gebruik gemaakt van glue code. Deze bestaat uit de initialisatiefunctie, de laadfunctie en een aantal hulpfuncties (waaronder hashfuncties). Al deze
code werd – op de hashfuncties na – volledig in assembler geschreven. Op een later moment
werd deze assembler herschreven naar C-broncode gemengd met inline assembler voor een
betere onderhoudbaarheid. In Diablo werd er code geschreven om de importtabellen van
een uitvoerbaar bestand te lokaliseren, te lezen en nadien te verwijderen. Er werden datastructuren voorzien om bij te houden welke symbolen ge¨ımporteerd werden uit welke DLL’s.
Daarna werd er uitgezocht hoe de glue code aan het parent-object toegevoegd kon worden,
en vervolgens werd de code geschreven die instaat voor het aanpassen van de ACVG.
57
Bij het aanpassen van de ACVG worden alle instructies die ge¨ımporteerde symbolen gebruiken
opgezocht, en ook deze informatie werd aan de datastructuren toegevoegd. Er werd code
geschreven die op basis van de informatie in de datastructuren de DYNIMP-tabel en DLLtabel genereert en als data-subsecties aan een data-sectie van de glue code toevoegt, zodat
de glue code deze kan vinden. De DYNIMP-tabel bevat de hashes van de terugkeeradressen,
maar deze zijn op het moment dat de DYNIMP-tabel in Diablo gecre¨eerd wordt nog niet
gekend. Pas nadat de ACVG weer omgezet is naar secties zijn deze terugkeeradressen gekend.
Daarom werd er op het moment van het toevoegen van de DYNIMP-tabel in Diablo een broker
call ge¨ınstalleerd. Deze broker call wordt opgeroepen op het moment dat de terugkeeradressen
gekend zijn en berekent dan deze hashes. Al deze code in Diablo was oorspronkelijk in C
geschreven, maar werd op een later moment omgezet naar C++. Op deze manier konden
de zelf geschreven datastructuren vervangen worden door de Standard Template Library
containers.
6.3
Statisch linken
In het begin van deze fase werd de glue code uitgebreid met de Hacker Disassembler Engine
of HDE [65]. Deze tool wordt gebruikt om dynamisch door DLL’s ge¨exporteerde functies
te analyseren en te kopi¨eren naar geheugen dat door de glue code gealloceerd wordt. Het
plan was om dit te gebruiken om de functies die door het uitvoerbaar bestand ge¨ımporteerd
worden dynamisch naar nieuwe geheugenpagina’s te kopi¨eren en vanaf daar uit te voeren. Op
deze manier kon tijdens de uitvoering een dynamisch gelinkt uitvoerbaar bestand omgezet
worden naar een statisch gelinkt uitvoerbaar bestand. Omdat de uitvoerbare code gekopieerd
werd uit componenten die dynamisch gevonden werden, was hooking hier echter nog altijd
een mogelijkheid. Er werd dus beslist om deze functies – en alle andere benodigde delen
uit DLL’s – reeds door Diablo aan het uitvoerbaar bestand toe te laten voegen. Tijdens dit
verkennend werk (dat ongeveer een week heeft geduurd) heb ik wel al veel naar de structuur
van de systeembibliotheken gekeken, wat bij de uiteindelijke implementatie ook een hulp was.
Om ervoor te zorgen dat de toevoegde DLL’s correct bleven functioneren moest er in Diablo code geschreven worden om de relocaties tussen de secties te reconstrueren uit de base
relocaties. Vervolgens werd er code geschreven om de ACVG aan te passen zodat symbolen uit de toegevoegde DLL’s statisch gebruikt werden in plaats van dynamisch. Hiervoor
werd verder gebouwd op de datastructuren die reeds aanwezig waren om informatie over
ge¨ımporteerde symbolen etc. bij te houden. Er werd eerst gewerkt met eenvoudige DLL’s.
Eens er ook systeembibliotheken werden toegevoegd, kreeg ik te maken met een aantal problemen: sprongtabellen en andere data in de .text-sectie, het API-set-schema, export forwarding
en import via ordinaal. De implementatie van lineair disassembleren die reeds aanwezig was
in de i386-backend werd door Stijn Volckaert uitgebreid om met sprongtabellen om te gaan.
Deze code heb ik op sommige punten nog aangepast om meer patronen te herkennen. Omdat
er ook andere data naast sprongtabellen aanwezig bleken te zijn in de .text-secties van de systeembibliotheken heb ik vervolgens code geschreven om recursief te kunnen disassembleren.
Om ondersteuning te voorzien voor export forwarding en import via ordinaal moesten er geen
grote aanpassingen gebeuren. Het API-set-schema daarentegen was niet gedocumenteerd en
de enige bron van informatie hierover bestond uit artikels geschreven door reverse engineers
op het internet. Om ondersteuning voor het API-set-schema te kunnen bieden moesten er
58
UTF-16 strings gelezen worden uit een 64-bits DLL. De PE-backend van Diablo biedt echter
nog geen ondersteuning voor 64-bits PE-bestanden. Er werd dus geen gebruik gemaakt van
een bepaalde backend in Diablo voor het inlezen van bestanden. In plaats daarvan werd er een
niet-herbruikbare en tijdelijke oplossing geschreven. Alvorens aan de ondersteuning voor het
API-set-schema te beginnen heb ik alle functionaliteit die ik op het Diablo-raamwerk geschreven had, omgezet van C-broncode naar C++. Vervolgens heb ik de recursieve disassembler
ge¨ımplementeerd en de code geschreven om de .text-secties van de systeembibliotheken samen te voegen. Voor de recursieve disassembler was er functionaliteit nodig om te kunnen
beslissen of een bepaald ge¨exporteerd symbool een functie of een variabele is. Tot slot werd
er code geschreven in zowel Diablo als de glue code om het uitvoeren van initialisatieroutines mogelijk te maken. Hiervoor werd ook functionaliteit ge¨ımplementeerd om te kunnen
beslissen of een bepaalde DLL een systeembibliotheek is of niet.
6.4
Compatibiliteit
Om een methode te kunnen implementeren die compatibiliteit met meerdere versies van
Windows voorziet, moest ik eerst begrijpen hoe het hele gebeuren van een systeemoproep
verloopt. Dit is niet volledig gedocumenteerd door Microsoft zelf. Er bestaan wel artikels
geschreven door reverse engineers op het internet, maar deze artikels zijn niet volledig in hun
omschrijvingen en vaak tegenstrijdig. Ik heb dus ook zelf met IDA Pro de gedisassembleerde
SCW’s, WoW64-laag en kernel-image bekeken.
De glue code werd geschreven in C. De glue code voor het encrypteren van meta-informatie
werd toen ook herschreven naar C om hergebruik van code toe te laten, maar dit hergebruik
was redelijk beperkt. Er werd ook code geschreven in Diablo die de nodige aanpassingen
maakt in de ACVG om verbindingen te maken met deze toegevoegde glue code.
6.5
SVN-statistieken
Al het werk voor deze masterproef gebeurde in een afzonderlijke SVN-branch van de Diablo
repository waarnaar enkel ik en Stijn Volckaert commits hebben gedaan. We kunnen SVNstatistieken genereren in een poging de hoeveelheid werk geleverd tijdens deze masterproef
te kwantificeren. Een eerste mogelijke maat voor het geleverde werk is het aantal lijnen code
dat aangepast of toegevoegd werd. Doorheen de looptijd van de masterproef heb ik 21534
lijnen code aangepast of toegevoegd. Deze cijfers geven echter geen volledig beeld. Als in
een eerste commit een bepaalde lijn code toegevoegd wordt en deze lijn vervolgens tien keer
wordt aangepast in tien afzonderlijke commits dan telt dit als elf aangepaste lijnen.
Een andere maat die we kunnen gebruiken is de toename in het totaal aantal lijnen code in
de branch, maar bij deze maat wordt er niet gedifferentieerd op auteurschap. Deze toename
komt neer op ongeveer 7500 lijnen code. Een laatste maat voor het geleverde werk bekomen
we aan de hand van het SVN-commando ‘blame’. Dit commando gaat voor elke lijn code
in een bestand na wie deze het laatste heeft aangepast, wat kan gebruikt worden te tellen
hoeveel lijnen code in een map met broncodebestanden het laatste zijn aangepast door een
bepaalde auteur. Kijken naar de laatste persoon die een bepaalde lijn heeft aangepast geeft
59
Onderdeel
Lijnen code
Diablo-gebaseerde applicatie
2251
Glue code
1866
Algemene Diablo-code
746
i386-backend
97
PE-backend
∼800
Tabel 6.1: De groottes van de herschreven uitvoerbare bestanden.
natuurlijk ook geen volledig beeld aangezien iemand anders deze lijn kan hebben geschreven
en meerdere malen aangepast alvorens de laatste persoon ze aanpaste. In Tabel 6.1 wordt
deze maat voor door mij geschreven code weergegeven voor verschillende onderdelen.
Voor de PE-backend kon geen nauwkeurige meting gedaan worden. De line endings in deze
bestanden werden tijdens de masterproef veranderd van Windows-stijl naar Unix-stijl met
als gevolg dat bijna alle lijnen code verkeerdelijk als door mij aangepast worden beschouwd.
Handmatig bekijken van de geschreven functies uit deze bestanden leidt tot een schatting
van ongeveer 800 van de 4843 lijnen die door mij geschreven werden. Onder ‘Glue code’
valt zowel de glue code voor het verzorgen van compatibiliteit als de glue code voor het
encrypteren van meta-informatie. Bij het laatste werd zowel de versie geschreven in assembler
als de herschreven C-versie geteld. Met ‘Diablo-gebaseerde applicatie’ wordt de functionaliteit
bedoeld die op het Diablo-raamwerk werd ge¨ımplementeerd om de applicaties te herschrijven
volgens de methodes van het encrypteren van meta-informatie en statisch linken.
60
Hoofdstuk 7
Evaluatie
De in de vorige hoofdstukken voorgestelde methodes worden in dit hoofdstuk ge¨evalueerd.
Aangezien deze methodes proof-of-concept zijn en realistische applicaties herschrijven nog
niet mogelijk is, bestaat deze evaluatie vooral uit het bespreken van de beperkingen van de
methodes en het schatten van de overhead ge¨ıntroduceerd door het gebruik ervan.
7.1
Encrypteren van meta-informatie
Momenteel zijn de belangrijkste beperkingen bij het encrypteren van meta-informatie dat het
importeren van variabelen noch import via ordinaal ondersteund worden. Niet alle mogelijke
uitvoerbare bestanden kunnen dus herschreven worden. De overhead die de methode introduceert bestaat enkel uit de tijd die gespendeerd wordt aan het uitvoeren van de glue code.
Daarom worden de gemiddelde uitvoeringstijden van de initialisatiefunctie en de laadfunctie
gemeten. Deze metingen werden uitgevoerd op een 64-bits Windows 8.1 met een Intel Core
i7 processor.
De uitvoeringstijd van de initialisatiefunctie werd gemeten voor een realistisch scenario waarin
de DLL-tabel de gehashte namen van acht DLL’s (groot en klein) bevat. Het laden van deze
acht DLL’s is de taak waar de initialisatiefunctie het meeste tijd aan besteed. De totale
uitvoeringstijd kwam voor dit scenario na meerdere testen uit op ongeveer 17ms. De initialisatiefunctie neemt door het laden van deze DLL’s eigenlijk de taak van de loader over (zie
Sectie 2.5.2) en deze uitvoeringstijd is dus geen pure overhead.
Voor de laadfunctie werd er een scenario opgezet met een reeks oproepen naar de laadfunctie. Voor elke oproep wordt er een ‘call laadfunctie’-instructie herschreven naar een ‘call
kernel32.symbool’-instructie. Omdat de laadfunctie de namen in de ENT overloopt en hasht
tot de juiste naam gevonden is, verwachten we dat de laadfunctie gemiddeld langer uitvoert
bij DLL’s met een grote ENT. We nemen kernel32 als gebruiksgeval omdat deze een ENT
heeft met een groot aantal namen, namelijk 1551. Er werden drie mogelijke symbolen uit
kernel32 gebruikt: ´e´en dat zich aan het begin van de ENT bevindt, ´e´en dat zich aan het
einde bevindt, en ´e´en dat zich ongeveer in het midden bevindt. Een symbool zal sneller gevonden worden indien het in het begin van de ENT staat, en op deze manier middelen we de
resultaten dus uit.
Hoe meer elementen er aanwezig zijn in de DYNIMP-tabel, hoe langer het gemiddeld duurt
61
voor de laadfunctie om deze te overlopen. We verwachten dus dat de uitvoeringstijd van de
laadfunctie toeneemt naarmate deze tabel groter wordt. Bij een reeks van 99 oproepen kostte
elke oproep gemiddeld 49µs. Bij een reeks van 300 oproepen was dit gemiddeld 51µs, bij
900 was dit gemiddeld 52µs en bij 9000 83µs. Voor een uitvoerbaar bestand waarin er meer
instructies gebruik maken van een ge¨ımporteerd symbool voert de laadfunctie dus iets trager
uit. De totale overhead veroorzaakt door de laadfunctie is beperkt omdat de laadfunctie
hoogstens even veel opgeroepen kan worden als dat er instructies zijn die ge¨ımporteerde
symbolen gebruiken. Uit het disassembleren van een aantal uitvoerbare bestanden blijkt dat
het bij grote, ingewikkelde applicaties mogelijk is dat er duizenden zo’n instructies zijn.
Indien dit het geval is zou de totale overhead nog steeds beperkt blijven tot minder dan een
seconde, verspreid over de uitvoertijd van de applicatie. Enkel indien er op een bepaald punt
van de applicatie – zoals het opstarten – een ongewone concentratie aan oproepen naar de
laadfunctie is, is deze overhead merkbaar.
7.2
Statisch linken
Deze sectie gaat over de methode van het statisch linken die uitgelegd is geweest in Hoofdstuk 4 en Hoofdstuk 5. Deze bestaat eigenlijk uit twee deelmethodes (elk uitgelegd in zijn
eigen hoofdstuk), maar in deze sectie wordt de volledige methode ge¨evalueerd.
7.2.1
Beperkingen
Er zijn een aantal belangrijke beperkingen aan de huidige implementatie van de methode:
• de toegevoegde delen uit kernel32, KernelBase en ntdll worden nog niet ge¨ınitialiseerd.
• er is enkel compatibiliteit met de 64-bits versies van Windows 7, Windows 8 en Windows
8.1.
• er is geen ondersteuning voor grafische systeemoproepen op meerdere versies van Windows.
• eventuele veranderingen in de system services worden niet opgevangen.
• niet alle instructies uit de .text-secties van de systeembibliotheken worden gedisassembleerd, met mogelijke fouten in de applicatie tot gevolg.
• er blijft teveel nutteloze code en data over in het herschreven uitvoerbaar bestand.
7.2.2
Nutteloze code en data
We gaan nog even in op de laatste beperking, namelijk die van de nutteloze code en data.
Deze zorgt er namelijk voor dat de herschreven uitvoerbare bestanden een stuk groter zijn
dan de uitvoerbare bestanden uit de oorspronkelijke, dynamisch gelinkte applicaties. Om
dit probleem te verduidelijken bevat Tabel 7.1 voor een aantal kleine voorbeeldapplicaties
de grootte van het herschreven uitvoerbaar bestand. De uitvoerbare bestanden voor deze
voorbeeldapplicaties hebben allemaal een grootte van 2560 bytes.
62
Applicatie
Grootte (in KB)
HeapAlloc
387
VirtualAlloc
421
CreateThread
435
GetTickCount
435
OpenFile
1025
HelloWorld
2169
HelloWorldExtra
2177
Tabel 7.1: De groottes van de herschreven uitvoerbare bestanden.
In HeapAlloc wordt er geheugen op de heap gealloceerd en beschreven. In VirtualAlloc wordt
hetzelfde gedaan, waarna er een extra geheugenpagina wordt gealloceerd en beschreven. CreateThread doet hetzelfde als VirtualAlloc maar cre¨eert een nieuwe thread om naar de geheugenpagina te schrijven. GetTickCount zal al het voorgaande doen, maar de nieuwe thread zal
nu de – binaire representatie van de – systeemtijd naar de geheugenpagina schrijven. OpenFile
is hetzelfde als GetTickCount maar opent ook een bestand. Tot slot schrijven HelloWorld
en HelloWorldExtra allebei de tekst “Hello World!” naar een consolevenster, maar doet de
tweede versie daarnaast ook alles wat OpenFile doet.
We zien dat ingewikkeldere applicaties in het algemeen groter zijn, maar dat er bepaalde
drempels zijn. Zodra er een functie ge¨ımporteerd wordt die gebruik maakt van de .datasectie van een DLL, wordt deze sectie (samen met geassocieerde code en data) bijgehouden
en is het herschreven uitvoerbaar bestand weer een stuk groter. Als er daarnaast een andere
functie uit dezelfde DLL ge¨ımporteerd wordt die gebruik maakt van deze sectie, dan is de
uiteindelijke kost (qua grootte van het bestand) voor deze ge¨ımporteerde functie kleiner dan
voor de eerste.
De eerste vier bestanden bevatten geen toegevoegde data-secties. De toename in grootte
tussen de eerste drie bestanden is redelijk klein omdat er enkel extra code toegevoegd wordt.
De derde en vierde herschreven bestanden zijn zelfs even groot. De functionaliteit om de
systeemtijd op te vragen was namelijk al aanwezig in de derde applicatie, hoewel deze daar
niet gebruikt werd. Bij de overgang van het vierde naar het vijfde bestand wordt er een
drempel overschreven. Het vijfde bestand is veel groter dan het vierde omdat er in het vijfde
bestand wel een data-sectie aanwezig is. HelloWorld en HelloWorldExtra verschillen niet
veel qua grootte maar wel qua ge¨ımporteerde functies. Het merendeel van de code en data
geassocieerd aan de door HelloWorldExtra ge¨ımporteerde functies was dus reeds aanwezig in
HelloWorld zonder dat het gebruikt werd.
Om meer nutteloze code en data te kunnen verwijderen zou het dus vooral beter zijn om
data-secties beter onder te verdelen in subsecties. Er is natuurlijk ook een bovengrens aan de
63
grootte van het herschreven uitvoerbaar bestand, namelijk de som van de groottes van het
oorspronkelijk uitvoerbaar bestand en de toegevoegde DLL’s.
7.2.3
Evaluatie overhead
Net zoals in Sectie 7.1 bestaat de overhead van deze methode uit de tijd die gespendeerd
wordt aan het uitvoeren van de glue code. Deze metingen werden uitgevoerd op een 64-bits
Windows 8.1 met een Intel Core i7 processor.
Bij het evalueren van de initialisatiefunctie werd er geen bepaald scenario gebruikt omdat
deze functie in elk geval hetzelfde gedrag vertoont. De uitvoeringstijd bleek gemiddeld 26µs
te zijn. De enige variabele factor in de uitvoeringstijd van de laadfunctie bestaat uit de tijd
die het kost om in ntdll’s ENT de naam van de SCW op te zoeken. Dit gebeurt door alle
namen in de ENT te hashen tot de hashes overeenkomen. Namen die in het begin van de ENT
staan worden dus sneller gevonden dan die op het einde. In het scenario dat we gebruiken
wordt de laadfunctie 20 keer opgeroepen om de SCW waarvan de naam het laatst staat in de
ENT te herschrijven. De gemiddelde uitvoeringstijd voor de laadfunctie bleek 35µs te zijn.
De laadfunctie wordt hoogstens ´e´en keer opgeroepen per SCW aanwezig in het uitvoerbaar
bestand en in alle systeembibliotheken tezamen zijn er slechts een paar duizend SCW’s.
De totale uitvoeringstijd van de glue code is dus beperkt tot minder dan een seconde. De
laadfunctie zal op verschillende momenten tijdens de uitvoering van de applicatie opgeroepen
worden, hoewel het natuurlijk te verwachten valt dat er tijdens het opstarten van de applicatie
het vaakst SCW’s voor het eerst opgeroepen zullen worden. Zelfs indien er 1000 SCW’s voor
het eerst opgeroepen zouden worden tijdens het opstarten – een extreem scenario – dan zou
dit opstarten in totaal maar 35ms langer duren. De overhead ge¨ıntroduceerd door de methode
is dus zeer klein.
64
Hoofdstuk 8
Conclusie
In deze scriptie werden twee methodes besproken om het gebruik van bibliotheekinterfaces
af te schermen tegen reverse engineering, door uitvoerbare bestanden te herschrijven. Vooral
de methode van het statisch linken is beloftevol. In deze methode worden er dynamische
bibliotheken waarvoor we de broncode noch de objectbestanden bezitten aan het uitvoerbaar
bestand toegevoegd. Dit gebrek aan informatie zorgt ervoor dat er veel nutteloze code en data
aanwezig is in het uitvoerbaar bestand, waardoor dit bestand onnodig groot is. Hiernaast
zijn er nog een aantal beperkingen in de huidige implementatie van de methode. Bij beide
methodes is het nog niet mogelijk om realistische applicaties te herschrijven, hoewel dit met
de nodige uitbreidingen wel mogelijk zou moeten zijn.
Met het toevoegen van de dynamische bibliotheken waarvan het uitvoerbaar bestand afhankelijk was, worden er ook nieuwe mogelijkheden gecre¨eerd. De code en data uit deze
bibliotheken wordt nu meegeleverd door de ontwikkelaar van applicatie, zodat deze code en
data naar believen aangepast kan worden. Deze kan aangepast worden met het oog op beveiliging, zo kan bijvoorbeeld de code uit de bibliotheken – ook uit de systeembibliotheken –
geobfusceerd worden om reverse engineering tegen te gaan.
65
Bibliografie
[1] Linux, “Linux Documentation: The kernel syscall interface.” [Online]. Available: http://www.cs.fsu.edu/∼baker/devices/lxr/http/source/linux/Documentation/
ABI/stable/syscalls
[2] J. R. Levine, Linkers & Loaders. Morgan Kaufmann Publishers, 2000.
[3] Wikipedia, “DLL Hell.” [Online]. Available: http://en.wikipedia.org/wiki/DLL Hell
[4] L. Van Put, D. Chanet, B. De Bus, B. De Sutter, and K. De Bosschere, “DIABLO: a
reliable, retargetable and extensible link-time rewriting framework,” Proceedings of the
Fifth IEEE International Symposium on Signal Processing and Information Technology,
2005., 2005.
[5] B. De Sutter, B. De Bus, and K. De Bosschere, “Link-time binary rewriting techniques
for program compaction,” ACM Transactions on Programming Languages and Systems
(TOPLAS), vol. 27, no. 5, pp. 882–945, 2005.
[6] B. De Sutter, L. Van Put, D. Chanet, B. De Bus, and K. De Bosschere, “Link-time
compaction and optimization of ARM executables,” ACM Transactions on Embedded
Computing Systems (TECS), vol. 6, no. 1, p. 5, 2007.
[7] M. Madou, B. Anckaert, P. Moseley, S. Debray, B. De Sutter, and K. De Bosschere,
“Software protection through dynamic code mutation,” in International Workshop on
Information Security Applications (WISA), 2005, pp. 194–206.
[8] B. Coppens, B. De Sutter, and K. De Bosschere, “Protecting your software updates,”
pp. 1–1, 2012.
[9] B. Schwarz, S. Debray, and G. Andrews, “Disassembly of executable code revisited,”
Ninth Working Conference on Reverse Engineering, 2002. Proceedings., 2002.
[10] C. Linn and S. Debray, “Obfuscation of executable code to improve resistance to static
disassembly,” Proceedings of the 10th ACM conference on Computer and communication
security - CCS ’03, p. 290, 2003.
[11] R. N. Horspool and N. Marovac, “An approach to the problem of detranslation of computer programs,” The Computer Journal, vol. 23, no. 3, pp. 223–229, 1980.
[12] C. Eagle, The IDA pro book: the unofficial guide to the world’s most popular disassembler.
No Starch Press, 2008.
[13] C. Cifuentes and K. J. Gough, “Decompilation of Binary Programs,” Software Practice
and Experience, vol. 25, pp. 811–829, 1995.
66
[14] M. Christodorescu and S. Jha, “Static analysis of executables to detect malicious patterns,” SSYM’03 Proceedings of the 12th conference on USENIX Security Symposium,
vol. 12, pp. 12–12, 2003.
[15] CLET Team, “Polymorphic Shellcode Engine,” Phrack, vol. 11, no. 61, 2003. [Online].
Available: http://phrack.org/issues/61/9.html
[16] A. Moser, C. Kruegel, and E. Kirda, “Limits of Static Analysis for Malware Detection,”
Twenty-Third Annual Computer Security Applications Conference (ACSAC 2007), pp.
421–430, Dec. 2007.
[17] U. Bayer, A. Moser, C. Kruegel, and E. Kirda, “Dynamic Analysis of Malicious Code,”
pp. 67–77, 2006.
[18] M. Egele, C. Kruegel, E. Kirda, and D. Song, “Dynamic Spyware Analysis,” Analysis,
pp. 233–246, 2007.
[19] T. Bell, “The concept of dynamic analysis,” pp. 216–234, 1999.
[20] I. Ivanov, “API hooking revealed,” The Code Project, 2002.
[21] C. Collberg and C. Thomborson, “Watermarking, tamper-proofing, and obfuscation tools for software protection,” IEEE Transactions on Software Engineering, vol. 28, 2002.
[22] J. Crasta, “ELF Prelinking and what it can do for you.” [Online]. Available:
http://crast.us/james/articles/prelink.php
[23] M. Pietrek, “An In-Depth Look into the Win32 Portable Executable File Format.”
[Online]. Available: http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
[24] C. S. Collberg, J. H. Hartman, S. Babu, and S. K. Udupa, “SLINKY: Static Linking
Reloaded.” in USENIX Annual Technical Conference, General Track, 2005, pp. 309–322.
[25] PEBundle, “PEBundle.” [Online]. Available: http://bitsum.com/pebundle.asp
[26] MoleBox, “MoleBox.” [Online]. Available: http://www.molebox.com/
[27] ReWolf, “DLLPackager.” [Online]. Available: https://code.google.com/p/dllpackager/
[28] Microsoft, “Microsoft Portable Executable and Common Object File Format Specification,” 2013.
[29] J. Leitch, “IAT Hooking Revisited.” [Online]. Available: http://www.autosectools.com/
IAT-Hooking-Revisited.pdf
[30] A. Malik, “DLL Injection and Hooking.” [Online]. Available: http://securityxploded.
com/dll-injection-and-hooking.php
[31] PaX, “ASLR.” [Online]. Available: http://pax.grsecurity.net/docs/aslr.txt
[32] H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and D. Boneh, “On the
effectiveness of address-space randomization,” in Proceedings of the 11th ACM conference
on Computer and communications security, 2004, pp. 298–307.
67
[33] M. E. Russinovich, D. A. Solomon, and A. Ionescu, Windows Internals: Covering Windows Server 2008 and Windows Vista, 2009.
[34] Wikipedia, “Native API.” [Online]. Available: http://en.wikipedia.org/wiki/Native API
[35] M. E. Russinovich, “Inside the Native API.” [Online]. Available: http://netcode.cz/
img/83/nativeapi.html
[36] Microsoft, “New Low-Level Binaries.” [Online]. Available: http://msdn.microsoft.com/
library/dd371752.aspx
[37] ——, “Windows API Sets.” [Online]. Available: http://msdn.microsoft.com/en-us/
library/hh802935(v=vs.85).aspx
[38] NirSoft, “Windows 7 Kernel Architecture Changes.” [Online]. Available: http:
//www.nirsoft.net/articles/windows 7 kernel architecture changes.html
[39] Quarkslab, “Runtime DLL name resolution: ApiSetSchema.” [Online]. Available:
http://blog.quarkslab.com/runtime-dll-name-resolution-apisetschema-part-i.html
[40] G. Chapell, “The API Set Schema.” [Online]. Available: http://www.geoffchappell.
com/studies/windows/win32/apisetschema/index.htm
[41] J. Gulbrandsen, “How Do Windows NT System Calls REALLY Work?” [Online]. Available: http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/
article.php/c8035/How-Do-Windows-NT-System-Calls-REALLY-Work.htm
[42] G. Hoglund, “A *REAL* NT Rootkit, patching the NT Kernel,” Phrack, vol. 9, no. 55,
1999. [Online]. Available: http://phrack.org/issues/55/5.html#article
[43] Shift32, “Inside KiSystemService.” [Online]. Available: http://shift32.wordpress.com/
2011/10/14/inside-kisystemservice/
[44] Trapframe, “Just enough kernel to get by (part 2) : Syscall & SSDT.” [Online].
Available: http://trapframe.org/just-enough-kernel-to-get-by-2/
[45] D. Lukan, “Hooking the System Service Dispatch Table.” [Online]. Available:
http://resources.infosecinstitute.com/hooking-system-service-dispatch-table-ssdt/
[46] The Honeynet Project, “Get system call address from SSDT.” [Online]. Available:
http://www.honeynet.org/node/438
R 64 and IA-32 Architectures Software Developer’s Manual,”
[47] Intel Corporation, “Intel 2014.
[48] M. Jurczyk, “Windows X86 System Call Table (NT/2000/XP/2003/Vista/2008/7/8).”
[Online]. Available: http://j00ru.vexillium.org/ntapi/
[49] Microsoft, “Running 32-bit Applications.” [Online]. Available: http://msdn.microsoft.
com/en-us/library/windows/desktop/aa384249(v=vs.85).aspx
68
[50] ——, “WoW64 Implementation Details.” [Online]. Available: http://msdn.microsoft.
com/en-us/library/windows/desktop/aa384274(v=vs.85).aspx
[51] K. Johnson, “What’s the difference between the Wow64 and native x86 versions of a
DLL?” [Online]. Available: http://www.nynaeve.net/?p=131
[52] M. Naor and M. Yung, “Universal one-way hash functions and their cryptographic applications,” Proceedings of the twenty-first annual ACM . . . , pp. 33–43, 1989.
[53] Microsoft, “LoadLibrary function.” [Online]. Available: http://msdn.microsoft.com/
en-us/library/windows/desktop/ms684175(v=vs.85).aspx
[54] Wikipedia, “Process Environment Block.” [Online]. Available: http://en.wikipedia.org/
wiki/Process Environment Block
[55] Harmony Security, “Retrieving Kernel32’s Base Address.” [Online]. Available:
http://blog.harmonysecurity.com/2009/06/retrieving-kernel32s-base-address.html
[56] Microsoft, “GetProcAddress function.” [Online]. Available: http://msdn.microsoft.
com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx
[57] ——, “VirtualProtect function.” [Online]. Available: http://msdn.microsoft.com/en-us/
library/windows/desktop/aa366898(v=vs.85).aspx
[58] ——, “FlushInstructionCache function.” [Online]. Available: http://msdn.microsoft.
com/en-us/library/windows/desktop/ms679350(v=vs.85).aspx
[59] S. Chow, P. A. Eisen, H. Johnson, and P. C. van Oorschot, “White-Box Cryptography
and an AES Implementation,” in Revised Papers from the 9th Annual International
Workshop on Selected Areas in Cryptography, 2003, pp. 250–270.
[60] Microsoft, “DllMain entry point.” [Online]. Available: http://msdn.microsoft.com/
en-us/library/windows/desktop/ms682583(v=vs.85).aspx
[61] ——, “Dynamic-Link Library Entry-Point Function.” [Online]. Available: http:
//msdn.microsoft.com/en-us/library/windows/desktop/ms682596(v=vs.85).aspx
[62] ——, “Using Thread Local Storage in a Dynamic-Link Library.” [Online]. Available:
http://msdn.microsoft.com/en-us/library/ms686997(v=vs.85).aspx
[63] K. Johnson, “A catalog of NTDLL kernel mode to user mode callbacks, part 6:
LdrInitializeThunk.” [Online]. Available: http://www.nynaeve.net/?p=205
[64] ReactOS, “ReactOS Project.” [Online]. Available: https://www.reactos.org/
[65] V. Patkov, “Hacker Disassembler Engine.” [Online]. Available: http://vxheavens.com/
vx.php?id=eh04
69

Sla dit formulier op!

Fotograferen met ID-Link

OUDE XP PC TOCH NOG TE GEBRUIKEN

Ontwikkeling Statistische Analyse Software

Installatie Garmin Mapsource 6.16.3

COPE controles

JOBS AT CAREER PAGE WWW.VCST.COM

bulletin 60.pub - DIG-PA

1. Prodrive FuelScan (0-meting) € 1.500,

Beëindiging ondersteuning Windows XP Microsoft stopt op 8 april