c..k..i

vous devez chausser du 48 ou bien mettre des scholls

2011-09-05T17:16:00.003+01:00

last post here ?
As I now prefer to write and update technical documents in my wiki, and notify people via my announcement-only twitter account, rather than write on this blog, it will be unlikely updated in the future.

So, to keep yourself updated, I suggest to check @corkami.
If you want to use an RSS reader, you can point it to this address, which doesn't require your own twitter account . For some reasons, Google Reader doesn't like it: to solve the problem, you can use a service such as Freemyfeed (no need of login/password). It gives you an url like this one, which works fine with Google Reader.

dernier billet ici ?
Comme je préfère désormais écrire et maintenir des documents techniques sur mon wiki, et avertir des mises-à-jour via mon compte twitter (utilisé uniquement pour cela), plutôt que d'écrire sur ce blog, il a peu de chances d'être mis à jour à l'avenir.

Pour vous tenir au courant, je vous conseille donc de regarder @corkami.
Si vous voulez utiliser un lecteur RSS, vous pouvez l'utiliser avec cette adresse, qui ne nécessite pas d'avoir votre propre compte twitter.
Pour des raisons inconnues, Google Reader ne semble pas l'accepter: pour résoudre le problème, vous pouvez utiliser un service tel que Freemyfeed (sans identifiant ni mot de passe). Vous obtiendrez une adresse alors comme celle-ci, qui fonctionne sans problème avec Google Reader.

too scared to go to prison, we're unable to make decisions

2011-07-14T18:10:00.001+01:00

I still don't have the time to write a decent blog article, but at least, I managed to do a few things since the last post (if you don't follow me on twitter or reddit):

Trying to improve my screencasting methodology, I created a screencast tutorial on reJava (compare with my previous one and let me know which one is better).
a summary of PDF tricks page, with various categories (encodings, structures, javascript...), and for each example, a handmade, clean and minimal PoC.
In order to study a way to document in details a binary, I created a commented IDB of a PE file packed with UPX - released as is, on request but I find it a sub-optimal way to document assembly, especially as it's not really possible to easily move this information to another IDB.
a small update to my PE infographics, some fixes, and improvments of the resource section.
a merge from the aPlib part of Kabopan as a single independent aplib.py
a commented disassembly of Peter Ferrie's new EICAR file
a commented disassembly of Yosuke Hasegawa's AA86, the symbol assembler.
Example: "Hello World" code:

@^^^^^-%+)@@^^^!;@@_!,((,.((-$+)@*+@!!@-,!"(+@@,$-,!"($%&,&,&_&,"@"'%_&"',&$&-@*@$"

a handy python script to rename unicode filenames (and back), very handy for these tools that don't support unicode filenames.
ex: 日本.txt <=> &'#26085;&'#26412;.txt
a yED graph of intel AVX2 opcodes descriptions (png): totally useless in itself, yet all these opcodes are scary.

Mireille est une star au fin fond du Tibet

2011-04-01T18:35:00.003+01:00

Here are a few things that I released recently but didn't get a regular blog post, just a twitter entry:

Usermode test(v0.1): a usermode opcode tester, covering most opcodes, including rare, obsolete, recent, undocumented, 64 bits, exception triggers, anti-debugs.... (gathering and extending the result of my previous blog entries and programs)

Following Peter Ferrie's article, I wrote a commented source of JJencode, the funny javascript obfuscator, along with a dumb decryption script.
I extended y0da's binary corpus, with various compiled files and my own experimental PEs, to build my own binary corpus. It covers a lot of different compilers, sections layout, image directories,...
I created a simple screencast to introduce tracing with OllyDbg, based on Oleh's tutorial.

I wear my crown of thorns, on my liar's chair

2011-02-01T21:24:00.003Z

a bit of nostalgia (virii)
my first contact with a computer virus was Ping-Pong, which infected our 10 Mhz 8086. Hopefully, a magazine was giving the solution (for free!): they were giving the hex sequence to search and replace !!!
While it was a working solution, it was not exactly 'user-friendly': Hey Grandma, launch PCTools 4.30, open the hex editor, then.... err, nevermind !

My 2nd interaction with a virus was Tequila: it kept re-infecting our computer. However, because our 20 Mb hard disk was very noisy, I could eventually recognize the sound of the virus infecting the MBR ! Instant detection, but once again, not exactly the most user friendly !

Hopefully, Anti-Virus softwares are now a bit better than 'listen to your hard disk' or 'search and replace yourself' !

Mais je me lâche la main, je m’éloigne de moi...

2011-02-01T19:03:00.000Z

unpacking drivers in user-mode (2)

Following my previous post on the topic, I came up with a few more tricks:

since packed drivers typically use ExAllocatePool*, you need a user-mode equivalent to extract the packed driver. So I just made my fake ntoskrnl call VirtualAlloc* for the trick
they often use RtlImageNtHeader, so I added a redirection for it in the fake ntoskrnl.
some drivers import HAL.DLL and CLASSPNP.SYS, I made fake ones for them too.
some drivers load ntoskrnl.exe manually. in this case, i'd use (under OllyDbg) multimate-assembler, with a standard snippet.
it's important to recognize when the driver is trying to locate ntoskrnl, to be able to correct execution. Here are the various ways that I can recall:

calling SIDT will give you the IDT, which is present in ntoskrnl.
calling RDMSR with ECX=176 gives you Sysenter address, you can then locate ntoskrnl header.
standard range checking:

mov eax, 0ffdff12ch
mov eax, [eax]
loop:
and ax, f001
dec eax
cmp [eax], 5a4d
jnz loop

As usual, I included the (minimal) sources - happy unpacking!
Sources and binaries

Ne trouvez-vous donc pas, l'histoire un peu répétitive ?

2010-07-14T18:19:00.001+01:00

a simple API jump
If you check Wine's source:

void WINAPI RtlCopyLuid (PLUID LuidDest, const LUID *LuidSrc)
{
*LuidDest = *LuidSrc;
}

you see that this little NtDll API is very strong: no check is done, so it could be used literally for anything. A simple way to use it is just to jump, by setting the right arguments.

mov eax, esp
sub eax, 10h
push jump_target
push esp
push eax
call RtlCopyLuid

Jumps is now updated with it. (Part 1 here)

un saut simple via API
Si on regarde le source de Wine:

void WINAPI RtlCopyLuid (PLUID LuidDest, const LUID *LuidSrc)
{
*LuidDest = *LuidSrc;
}

on voit que cette petite API de NtDll est très puissante: aucune vérification, donc elle pourrait être vraiment utilisée pour tout et n'importe quoi. Une façon simple de l'utiliser est pour sauter, en préparant correctement la pile:

mov eax, esp
sub eax, 10h
push jump_target
push esp
push eax
call RtlCopyLuid

cette technique est maintenant ajoutée à Jumps (première partie ici)

...Weiß noch nicht, dass er tanzen muss

2010-07-11T19:43:00.004+01:00

misc update
Just to let you know I updated the Map and Downloads, hoping things will be a little more detailed about my various experiments.

petite mise à jour
Simplement pour vous dire que j'ai mis à jour la Carte et les Téléchargements, en espérant que les choses soient un peu plus claires concernant mes bidouillages.

Sans réfléchir, ne me demande pas comment...

2010-07-08T18:14:00.004+01:00

a bit of nostalgia
my first game crack was purely accidental (i own the game too!):
both edited by Microprose, F15 Strike eagle II and F19 stealth fighter had the same structure:
a small (F15|F9).COM file calling the main GAME.EXE file
what if you swap one game's .COM with the other game's ?
well, it turns out that in F15, the protection check was in the .COM, and in F19, it was in the EXE.
so if you swapped COM files, F19 was getting 2 protections checks... and F15... none :)

my first cheat patch was not completely accidental, but totally lucky too (I had no assembly knowledge at the time):
by checking in games magazines, I noticed it was often a matter of switching a 74 xx with a 75 xx, or replacing it with a 90 90...
so I took my favorite game at the time (Super Off-Road Racer), a hex-editor (PC-Tools 4.30 ! yeah !), and looked for hex sequences, trying blindly one after each other:
and ... it worked... I eventually (ahh, youth !) replaced the right sequence, giving me infinite nitros...

it was... in 1990 ! Doh! I feel old, suddenly...

a bit of nostalgia

mon premier crack était purement accidentel (j'avais le jeu original, cela dit):
tous deux de MicroProse, F15 Strike eagle II et F19 stealth fighter avaient la même structure:
un petit fichier (F15|F9).COM qui appelle le GAME.EXE principal
que ce passe-t-il si on intervertit les 2 fichiers COM ?
et bien, il s'avère que dans F15, la vérification de la copie se trouvait dans le COM, et dans F19, dans l'EXE...
donc, si on intervertit les 2, F19 vérifiait successivement les 2 disquettes... et F15... aucune :D

mon premier patch pour tricher n'était pas complètement accidentel, mais quand même très chanceux (je n'avais aucune connaissance d'assembleur à l'époque):
à force de regarder les magazines qui proposaient des patchs, j'avais remarqué que souvent, il s'agissait de remplacer un 74 xx par un 75 xx, ou de tout remplacer par un 90 90...
Donc j'ai pris mon jeu favori à l'époque (Super Off-Road Racer), mon éditeur hexadécimal favori (PC-Tools 4.30 ! yeah !), et j'ai essayé de remplacer chaque séquence au pif, l'une après l'autre...
et... ça a fini par marcher (ahhh, jeunesse !)... au hasard, j'ai fini par patcher la bonne séquence, me donnant les nitros infinies...

tout cela... en 1990 ! Je me sens vieux, tout d'un coup...

Wir halten zusammen, keiner kämpft allein

2010-04-07T09:46:00.004+01:00

Finished PE/Packers/Opcodes graphics

As I added Data Directories to the PE infographics, my 3 infographics projects are now finished:
PE format
Packers
Opcodes

It was fun, hope you like them.

Infographies PE/Packeurs/Instructions terminées

Je viens de rajouter les Data Directories à mon infographie sur le PE. Mes 3 projets en cours d'infographies sont donc terminés :
PE format (anglais)
Packers (anglais)
Opcodes (anglais)

C'était intéressant, j'espère que ça vous plait.

Before you judge me, take a look at you

2010-04-05T20:52:00.004+01:00

Packers' algorithms

I created one last diagram, showing Packers' most common algorithms.
Packers' infographics

I have no plan to do any other on the topic. Let me know if you have a suggestion for an extra one.

Algorithmes de Packeurs

J'ai crée une dernière infographie qui montre les algorithmes les plus communs dans les packeurs.
Packers' infographics (anglais)

Je n'ai pas le projet d'en faire un autre sur le sujet, dites-moi si vous avez des suggestions.

Si tu cherches un peu de gaîté, viens donc faire un tour à...

2010-04-04T22:53:00.003+01:00

Typical behavior of the various kinds of packers

I made an infographic showing 3 different kinds of packer, their usual steps and the caracteristics of each of these steps.

Packers

Comportement habituel des diverses sortes de packeurs

J'ai fait une infographie représentant 3 différentes sortes de packeurs, leurs étapes habituelles, et les caractéristiques de chaque étape.

Packers (anglais)

I time every journey to bump into you

2010-04-03T18:28:00.004+01:00

PE file and memory layouts
I created a graph (diagram?) for the PE format, showing 'standard' layouts of a PE file, on disk and in memory.

PE Format: Headers, Layouts

Initially, I wanted to include all PE details, but it would make it overly complex (or impossible, as I make them on a netbook).

Organisations fichier et mémoire d'un PE
J'ai créé un graphe (schéma, diagramme ?) pour le format PE, qui montre les organisations 'standards' d'un PE, sur le disque et en mémoire.

PE Format: Headers, Layouts (ANGLAIS)

A l'origine, je voulais y mettre tous les détails du PE, mais ça le rendrait illisible (ou ingérable, vu que je fais tout ça sur un netbook).

Lutte contre les mots faciles, lutte contre la haine des ...

2010-04-02T23:24:00.006+01:00

user-mode opcodes cheat sheets
I mostly work on user-mode code, or kernel-mode code that actually uses a very limited amount of privileged opcodes, just to access CR0 and IF. Besides, FPU/MMX/SSE are usually used as junk or pure calculation that I can ignore.

So, from that limited perspective, the amount of opcodes is much reduced.

A Perspective of two-byte opcodes
After my overview of one-byte opcodes, I made a graph of two-byte opcodes according to that perspective.
It makes it much more readable than expected!

Opcodes' reminders
Also, I checked every user-mode opcode, and wrote a one-liner to describe them, as well as a small example. I put together an executable with all the examples, just to see them in action - and test your favorite emulator ;)

It makes them small opcodes' reminders, in printable text and executable code formats.

All obvious opcodes are naturally included, but also (since ALL user-mode opcodes are present):

ARPL, BOUND, LDS, LAR, STR, XADD, SYSENTER,
XLAT, VERR, SALC, AAA, CMPXCHG, SIDT...

aka 'all the ones I forget too quickly'.

Opcodes (One-byte overview, two-byte perspective, opcodes' description)
Opcodes test executable (source)

The executable may not work on (older?) AMD cpus (because of SYSENTER), and may fail under virtualization or other OS but XP (SIDT, STR, etc...)

Thanks to Costin Ionescu and BeatriX.

Sysenter Anti-stepping
I noticed that, like Int2E, Sysenter behaves differently if stepped or ran over.
for example, with EAX = 0:
if stepping,

ECX, EDX = 1, -1.

If ran normally,

ECX, EDX = esp - 4, @KiFastSystemCallRet.

Penses-bêtes pour instructions en mode utilisateur
Je travaille principalement avec du code en mode utilisateur, ou du code noyau qui n'utilise en fait qu'un nombre très limité d'instructions privilégiées, juste pour accéder a CR0 et IF. De plus, FPU/MMX/SSE sont utilisés d'habitude comme code pourri, ou comme calcul pur que je peux ignorer.

Donc, avec cette perspective limitée, le nombre d'instructions est bien réduit.

Une perspective des instructions sur deux octets
Après ma vue d'ensemble sur les instructions sur un octet, j'ai fait un graphe des instructions sur 2 octets selon cette perspective.
Ça rend les choses beaucoup plus lisibles que je ne l'imaginais!

Penses-bêtes d'instructions
De plus, j'ai regardé chaque instruction utilisateur, et écrit une courte description pour chacun, avec un petit exemple. J'ai fait un exécutable avec tous ces exemples, juste pour voir ces instructions en action - et tester votre émulateur favori ;)

Ça donne 2 petits pense-bêtes pour instructions, l'un en texte imprimable, et l'autre en code exécutable.

Toutes les instructions évidentes sont bien évidemment présentes, mais aussi (puisqu'elles y sont TOUTES):

ARPL, BOUND, LDS, LAR, STR, XADD, SYSENTER,
XLAT, VERR, SALC, AAA, CMPXCHG, SIDT...

autrement dit, 'celles que j'oublie toujours trop vite'.

Opcodes (One-byte overview, two-byte perspective, opcodes' description) (ANGLAIS)
le fichier de test des opcodes (source)

L'exécutable peut ne pas fonctionner sur les (vieux?) processeurs AMD à cause de SYSENTER, et échouer sur une VM ou un OS autre que XP (SIDT, STR, etc...)

Merci à Costin Ionescu et BeatriX.

Anti-pas-à-pas SYSENTER
J'ai remarqué que, comme Int2E, SYSENTER se comporte différemment si lancé ou exécuté pas-à-pas.
Par exemple, avec EAX = 0:
en pas-à-pas,

ECX, EDX = 1, -1.

en exécution normale,

ECX, EDX = esp - 4, @KiFastSystemCallRet.

If you wanna make the world a better place, take a look at ...

2010-03-29T13:04:00.005+01:00

typical packer entry-points
It can be useful to have a reminder of the most usual packers' entry point - especially the light ones, which are likely to be hacked or used as an inner layer.

PDF

I also merged all the current packers graphs (including the new one) into a single PDF.
Features, Landscape, Detailed, Usual EntryPoints

début de packeurs standards
Ça peut être utile d'avoir sous la main le début des packeurs les plus courants - surtout les plus légers, qui ont le plus de chances d'être hackés ou utilisés comme sous-couche.
PDF
J'ai aussi fusionné tous mes graphes actuels sur les packeurs (y compris celui d'aujourd'hui) en un seul PDF.
Features, Landscape, Detailed, Usual EntryPoints

Quand mes 'elles' se froissent et mes 'ils' se noient

2010-03-29T00:35:00.001+01:00

pages on anti-debuggers and PE oddities

I created 2 new pages: one is about anti-debuggers (nothing new, just a compact and a printable form), and the other about PE oddities.

PE Anti

They are in progress - feel free to comment, correct, flame, suggest, etc...

pages sur les anti-débogueurs et les bizarreries du PE

J'ai crée 2 pages: une sur les anti-débogueurs (rien de neuf, juste une forme compacte et imprimable) et une autre sur les bizarreries du PE.

PE Anti

Elles sont en cours d'écritures - n'hésitez pas à commenter, corriger, reprocher, suggérer...

Life's a piece of sh.t, when you look at it

2010-03-28T22:15:00.006+01:00

Overview of one-byte opcodes

I made a simple one-page overview of one-byte opcodes:

PDF

Of course, if you want more info on the opcodes, check x86asm and sandpile.
But sometimes, all I need is just a small reminder.

Une vue d'ensemble des instructions de 1 octet

J'ai fait une vue d'ensemble simplifiée des instructions de 1 octet :
PDF

Bien sûr, pour avoir plus d'informations sur les instructions, allez voir x86asm et sandpile.
Mais parfois, j'ai juste besoin d'un petit rappel, sans avoir besoin de sortir l'artillerie lourde.

Aurais-je été meilleur ou pire que ces gens, si j'avais été...

2010-03-24T23:07:00.003Z

packers' categories and features
Following my graph of the packers' landscape, I made a graph showing the different categories of packers, and what kind of features they have.
Then, to go deeper in details, I made a more detailed list of the various features for each of these kinds.

a graph of the different packers' categories and their features
a detailed list of packers' features

les sortes de packeurs et leurs caractéristiques
Après mon graphe sur le monde des packeurs, j'ai fait un graphe qui montre les différentes catégories de packeurs et le genre de caractéristiques qu'ils ont:
les types de packeurs et leurs caractéristiques (anglais)
ensuite, pour aller plus dans les détails, j'ai fait une liste qui détaille chaque catégories.
list détaillée du fonctionnement interne d'un packeur (anglais)

Je ne prévois pas pour l'instant de faire des versions françaises à mes codes sources ou graphes, faites-moi savoir si ça vous gène.

You can't hide nowhere, with the torchlight on

2010-03-19T01:36:00.003Z

a emptier TinyPE
TinyPE is an impressive project, that explains step-by-step how to make an incredible 97 bytes functional PE. It also shows that a PE can't be any smaller, otherwise IMAGE_OPTIONAL_HEADER32.Subsystem, which is a critical field, wouldn't be defined - it's even already shortened from a word to a byte.

However, the original TinyPE still defines a section and SizeOfOptionalHeader, which are not necessary.
Removing them makes such a PE not only Tiny, but also very small in amount of information - yet it works, naturally, and there's quite some room for code (relatively).
In the end, here are the only defined fields, across all PE headers fields:

.e_magic
...
NT_SIGNATURE
...
Machine
...
Characteristics
Magic
...
AddressOfEntryPoint
...
ImageBase
SectionAlignment ; also e_lfanew
FileAlignment
...
MajorSubsystemVersion
...
SizeOfImage
SizeOfHeaders
...
Subsystem

source binary

un TinyPE encore plus vide
TinyPE est un projet impressionant, qui explique étape par étape comment faire un PE fonctionnel de 97 octets. Il montre aussi qu'on ne peut pas faire un PE plus petit, sans quoi IMAGE_OPTIONAL_HEADER32.Subsystem, qui est un champ critique, ne serait pas défini - il est d'ailleurs déjà réduit de mot à octet.

Cependant, le TinyPE original défini encore une section et SizeOfOptionalHeader, qui ne sont pas nécessaires.
Les enlever fait un PE non seulement ridicule, mais aussi avec une quantité d'information très faible - pourtant il fonctionne, bien évidemment, et laisse relativement pas mal de place pour y mettre du code.
Au final, voici les seuls champs définis, parmi tous ceux des en-têtes de PE:

.e_magic
...
NT_SIGNATURE
...
Machine
...
Characteristics
Magic
...
AddressOfEntryPoint
...
ImageBase
SectionAlignment ; also e_lfanew
FileAlignment
...
MajorSubsystemVersion
...
SizeOfImage
SizeOfHeaders
...
Subsystem

source binaire

Si c'est ton corps qui bouge, c'est ton coeur qui fait tout

2010-03-03T21:33:00.000Z

Getting the current EIP
While standard code starts at a fixed address, there are several cases when your code needs to know its current IP:

after a vulnerability has been triggered, shellcodes can't know in advance where they are executing exactly
packers often allocates a buffer and decompress their next layer of code, which will likely need to locate itself at some point
relocating code is a good way to avoid breakpoints: same code, somewhere else

Thus, I'll enumerate ways to get your current EIP, in a file, on which you can test your emulator or debugger.

Call/Pop

Since Calls push the next address on the stack, you just need to grab it with a POP and will get the current address. Since a standard E8 call is encoded on 5 bytes, such a 'next line' call is often written CALL $ + 5.

call $ + 5
after_call:
pop edx
cmp edx, after_call
jnz bad

FPU

the FPU knows the address of the last executed fpu instruction. so, to get the current IP, use any FPU opcode - even FNOP - then store the FPU environment in memory via F(N)STENV:

_fpu:
fnop
fnstenv [fpuenv]
mov edx,[fpuenv.DataPointer]
cmp edx, _fpu
jnz bad

Interrupts

Interrupts 2C and 2E will put into EDX the next address. If you step on it with a debugger, it will probably not work correctly

int 02eh
after_int:
cmp edx, after_int
jnz bad

Exceptions

When an exception is triggered, the context of the trigger will be put on the stack, so it's possible to know the address of the trigger this way:

handler:
mov eax, [esp + 0ch]
cmp dword [eax + 0b8h], address
jnz bad

Most exceptions are triggered before executing an incorrect line:

xor eax, eax
_on_the_instruction:
mov [eax], eax

Some exceptions are triggered AFTER executing an instruction that launched them (on purpose):

db 0f1h ; IceBP
_trigger_after_execution

And then some exceptions are triggered the instruction after, to enable stepping:

push 302h
popf
jmp bad
_after bad

Have fun! If I missed something, drop a comment!

Binary Source

Obtenir l'EIP courant
Alors que du code standard commence d'habitude à une adresse fixée, il y a plusieurs cas où votre code a besoin de savoir son adresse courante:

après qu'une vulnérabilité soit exploitée, les shellcodes ne peuvent pas savoir à l'avance où ils s'exécutent exactement
les packeurs allouent souvent une mémoire tampon et y décompressent leur couche de code suivante, qui aura besoin de savoir sa propre adresse
déplacer du code est une façon facile de contourner les points d'arrêt: même code, mais autre part

Je vais donc énumérer les méthodes existantes dans un fichier qui vous permettra de vérifier le comportement correct de votre émulateur ou débogueur.

Call/Pop

Puisque les instructions de type Calls mettent l'adresse suivante sur la pile, on a juste besoin de la récupérer avec un POP. Et puisque un E8 call standard est encodé sur 5 octets, un tel 'appelle la ligne suivante' est souvent écrit CALL $ + 5.

call $ + 5
after_call:
pop edx
cmp edx, after_call
jnz bad

FPU

Le coprocesseur arithmétique sait à quelle adresse a eu lieu la dernière instruction FPU. Donc, pour obtenir l'adresse courante, utilisez n'importe quel instruction FPU - même FNOP - et ensuite stockez l'environnement FPU en mémoire via F(N)STENV :

_fpu:
fnop
fnstenv [fpuenv]
mov edx,[fpuenv.DataPointer]
cmp edx, _fpu

Interruptions

Les interrupts 2C et 2E mettrons dans EDX l'adresse suivante. Si vous êtes en pas-à-pas avec un débogueur, cela ne marchera probablement pas.

int 02eh
after_int:
cmp edx, after_int
jnz bad

Exceptions

Quand une exception est déclenchée, le contexte lors du déclenchement est stocké dans la pile, donc il est possible de savoir l'adresse de cette façon.

handler:
mov eax, [esp + 0ch]
cmp dword [eax + 0b8h], adresse
jnz bad

La plupart des exceptions sont déclenchées avant l'exécution d'une ligne incorrecte :

xor eax, eax
_on_the_instruction:
mov [eax], eax

Certaines seront déclenchées APRÈS une instruction qui les a appelée (volontairement) :

db 0f1h ; IceBP
_trigger_after_execution

Et enfin, certaines exceptions sont déclenchées après l'instruction SUIVANTE, pour permettre le pas-à-pas logiciel :

push 302h
popf
jmp bad
_after bad

Amusez-vous bien ! Si j'ai oublié quelque chose, laissez-moi un commentaire !

Binaire Source

no, I'm your father

2010-03-01T22:01:00.003Z

misc news
Opcodes 'complete'

my file listing all known 32 bits opcodes is almost done: everything documented should be in (including AVX, XOP, Padlock, LWP), and 99% of undocumented stuff I can think of is in (to be blogged later)
Source

Packers graph now printable

I updated my packer's landscape graph, with a few fixes, and now printable. (tbbl) PDF

MakePE : Exports, Relocs

In order to make custom PE myself, I generate the structure manually. However, it would be very annoying to generate manually everything everytime, so my MakePE script makes it easy to generate, for example, an import table. It's just an ASM pre-processor.
As I just added support for exports and relocations, this piece of code would generate a complete export entry in a DLL:

;%EXPORT DbgPrint
mov ebx, [esp+4]
push MB_ICONINFORMATION ; UINT uType
;%reloc 1
push Driver ; LPCTSTR lpCaption
...
;%reloc 2
;%IMPORT user32.dll!MessageBoxA

;%IMPORTS
;%EXPORTS dll.dll
;%relocs

Blog Map

I created a separate page (updates won't be mentioned in the RSS feed) to make it easier to find older blog entries. It will also tell you what I plan to blog on - and might be already in the source repository.

PE headers graph

Since its initial release, I did minor changes to my PE headers' graph, with a lighter layout and 64 bits information.

nouvelles diverses
Opcodes 'complet'

Mon fichier qui énumère tous les opcodes 32 bits est presque fini: tout ce qui est documenté devrait y être (y compris AVX, XOP, Padlock, LWP), et 99% de ce qui n'est pas documenté devrait y être (j'en reparlerais dans un billet dédié).
Source

graph sur les Packers: imprimable

J'ai mis à jour mon graph sur le monde des packeurs, avec quelques correctifs, et il est maintenant imprimable (billet à venir) PDF

MakePE : Exports, Relocs

Pour faire des PE spéciaux, je génère la structure à la main. Ça serait néanmoins très répétitif de tout générer à chaque fois, donc mon script MakePE permet de générer facilement, par exemple, une table d'import. C'est juste un préprocesseur pour fichier assembleur.
Comme je viens d'ajouter la gestion des exports et des relocations, ce bout de code génère un export complet dans une DLL :

;%EXPORT DbgPrint
mov ebx, [esp+4]
push MB_ICONINFORMATION ; UINT uType
;%reloc 1
push Driver ; LPCTSTR lpCaption
...
;%reloc 2
;%IMPORT user32.dll!MessageBoxA

;%IMPORTS
;%EXPORTS dll.dll
;%relocs

Carte du blog

J'ai créé une page séparée (les changements ne seront pas mentionnés dans le flux RSS) pour pouvoir retrouver facilement des vieilles entrées du blog. Ça vous montrera aussi ce sur quoi j'ai l'intention d'écrire - et qui est peut-être déjà dans le dépôt du source.

graphe: en-têtes PE

Depuis sa diffusion initiale, j'ai fait quelques changements mineurs dans mon graphe sur les en-têtes du PE, avec une mise en page plus légère et les informations 64 bits.

And when I start to come undone, stitch me together

2010-02-28T23:11:00.001Z

Exception triggers
Structured Exceptions Handling is a complex mechanism that makes many anti-debuggers / anti-emulators possible. After setting a handler (check Subtle SEH for exotic ways, but never used in the wild), you trigger the exception. And typically, packers rely blindly on the trigger itself, such as the actual error code: in short, trigger the wrong exception, and execution will fail (tampering is deected).
The most common ones are:

Int3 BREAKPOINT 080000003h
mov [0], ... ACCESS_VIOLATION 0c0000005h

But what about the rest?

I put together common exception triggers. There is no point listing all of them and all possible triggers, just common ones found in packers or malware, or the ones with a non-obvious behavior.

Access violation

This is probably the most common one, as it can happen 'naturally'. Access a wrong address, and it will trigger. Note that would also happen on trying to write a readonly address.
Also, most interrupts, including CD01 Int 1 and CD20 int 20h, will trigger this exception. This is different from F1 IceBP, which is sometimes written Int1, and triggers a Single step exception, and Int 20h used to be for VxdCalls under Windows 9x, so this is not relevant today anymore.

To be exact, all interrupts 00-FFh, except 3, 4, 2A-2E, trigger this exception.

Breakpoint

One of the most common, as it's triggered by CC Int3. It's also triggered by it's double bytes counterpart CD03 Int 3.
It's also triggered by CD2D Int 2Dh, but that one is special: no exception is triggered if a debugger is present, which makes it a stealth anti-debug. It's quite interesting to see that one with your own debugger, the best way to avoid it is to patch it with another Breakpoint trigger like CC. However, a packer using this trick will likely check the bytes that triggered the exception, so pay attention ;)
Last, calling the API kernel32.dll!DebugBreak, does, as expected, execute an Int3. This is just the 'clean' way to trigger a breakpoint exception.

Page guard violation

Similar to access violation, this exception can be triggered by accessing an address with the PAGE_GUARD memory protection. However, this is the technic that OllyDbg itself uses for software memory breakpoint, so OllyDbg will just stop and give a message

Break-on-access when executing [....]

instead of offering you to skip the exception as usual

Use Shift+F7/F8/F9 to pass exception to program

, which makes things annoying.

Privileged Instruction

That one is quite straightfoward. Typically it's triggered with opcodes such as F4 HLT, FA cli, FB sti. If you're debugging a driver in user mode, operations such as accessing 0F20C0 mov eax,cr0 will trigger it. And the classic anti-vmware in 'VMXh', 'VX' will trigger it, if not in vmware.

Single step

Single step exception occurs AFTER the 'undocumented' F1 IceBP/Int1. The other ways to trigger is using the hardware breakpoints - but that's worth a dedicated blog entry - and setting TF, the trap flag (100h in EFLAGS), via 9d popf or an context change (exception, SetContext). In the case of TF, the exception is triggered after the FOLLOWING instruction is executed, which makes you think nothing happens while stepping.

Invalid Handle

Invalid Handle is triggered when an API is called with an invalid handle, and is usually handled internally by the system. However, OllyDbg fails to skip it - even if you explicitly bypass it - so it makes it an easy anti-ollydbg. Using OllyAdvanced or a similar plugin will help to fix the problem.
This exception is usually triggered by kernel32.dll!CloseHandle, but there are many other possibilities such as advapi32.dll!RegCloseKey

Invalid lock sequence

F0 Lock is a prefix that can only be used on specific opcodes (add/xadd/adc/or/and/sub/sbb/xchg/dec/inc/not/neg (*NOT* mov!), btr/btc/bts (not bt), cmpxchg/cmpxchg8b), and on memory operands only, so using it on even a F090 lock: nop will trigger an exception, or a F000c0 lock: add eax, eax.
it also became famous for crashing Pentium CPUs via f00fc7c8 lock:cmpxchg8b eax.

Integer overflow

Integer overflow is a standard exception that can be triggered on typical arithmetical operations, such as DIV, but also by CD04 int 4 - the only interrupt to do so - and CE into, which triggers on OF, which is the only conditional interrupt.

the File

The file itself implements all these triggers and exceptions. Because of the Int2D/Page Guard/CloseHandle, it will not run easily under a naked OllyDbg. And All interrupts are generated and triggered, so it triggers in total 264 exceptions.

Binary

Let me know if I missed a trigger that is commonly used as an anti-analysis.

déclencheurs d'exceptions
les SEH (Structured Exceptions Handling) sont un mécanisme complexe qui permet beaucoup d'anti-débogueurs/anti-émulateurs. Après avoir défini le handler (voir Subtle SEH pour des façons exotiques mais jamais utilisées en vrai), on peut déclencher l'exception. Et en général, les packeurs utilisent directement les caractéristiques du déclenchement lui-même, tel que son code d'erreur: en raccourci, déclenchez la mauvaise exception, et l'exécution échouera (quelque chose d'anormal a été détecté).
Les plus communs sont :

Int3 BREAKPOINT 080000003h
mov [0], ... ACCESS_VIOLATION 0c0000005h

Mais qu'en est-il du reste ?

J'ai rassemblé les déclenchements d'exception répandus. Il n'y a pas d'interêt à les énumérer tous, donc juste ceux qu'on trouve communément dans les packeurs et les malwares, ou ceux dont le comportement est inattendu.

Access violation

C'est probablement le plus répandu, puisqu'il peut arriver 'naturellement'. Accédez à une adresse inexistante, et cela déclenchera. Cela se produit aussi si on essaie d'écrire à une adresse en lecture seule.
De même, la plupart des interruptions, y compris CD01 Int 1 et CD20 int 20h, vont déclencher cette exception. C'est différent de F1 IceBP, parfois écrit Int1 et qui déclenche une exception Single Step, et Int 20h était avant utilisée pour les VxdCalls sous Windows 9X, ce qui n'est plus d'actualité.

Pour être exact, toutes les interruptions de 0 à FFh, exceptées 3, 4, 2A-2E, déclenche cette exception.

Breakpoint

Une des plus communes, puisqu'elle est déclenchée par le point d'arrêt logiciel, CC Int3. Elle est aussi déclenchée par son équivalent sur 2 octets, CD03 Int 3.
Elle est aussi déclenchée par l'interruption CD2D Int 2Dh, mais celle-ci est spéciale: aucune exception n'est déclenchée si un débogueur est présent, ce qui en fait un anti-débogueur silencieux. C'est plutôt intéressant à voir sous son propre débogueur, et la meilleure façon de l'éviter est de patcher avec un autre déclencheur de Breakpoint tel que CC. Cependant, un packeur utilisant cette astuce vérifiera les octets originaux dès que possible, donc gardez l'oeil ouvert ;)
Enfin, appeler l'API kernel32.dll!DebugBreak fera, comme on si attend, exécuter une Int3. C'est la façon propre de déclencher une exception de type Breakpoint.

Page guard violation

Un peu comme l'exception 'access violation', cette exception sera déclenchée en accédant à une adresse qui est protégé par l'accès PAGE_GUARD. Par contre, c'est la technique qu'OllyDbg lui-même utilise pour les points d'arrêts mémoire logiciel, donc OllyDbg s'arrêtera tout simplement en donnant le message

Break-on-access when executing [....]

plutôt que l'habituel

Use Shift+F7/F8/F9 to pass exception to program

ce qui complique les choses.

Privileged Instruction

Cette exception est directe: d'habitude, elle est déclenchee par des opcodes tels que F4 HLT, FA cli, FB sti. Si vous déboguez un driver en mode utilisateur, des opérations tels qu'accéder à cr0 (0F20C0 mov eax,cr0) la déclencheront. Et l'anti-vmware classique in 'VMXh', 'VX' la déclenchera - si on n'est pas sous VmWare.

Single step

L'exception Single step se produit APRÈS l'opcode 'non documenté F1 IceBP/Int1. L'autre manière de la déclencher est les points-d'arrêts matériels - mais ça justifie un billet dans ce blog à eux seuls - et lever le drapeau TF, appelé trap flag (100h dans EFLAGS), via 9d popf ou un changement de contexte (exception, SetContext). Dans le cas de TF, l'exception sera déclenchée après l'exécution de l'instruction SUIVANTE, ce qui laisse penser que rien ne se produit lors de l'exécution pas à pas: popf - exécution - exception !

Invalid Handle

Invalid Handle est déclenchée quand une API est appelée avec un handle invalide, et est gérée par le système en interne. Cependant, OllyDbg n'arrive pas à la passer silencieusement - même si on l'a bien précisée dans les options - ce qui en fait un anti-Ollydbg facile. Utiliser OllyAdvanced ou un plug-in similaire pourra résoudre ce problème.
Cette exception est déclenchée d'habitude par kernel32.dll!CloseHandle, mais il y a beaucoup d'autres possibilités telles que advapi32.dll!RegCloseKey

Invalid lock sequence

F0 Lock est un préfixe qui ne peut être utilisé que certains opcodes spécifiques (add/xadd/adc/or/and/sub/sbb/xchg/dec/inc/not/neg (*PAS* mov!), btr/btc/bts (PAS bt), cmpxchg/cmpxchg8b), et sur la mémoire uniquement, donc même un innocent F090 lock: nop va déclencher l'exception, de même qu'un F000c0 lock: add eax, eax.
Il est aussi devenu célèbre pour faire planter les processeurs Pentiums via f00fc7c8 lock:cmpxchg8b eax.

Integer overflow

Integer overflow est une exception pouvant être déclenchée par une opération arithmétique standard telle que DIV, mais aussi par CD04 int 4 - la seule interruption à le faire - et CE into, qui déclenche sur le drapeau OF, qui est la seule interruption conditionnelle.

le fichier

Le fichier implémente tous ces déclencheurs et exceptions. À cause des Int2D/Page Guard/CloseHandle, il ne tournera pas directement sous un OllyDbg nu. Et, comme toutes les interruptions sont générées et déclenchées, il déclenchera au total 264 exceptions.

Binaire

N'hésitez pas à me signaler si j'ai oublié une exception ou un déclencheur particulier, utilisé comme anti-analyse.

I have legalised robbery - called it belief

2010-02-26T22:58:00.002Z

Real life security (fails?)
How secure is your network if your front door is wide open?

Lock

Like software protection (and, say, virtualization), a different design in locks can bring added protection and extra features. If you are interested in your own front door security, I advise reading about the fascinating Geminy Lock and Abloy articles here. It's impressive to see that a Geminy withstood more than 30 minutes of continuous attacks, and that an Abloy can have 2 different keys (one to open and one to close).
Also, even more fascinating (analysed in the 'Abloy special products' PDF), the Rosengrens RKL-10, which is resettable: lost your keys? order a new set and reset the lock! But this unique feature doesn't make it necessarily weaker.

Hotel room

Following the video about the Dubai assassination,
,
Barry Wels blogged to enlighten us: this video shows you don't need to be a hacker to enter a hotel room:

House alarm

I was personally quite shocked to discover that disabling a (standard) house alarm doesn't need any special tool (no security screw or anything, just tampering detection), which proves that it doesn't really protect you from anything - except maybe your own insurance.

(Echec de ?) Sécurité dans la vie réelle
Quelle est la securité de votre réseau si votre porte d'entrée est grande ouverte ?

Serrure

Comme les protections logicielles (et, par exemple, la virtualisation), une conception différente de serrure peut améliorer la protection et apporter de nouvelles possibilités. Si vous êtes intéressés par la sécurité de votre propre porte d'entrée, je vous conseille de lire au sujet des fascinantes serrures Geminy et Abloy ICI. C'est impressionant de voir que le Geminy ait pu tenir plus de 30 minutes d'attaques permanentes (sans céder ni devenir inutilisable), ou que le Abloy permette 2 clefs différentes (une pour ouvrir et une pour fermer).
De même, encore plus fascinant, le Rosengrens RKL-10 (présenté dans le PDF 'Abloy special products'), qui est réinitialisable: vous avez perdu vos clefs ? achetez un nouveau trousseau et réinitialisez la serrure! mais cette possibilité unique ne l'a pas rendu plus vulnérable..

Chambre d'hôtel

À la suite de la vidéo sur l'assassinat à Dubai,
,
Barry Wels a écrit pour éclairer notre lanterne: cette vidéo montre qu'on n'a pas besoin d'être un hackeur pour pénétrer dans une chambre d'hôtel sans effraction:

Alarme domestique

J'ai été personnellement plutôt choqué de découvrir que désactiver une alarme domestique (standard) ne nécessite aucun outil particulier (aucune vis de sécurité ni rien, juste une détection d'effraction, sûrement évitable ou annulable), ce qui prouve que ça ne protège pas vraiment de quoi que ce soit - à part peut-être de votre assurance.

Combien d'échecs avant que l'on comprenne? et d'autos brûlées, pour voter...

2010-02-25T11:45:00.001Z

Libdasm downloads
I don't have much time lately for Libdasm, but it's not a reason to ignore it totally.
I think it was a bad idea to remove downloads (and binaries?), let me know what you think!
On one hand, it's handy to just have source in one click, but on the other hand, I don't think it's that relevant to bundle binaries,
because they depend on your compiler or OS, and if you code, well, you're likely to have the compiler (and it compiles quickly and easily).

Let me know what you think, by commenting or replying in the group

In the meantime I added the original archive, and the current source as downloads.

Téléchargements pour Libdasm
Je n'ai pas beaucoup de temps à consacrer à Libdasm ces temps-ci, mais ce n'est pas une raison de le laisser tomber dans l'oubli. Je pense que c'était une erreur de jugement de supprimer les téléchargements (et les binaires?), dites-moi ce que vous en pensez!
D'un coté, c'est pratique d'avoir le source en un seul click, mais d'un autre coté, je ne pense pas que ça soit cohérent d'inclure les binaires, car ils dépendent de votre compilateur et OS, et si vous programmez, on s'attend à ce que vous ayez le compilateur (et libdasm se compile vite et bien).

Dites-moi ce que vous en pensez, par exemple en laissant un commentaire.

En attendant, j'ai mis à disposition la dernière version officielle, et le source de la version en cours.

None can outrun or equal ... the power ... of Megablast

2010-02-23T23:54:00.008Z

a graphical representation of the packers landscape
I created a graphical representation of the packers' landscape. It's certainly far from complete (could it ever be, honestly ?), but it might be useful to you.

Comments are welcome!

PDF svg

une représentation graphique du monde des packeurs
J'ai fait une représentation graphique du monde des packeurs. Ce n'est sûrement pas complet (comment pourrait-ce l'être ?), mais ça peut vous être utile.

Les commentaires sont les bienvenus.

PDF svg

Just remember, it's not so long since you were young

2010-02-17T21:57:00.004Z

English only?
I removed the previous poll since it looks like it was not worth it - my twitter will stay suspended ;)

However, now I'm asking you if you're ok with this blog being bilingual, English first then French.
It might annoy English reader, or fustrate french readers. Or maybe French readers only read the english part.
the 3 possible conclusions of that poll would be:
- keep as is
- split french into another blog
- remove french

the poll is on your right.

Isoler le Français?

J'ai enlevé le sondage précédent, il semble que ça n'en valait pas la peine - mon twitter restera inactif ;)

Cependant, je vous demande maintenant si c'est bien que ce blog soit bilingue (Anglais puis Français): vous ne lisez que la partie anglaise ? l'anglais vous gène et vous aimeriez le français sur un blog indépendant ? faites-le savoir!
Les 3 décisions envisagées à la suite de ce sondage sont :
- garder tel quel
- isoler le français dans un autre blog
- supprimer le français

le sondage est à votre droite sur la page.

葉っぱ一枚あればいい

2010-02-13T09:16:00.010Z

Drivers in user-mode

Ever wanted to trace a driver directly from OllyDbg, without the usual

Unable to start file 'driver.sys'

Why

I already introduced the basics of a driver, at PE level.
It might be interesting to run a driver in user-mode, for example, to unpack it:
On one hand, if a driver is packed, you just won't be able to quickly run and dump it the usual way, so you'd have to use a kernel debugger.
On the other hand, typically, packed drivers unpack themselves with no or few API calls, no or few privileged instruction, which makes you think:
'this is standard user-mode code that just runs inside a driver to unpack itself, if only I could just run it the usual way'.

Loading the driver

But there are 2 things that prevent Driver.sys from loading under a user-mode debugger:
The Subsystem itself: the file will just refuse to load if it's Native, so just change that to Gui or Console, either manually or with a line of PEFile:

p.OPTIONAL_HEADER.Subsystem = 2
# = pefile.SUBSYSTEM_TYPE['IMAGE_SUBSYSTEM_WINDOWS_GUI']

Then, a driver will import ntoskrnl.exe, which will eventually fail in user-mode.
If you don't need APIs - or can emulate them manually - the easiest solution is just to get rid of the imports altogether. Just delete the RVA of the Imports data directory - with PEFile, that translates as:

p.OPTIONAL_HEADER.DATA_DIRECTORY[1].VirtualAddress = 0

So, now you have a driver, without imports - which means it won't be able to call any API - that will load in OllyDbg. Maybe that's enough to reach code after the unpacking stub - most kernel packers are not complex - and then get the original file.

Further

Even though ntoskrnl.exe is Native itself, it's loaded like any other file (from user-mode), so if you want to be able to run a few API calls in your driver, a solution is to create a fake ntoskrnl.exe, and emulate the required APIs.
A normal file with exports and relocations will do.
In my example, I redirected ntoskrnl.exe!DbgPrint to user32.dll!MessageBoxA, which makes the HelloWorld driver work directly from your explorer window.

This turns the original kernel-level call

push helloworld
call DbgPrint

into a standard MessageBoxA call

00400216 CALL to MessageBoxA from ntoskrnl.00400211
00000000 hOwner = NULL
00010215 Text = "Hello World!"
00400217 Title = "User mode Ntoskrnl"
00000040 Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL

However, after the Subsystem and the APIs, the extra problem is that the driver might use privileged instructions, such as

FB sti
FA cli
0F20C0 mov eax, cr0
0F22C0 mov cr0, eax

Besides nopping each of them, there is no generic solution, as they might be obfuscated. A possible solution would be to load the executable with your own SEH, to skip such instructions (Exception: PRIVILEGED INSTRUCTION, 0C0000096h).
I am not sure it's worth the trouble, if it gets too complicated, you're just better with a kernel debugger.

Detection

Also, it's possible to detect if you're executed in user-mode (which is not the same as detecting kernel or user debuggers), for example by checking the value of CS:

default CS under XP
user mode 1B
kernel mode 8

HelloWorld driver, Sys2Exe python script, fake Ntoskrnl
Sources and binaries
(compile with MakePE)

Drivers en mode utilisateur

Avez-vous déjà voulu analyser un driver directement depuis OllyDbg, sans l'habituel

Unable to start file 'driver.sys'

Pourquoi

J'ai déjà parlé des bases des drivers, au niveau PE.
Ça peut être interessant d'exécuter un driver en mode utilisateur, par exemple pour le décompresser :
D'un coté, si le driver est packé, on ne peut pas le lancer et le dumper rapidement comme d'habitude, donc on devrait utiliser un débogueur noyau.
D'un autre coté, la plupart du temps, les drivers packés se décompressent eux-même en n'utilisant aucune ou très peu d'APIs, aucune ou très peu d'instructions privilégiées, ce qui nous amène à penser:
'C'est du code utilisateur normal, dans un driver. Si seulement je pouvais l'exécuter comme d'habitude'

Charger un driver

Mais il y a 2 choses qui empêchent Driver.sys de s'exécuter dans un débogueur utilisateur:
Le Subsystem lui-même: le fichier refusera tout simplement de se charger s'il est Native, donc changez le en Gui ou Console, manuellement ou avec une ligne de PEFile:

p.OPTIONAL_HEADER.Subsystem = 2
# = pefile.SUBSYSTEM_TYPE['IMAGE_SUBSYSTEM_WINDOWS_GUI']

Ensuite, le driver importe ntoskrnl.exe, ce qui finira par échouer en mode utilisateur.
Si on n'a pas besoin des APIs - ou qu'on peut les simuler à la main - la solution la plus simple est de se débarasser directement des imports. Il suffit de supprimer la RVA du data directory Imports - avec PEFile, cela donne:

p.OPTIONAL_HEADER.DATA_DIRECTORY[1].VirtualAddress = 0

Donc, on a maintenant un driver sans imports - donc qui ne pourra pas appeler d'API - qui marchera dans OllyDbg. Peut-être ça suffira pour atteindre le code après la décompression - la plupart des packeurs noyaux ne sont pas complexes - et d'obtenir le fichier original.

Un peu plus loin

Même si ntoskrnl.exe est lui-même Native, il est chargé comme n'importe quel fichier (depuis le mode utilisateur), donc si on veut exécuter quelques appels API depuis notre driver, une solution est de créer un ntoskrnl.exe factice, qui émulera les APIs requises.
Un fichier normal avec exports et relocations suffira.
Dans mon exemple, j'ai redirigé ntoskrnl.exe!DbgPrint vers user32.dll!MessageBoxA, ce qui permet au driver HelloWorld de marcher directement depuis votre fenêtre d'explorateur.

Cela change l'appel original au niveau noyau

push helloworld
call DbgPrint

en un appel MessageBoxA standard

00400216 CALL to MessageBoxA from ntoskrnl.00400211
00000000 hOwner = NULL
00010215 Text = "Hello World!"
00400217 Title = "User mode Ntoskrnl"
00000040 Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL

Cependant, après le Subsystem et les APIs, un problème possible est que le driver utilise des instructions privilégiées, telles que

FB sti
FA cli
0F20C0 mov eax, cr0
0F22C0 mov cr0, eax

A part nopper chacune d'entre elles, il n'y a pas de solution générique, puisqu'elles pourraient être dissimulées. Une solution possible serait de charger l'exécutable avec votre propre SEH, pour sauter de telles instructions (Exception: PRIVILEGED INSTRUCTION, 0C0000096h).
Je ne suis pas sûr que ça en vaille la peine, si ça devient trop compliqué, autant utiliser un débogueur noyau.

Détection

D'autre part, il est possible de détecter si on est exécuté en mode utilisateur - ce qui n'est pas la même chose de détecter un débogueur noyau ou utilisateur - par exemple en vérifiant la valeur de CS:

valeur par défaut de CS, sous XP
niveau utilisateur 1B
niveau noyau 8

driver HelloWorld, script python Sys2Exe, Ntoskrnl factice
Sources et binaires
(compiler avec MakePE)

Militant quotidien de l'inhumanité

2010-02-09T22:40:00.003Z

TLS and Imports

When is an apparently incorrect TLS entry actually executing a file ?

I already introduced TLS:
before execution of the Entrypoint, each callback is taken as is - since it's a VA - and executed, until a null entry or an exception occurs.

linked to Imports

But if you make the callbacks point to one of the imports:

AddressOfCallBacks dd __imp__WinExec

In the file, the import to WinExec will originally point to a Hint+Name structure:

WinExec:
jmp [__imp__WinExec]

__imp__WinExec:
DD aWinExec - IMAGEBASE ; RVA
DD 0

aWinExec:
dw 0 ; Hint
db 'WinExec',0 ; Name

so it doesn't look like it's a valid VA. At least, not yet.

Once the file is loaded, it will points to the API.

0040026C:
7C86250D kernel32.WinExec

So it's 'now' a valid VA, and TLS execution will happen correctly.

Arguments

You're calling an API, but you just don't control the parameters.
If it's your own DLL, you could still do anything. In any case, the first parameter on the stack is actually the IMAGEBASE, which points to the start of the file. Thus, MZ... and nothing prevents this signature to be taken as a normal parameter:

EIP 7C86250D kernel32.WinExec

Stack:

7C90118A CALL to WinExec from ntdll.7C901187
00400000 CmdLine = "MZ"
00000001 ShowState = SW_SHOWNORMAL

(7C90118A corresponds to NtDLL's LdrInitializeThunk + 24, which is indeed TLS execution return)

So, what will it do ? Execute a file named MZ. Or, if you modify the header a bit more, a file named MZsomething.

Thus, with an obscure TLS entry, you get a free pre-entry point API call - here, a file execution.

This is a funny trick by Peter Ferrie in his comment.

Binary and source

TLS et Imports

Quand est-ce qu'un TLS apparemment incorrect exécute correctement un fichier ?

J'ai déjà parlé du TLS:
avant l'exécution de l'Entrypoint, chaque callback est pris tel quel - puisque c'est une adresse virtuelle - et exécuté, jusqu'à une entrée nulle ou qu'une exception se produise.

TLS et imports

Mais si on fait pointer un des callbacks vers un des imports:

AddressOfCallBacks dd __imp__WinExec

Dans le fichier, l'import vers WinExec pointe initialement vers une structure Hint+Name:

WinExec:
jmp [__imp__WinExec]

__imp__WinExec:
DD aWinExec - IMAGEBASE ; RVA
DD 0

aWinExec:
dw 0 ; Hint
db 'WinExec',0 ; Name

donc ça n'a pas l'air d'une VA valide. Du moins, pas pour l'instant.

Une fois que le fichier sera chargé, cela pointera vers l'API en mémoire.

0040026C:
7C86250D kernel32.WinExec

Donc c'est 'à présent' une VA valide, et l'exécution du TLS se produira correctement.

Paramètres

Vous appelez donc une API, sans contrôler les paramètres.
Si c'est votre propre DLL, vous pouvez faire ce que vous voulez. Dans tous les cas, le premier paramètre sur la pile est l'IMAGEBASE, qui pointe vers le début du fichier. MZ, donc...et rien n'interdit cette signature d'être interprétée comme un paramètre normal:

EIP 7C86250D kernel32.WinExec

Stack:

7C90118A CALL to WinExec from ntdll.7C901187
00400000 CmdLine = "MZ"
00000001 ShowState = SW_SHOWNORMAL

(7C90118A correspond à NtDLL LdrInitializeThunk + 24, qui est effectivement le point de retour des TLS)

Donc, que va-t-il se passer ? Un fichier nommé MZ sera exécuté. Ou, si on modifie l'en-tête, un fichier nommé MZquelquechose.

Donc, avec un TLS bizarre, on obtient gratuitement un appel d'API avant l'EntryPoint - dans le cas présent, l'exécution d'un fichier.

Merci à Peter Ferrie pour cette astuce dans son commentaire.

Binaire et source

If you want to strike me down in anger

2010-02-08T22:17:00.004Z

Messing with loops
Do you understand these snippets?

setz ah setnz cl
aad 11 xor eax, eax
add eax,04000f3 mov fs:[eax], esp
jmp eax ror cl, 01
into

the problem

When reversing a program, fast forwarding by skipping loops is important - no one wants to step through each iteration. Also, detecting loop behavior is important in emulators, especially when extra loops are inserted to make them time out.

Let's take a simple example:

If you want to reset ECX and artificially create unneededed computing cycles, you can use

E2FE loop $

which just decrements ECX until it's zero. It might take several seconds (!), even if it's a simple operation altogether. So, it might be critical to detect and fast-forward it (emulate all its cycles at once). For a manual analysis, the skip is trivial.

So, to make either time-constrained emulation or manual analysis harder, you can make your loop harder to detect. Typically, when you analyze loops, you'll find the conditional jump, identify the exit point, and set a breakpoint on it.
Making the conditional jump or the exit point harder to find is what you'd be looking for to make reversing harder.

No Jxx

An easy way to hide the conditional jump and the exit address is to merge both jumps (to loop start and exit) in a single, calculated, unconditional jump, like this:

jmp loop_start + (condition) * (loop_end - loop_start)

So, after your loop condition, which sets some flag

dec cl

turn the flag into a number (0 or 1, then)

setz reg16

multiply by the distance between loop start and end

mov eax, loop_end - loop_start
mul reg16

or, in an unsual way (on AH only)

aad loop_end - loop_start

add the start address

add eax, loop_start

now you can jump inconditionally

jmp eax

Now, you get a standard loop, but with only one jump to both continue and exit, and you have to dig into the code to compute in advance the exit point. Obfuscating the critical information 'end - start' will make it even more difficult to exit from this loop quickly, especially because in this case the loop_exit might not be near the loop body.

a needle in the haystack

Another way is to add several decoy conditional jumps. Make them, as well as the real exit conditional jump, obfuscated (ie, jump on a comparison with 05fb4e3 instead of 0, with the counter hidden somewhere), make them jump to code being decrypted (to prevent software breakpoints), make more than 4 of them (to exhaust hardware breakpoints), and you get a loop that you can't exit of easily, for which you need to check every execution of each of these conditional jumps.
I made a simple example, in which 4 different registers are influenced by a counter (left obvious on purpose here), and compared to odd values, then jumping to different destinations:

cmp ax,0cafb
je 00400130
...
cmp bx,0bf21
je 0040012f
...
cmp dx,0c0d1
je 0040012e
...
cmp si,0bab0
je 00400131

Of course, this example is simplified. Add more junk code and randomization, you'll get what a few packers do.

SEH obfuscation

Peter Ferrie wrote an interesting kind of obfuscated loop:

push 3
pop ecx
call l1
pop eax
pop eax
pop esp
pop ecx
l1:
dec ecx
push ecx
setne cl
xor eax, eax
mov dword ptr fs:[eax], esp
ror cl, 01
into

In this case, the counter is decremented with a

dec ecx

which sets ZF.

the ZF flag is moved to OF by the combination of

setne cl ; cl = ZF ? 0 : 1
ror cl, 01 ; cl = ZF ? 0 (OF cleared) : 80 (OF set)

and the hidden conditional jump is

CE into

which triggers Int4 if OF is set, and nothing otherwise.

In short, this loop works by setting an exception handler, then, depending on ZF then OF, trigger an exception via Int4 (and loop) or just exit the loop.
However the devil is in the details:
the PUSH ecx both saves the counter on the stack, and set the right structure for an SEH (even though the next forwarder is wrong, since it will be the value of the counter and not the next SEH in the chain).

00000002 Pointer to next SEH record
004000F8 SE handler

Also, to restore ESP on each exception iteration, instead of using 4 bytes:

8b642408 mov esp,[esp+8]

It's implemented as 2 discarded pop and a real one, which is 3 bytes

58 pop eax
58 pop eax
5c pop esp

That's 3 examples of obfuscated loops, and the first 2 are used in widespread packers (Waledac, PESpin) already.

Update:
Hiding the counter and exit

Another idea, suggested by Baboon, is to replace the counter increment with something more random-looking, such as a LFSR, to prevent an easy guess of the required amount of iterations, and at the same time, have the loop exit address updated at each iteration, so that it's only correct at the last iteration:

lfsr32 edx, 0d0000001h
xor dword [loop_exit], edx ; exit address is updated blindly

lfsr16 cx, 0b400h
cmp cx, 0eaa2h ; this will be true on the 35th iteration
jnz loop_start

jmp [loop_exit] ; exit address is jumped to blindly

Here, both lfsr are independant. It would be worse if the loop exit also depends on the counter lfsr.

Source and binary

Note that you need to update the last loop_exit variable manually in the source, as YASM doesn't seem to support 'complex' operations such as:

loop_exit dd loop_end ^ Key

[...]

Bidouiller avec les boucles
Vous voyez ce que font ces bouts de code ?

setz ah setnz cl
aad 11 xor eax, eax
add eax,04000f3 mov fs:[eax], esp
jmp eax ror cl, 01
into

Énoncé du problème

Quand on analyse un programme, gagner du temps en sautant les boucles est important - personne ne veut faire du pas à pas sur chaque itération. De même, détecter les boucles est important dans les émulateurs, surtout si on a ajouté des boucles superflues pour les faire abandonner.

Prenons un exemple simple :
Si vous voulez mettre ECX à zéro, et créer des cycles d'exécution supplémentaires, vous pouvez utiliser

E2FE loop $

qui décrémente juste ECX jusqu'a ce qu'il soit nul. Cela peut prendre plusieurs secondes (!), même si c'est au final une opération très simple. On comprend qu'il soit critique de détecter et de l'accélérer (émuler tous les cycles d'un coup). Lors d'une analyse manuelle, la sauter est trivial.

Donc, que ce soit pour rendre plus difficile une émulation en temps limité ou une analyse manuelle, on peut rendre une boucle plus difficile à détecter. D'habitude, quand on analyse une boucle, on trouve le saut conditionnel, on identifie le point de sortie, puis on y met un point d'arrêt.
Rendre le saut conditionnel ou le point de sortie plus difficile à trouver est ce qu'on cherchera pour rendre l'analyse ardue.

pas de Jxx

Un moyen facile de cacher le saut conditionnel et le point de sortie est de fusionner les deux sauts (vers le début et la fin de la boucle) en un seul, calculé, saut inconditionnel, comme ceci:

jmp début + (condition) * (fin - début)

Donc, après la condition de la boucle, qui change les drapeaux

dec cl

on transforme le drapeau en nombre (0 ou 1, dans ce cas)

setz reg16

on multiplie par la distance entre début et fin

mov eax, fin - début
mul reg16

ou, de manière moins répandue, uniquement sur AH

aad fin - début

on ajoute l'adresse de début

add eax, début

maintenant, on peut sauter inconditionnellement

jmp eax

On obtient une boucle standard mais avec un seul saut pour continuer ou sortir, et on doit fouiller dans le code pour savoir à l'avance le point de sortie. Dissimuler l'information cruciale 'fin - début' rendra les choses encore plus difficiles, particulièrement si la sortie est loin du bloc de la boucle.

une aiguille dans une botte de foin

Une autre façon est d'ajouter plusieurs sauts conditionnels factices. On les rendra, de même que le vrai saut de sortie, plus compliqués (par exemple, comparer à une valeur genre 05fb4e3 plutôt que 0, avec le compteur caché quelque part), on les fera sauter vers du code en cours de décryptage (pour éviter les points d'arrêt logiciels), on en mettra plus de 4 (pour être à court de points d'arrêt matériels), et on obtient ainsi une boucle dont on ne peut sortir facilement, à part devoir vérifier à chaque itération chacun de ces sauts conditionnels.
J'ai fait un exemple simple, où 4 registres sont influencés par le compteur (laissé volontairement évident dans ce cas), et comparés à des valeurs bizarres, et qui sauteront vers des adresses différentes:

cmp ax,0cafb
je 00400130
...
cmp bx,0bf21
je 0040012f
...
cmp dx,0c0d1
je 0040012e
...
cmp si,0bab0
je 00400131

Bien sûr, cet exemple est simplifié. Ajoutez du code pourri et aléatoire, et vous aurez ce que font certains packeurs.

une boucle avec SEH

Peter Ferrie a écrit une forme originale de boucle:

push 3
pop ecx
call l1
pop eax
pop eax
pop esp
pop ecx
l1:
dec ecx
push ecx
setne cl
xor eax, eax
mov dword ptr fs:[eax], esp
ror cl, 01
into

Dans ce cas, le compteur est décrémenté via

dec ecx

ce qui modifie ZF.

le drapeau ZF est copié vers OF par la combinaison de

setne cl ; cl = ZF ? 0 : 1
ror cl, 01 ; cl = ZF ? 0 (OF cleared) : 80 (OF set)

et le saut conditionnel caché est

CE into

qui déclenche l'interruption 4 si OF est défini, et rien sinon.

En résumé, cette boucle défini un gestionnaire d'exceptions, puis, en fonction de ZF puis OF, déclenche une exception par Int4 (et boucle) ou sort juste de la boucle.

Cependant, il faut faire attention aux détails :
le PUSH ecx sert à la fois pour sauver le compteur sur la pile, et définir la bonne structure pour le gestionnaire d'exception (même si le gestionnaire suivant sera faux, puisque ça sera le compteur et non le gestionnaire suivant dans la chaîne).

00000002 Pointer to next SEH record
004000F8 SE handler

De même, pour restaurer ESP à chaque itération, au lieu d'utiliser 4 octets:

8b642408 mov esp,[esp+8]

c'est implémenté via 2 pop inutiles et un vrai, ce qui fait 3 octets

58 pop eax
58 pop eax
5c pop esp

Voici donc 3 exemples de boucles cachées, dont les 2 premiers sont utilisés dans des packeurs courants (Waledac, PESpin).

Mise à jour:

cacher le compteur et la sortie

une autre idée, suggérée par Baboon, est de remplacer l'incrément de compteur par quelque chose qui a l'air plus aléatoire, comme un LFSR (registre à décalage à rétroaction linéaire), pour empêcher de deviner facilement le nombre d'itération requis, et en même temps, de modifier l'adresse de sortie de la boucle à chaque itération, pour qu'elle ne soit correcte qu'à la dernière :

lfsr32 edx, 0d0000001h
xor dword [loop_exit], edx ; l'adresse de sortie est modifiée aveuglément

lfsr16 cx, 0b400h
cmp cx, 0eaa2h ; cela sera vrai à la 35ème itération
jnz loop_start

jmp [loop_exit] ; on saute aveuglément à l'adresse de sortie

Ici, les deux lfsr sont indépendants. Ça serait plus compliqué si l'adresse de sortie dépendait aussi du lfsr du compteur.

Source et binaire

Notez que vous devez modifier la dernière variable loop_exit manuellement, car YASM n'accepte pas les opérations complexes telles que :

loop_exit dd loop_end ^ Key

You're so fine, lose my mind, and the world seems to...

2010-02-06T16:19:00.002Z

I moved non-technical blog entries here to keep this blog coherent.

J'ai mis tous les posts non techniques ici pour que ce blog reste cohérent.

Et puis celles qu'on doit pas...

2010-02-03T21:08:00.015Z

Undocumented opcodes and behaviors

Ever seen this before?

00400181 0F1F ??? ; Unknown command

As my opcode file is now close to completion, I made a working test executable with undocumented or uncommon opcodes, that you could use to test your own emulator or disassembler.

Note that if you use an older tool, opcodes might not be disassembled at all. If you're using Ollydbg (1.1), get a copy of BeatriX' FullDisasm to add support for the latest opcodes.
Let's start:

Setalc (or salc), a.k.a Set al on carry, is an originally undocumented opcode that sets AL to 00 or FF depending on CF state:

clc
salc
cmp al, 0
jnz bad

stc
salc
cmp al, 0ffh
jnz bad

While BSWAP has an expected behavior on 32bits (turns a value of 12345678 into 78563412), it's undefined on 16bits and yet commonly used: It swaps the register contents with a null word, so it just resets it.

mov eax, 12345678
bswap ax
cmp eax, 12340000
jnz bad

AAD and AAM don't have officially an operand, but it's just that they had a default operand of Ah, as they were used for BCD arithmetic operations.
Their behavior with a different base is unofficially defined, so they can be used for breaking 'standard' emulators:
AAD X sets AH to 0, and AL to AH * X + AL
AAM X sets AH to AL / X, and AL to AL % X

mov ax, 0325h
aad 7
cmp ax, 003Ah
jnz bad

aam 3
cmp ax, 1301h
jnz bad

This makes AAD the first add and multiply opcode on Intel CPU, on 8 bits only.

I explored SMSW behavior in detail already: on 32 bits, it's supposedly not defined, but it actually just copies CR0 value, which is constant in the usual conditions:

smsw eax
cmp eax, 08001003bh
jnz bad

the FPU is full of undocumented aliases (check Sandpile for a complete list), I just inserted them as junk, not for their actual operations:

ffreep st0
fstp1 st0
fcom2 st0
fcomp3 st0
fxch4 st0
fcomp5 st0
fxch7 st0
fstp8 st0
fstp9 st0
fneni
fndisi

Group 3 (f6-f7) Opcode 001 is actually an alias of 000 (Test).
This gives you a standard TEST opcode on memory reference that might not be disassembled, thus emulated correctly.
Ex:

F70878563412 test dword ptr [eax], 12345678h

OllyDbg 1.1 says

00400155 F7 ??? ; Unknown command

Similarly, SAL (Shift Arithmetic Left) is functionally identical to SHL. Thus it's commonly assembled as SHL directly, and some disassemblers/emulators might not support it, even though it's a standard SHL.

NOP is not just 090h anymore. It has taken different forms in modern CPUs, for example, to give hints about the execution. It even has an operand, but you can't trigger an exception with it, hopefully.
So, it still basically does nothing, provided you disassemble it correctly. See for yourself:

0F1F00 nop dword ptr [eax]
0F1984C000000080 hint_nop dword ptr [eax+eax*8-80000000h]

IceBP, aka Int1, is a very famous undocumented opcode that triggers a Single Step exception. Int 1 (CD01) itself would trigger an access violation exception.

F1 IceBP
...
cmp dword ptr [edx] , 80000004h

On branching instructions (Call/Retn/Jmp/Jxx/Loop), the 66 Operand size prefix makes the opcode work only on the lower word of EIP.
Thus a familiar-looking

50 push eax
66c3 retn
...
cmp dword ptr [edx] , C0000005h

will actually jump to AX, which will trigger an Access violation exception - it's not your standard RET here!

CMPS* and MOVS* are the only 2 opcodes that use 2 memory reference operands. However, they're often shown without in their compact form, without their operands at all. If you use them with a segment prefix such as 64 FS, the source is taking the prefix.
Such a hidden FS:[ESI] => [EDI] could be used to set a SEH.
(For extra SEH tricks, check roy g biv's Subtle SEH)

LOOP is influenced by the Operand size prefix, but also the Address size prefix, in which case only CX is checked (same for Jecxz, but in this case it's written differently, jcxz). Thus with the right value ECX, the 'same' loop might end up in different places:

mov ecx, 0ffff0001h
67
loop bad
loop good

Source and binary

[...]

Opcodes et comportements non documentés

Ça vous dit quelque chose ?

00400181 0F1F ??? ; Unknown command

Alors que mon fichier d'opcodes est bientôt complet, j'ai écrit un exécutable de test qui marche correctement et qui contient des opcodes rares ou non documentés, que vous pourrez utiliser pour tester votre désassembleur ou émulateur perso.

Il faut noter que si vous utilisez un outil un peu ancien, les opcodes ne seront peut-être pas gérés du tout. Si vous utilisez Ollydbg (1.1), installez FullDisasm de BeatriX pour le mettre à jour.

Commençons:
Setalc (or salc), autrement dit Set al on carry, est un opcode non documenté au début, qui met AL à 00 ou FF en fonction de l'état de CF :

clc
salc
cmp al, 0
jnz bad

stc
salc
cmp al, 0ffh
jnz bad

Alors que BSWAP a un comportement prévisible sur 32 bits (change 12345678 en 78563412), il est non défini sur 16 bits, et pourtant couramment utilisé : il échange le contenu du registre avec un mot nul, donc il le remet à zéro.

mov eax, 12345678
bswap ax
cmp eax, 12340000
jnz bad

AAD et AAM n'ont officellement pas d'opérande, mais c'est en fait une opérande par défaut à Ah, puisqu'ils sont utilisés pour les opérations arithmétiques avec des nombres BCD (1020 est stocké sous la forme 1020h, pas 0x3fc).
Leur comportement avec une base autre que décimale est défini officieusement, donc ils peuvent être utilisés pour casser des émulateurs trop standard:
AAD X met AH à 0, et AL à AH * X + AL
AAM X met AH à AL / X, et AL à AL % X

mov ax, 0325h
aad 7
cmp ax, 003Ah
jnz bad

aam 3
cmp ax, 1301h
jnz bad

Ce qui fait de AAD le premier opcode d'addition et multiplication combinées sur processeur Intel, mais en 8 bits uniquement.

J'ai déjà exploré en détail le comportement de SMSW : sur 32 bits, il n'est soit-disant pas défini, mais en fait il copie juste la valeur de CR0, qui est constante dans les conditions normales :

smsw eax
cmp eax, 08001003bh
jnz bad

La FPU est remplie d'alias non documentés (allez voir Sandpile pour une liste complète), j'en ai juste inséré pour remplir, pas pour leurs opérations effectives:

ffreep st0
fstp1 st0
fcom2 st0
fcomp3 st0
fxch4 st0
fcomp5 st0
fxch7 st0
fstp8 st0
fstp9 st0
fneni
fndisi

dans le groupe 3 (f6-f7), l'opcode 001 est en fait un synonyme du 000 (Test).
Cela vous donne un opcode TEST standard qui pourrait ne pas être désassemblé correctement, donc émulé correctement.
Ex:

F70878563412 test dword ptr [eax], 12345678h

OllyDbg 1.1 donne

00400155 F7 ??? ; Unknown command

De manière similaire, SAL (Shift Arithmetic Left) est fonctionnellement identique à SHL. Il est en général assemblé en SHL, et certains désassembleurs ou émulateurs peuvent ne pas le gérer, alors qu'il n'est qu'un SHL standard.

NOP n'est plus uniquement 90h. Il a plusieurs formes sur les processeurs modernes, par exemple, pour donner des indications sur l'exécution. Il a même une opérande, mais heureusement on ne peut pas déclencher d'exception avec.
Donc, il ne fait toujours rien, mais encore faut-il le désassembler correctement. Voyez vous-même:

0F1F00 nop dword ptr [eax]
0F1984C000000080 hint_nop dword ptr [eax+eax*8-80000000h]

IceBP, parfois appelé Int1, est un opcode non documenté très connu qui déclenche une exception Single Step. Le vrai Int 1 (CD01) déclenche une exception de type access violation.

F1 IceBP
...
cmp dword ptr [edx] , 80000004h

Devant les instructions de saut (Call/Retn/Jmp/Jxx/Loop), le préfixe de taille d'opérande 66 fait sauter sur le mot faible de EIP.
Donc un innocent

50 push eax
66c3 retn
...
cmp dword ptr [edx] , C0000005h

va en fait sauter vers AX, ce qui déclenchera une exception Access violation - ce n'est pas votre RET habituel!

CMPS* et MOVS* sont les 2 opcodes qui utilisent 2 opérandes de références mémoires. Ils sont souvent affichés sous leur forme compacte, sans leurs opérandes. Si on les utilise avec un préfixe de segment tel que 64 FS, la source est influencée par ce préfixe.
Ce qui nous donne un FS:[ESI] => [EDI] caché, qui peut être utiliser pour définir un SEH.
(Pour plus d'astuces de SEH, voir Subtle SEH de roy g biv).

LOOP est donc influencée par le préfixe de taille d'opérande, mais aussi par celui de taille d'adresse, auquel cas seul CX est contrôlé (de même pour Jecxz, mais dans ce cas, il est écrit différemment, jcxz). Donc, avec une bonne valeur dans ECX, la 'même' LOOP peut donner des résultats différents :

mov ecx, 0ffff0001h
67
loop bad
loop good

Source et Binaires

It's just a flesh wound

2010-01-29T23:26:00.002Z

Section-less PE file (updated)
You may not expect a PE to be valid without all its standard structure:

Dos Header, Nt Headers, File Header, Optional Header, Data Directories, Section Headers.

TinyPE already proved that the Data directories are not compulsory, but also sections are not always required.

If the alignment is smaller than 1000h (800h or less), and the number of section is null, the loader loads the file directly as-is (RVA = Offset). And since the number of section is null, you don't need a section table altogether.

To use imports, you usually need just to define the Imports directory (VA only). the IAT directory is not required.
However, in this special section-less case, the IAT is required to set correct priorities on the right memory range, so the IAT size is required too.

To sum up:

NumberOfSection = 0
Alignment < 1000h
RVA = Offset
IAT RVA and SIZE are compulsory (if you use imports)

It makes a working PE that many tools will just handle as corrupted.

If you don't use imports, you can drop the whole set of data directories altogether. In this case, the header will be REALLY empty.

Binary Source

Update: SizeOfOptionalHeader has a confusing name. It's not the actual size of the optional header, it's just the delta between the start of the optional header and the section table, as it's used to find the locate it:

SizeOfOptionalHeader = @SectionTable - @Optional_Header

If you move the section table further in the file (even - for example - after the first section), SizeOfOptionalHeader will be huge, much bigger than the whole header itself (as in, SizeOfHeaders).
In this example, on the contrary, there is no (need of) section table, thus SizeOfOptionalHeader can be zero, or anything (even a value bigger than the filesize). But if it's negative, the file won't work.
This confirms that you can't put the section table before the Optional_Header, between the DOS_Header and the NT_Headers.

Yet another unexpectedly weird element in the PE headers...

[...]

Fichier PE sans section (mis à jour)
A priori, on n'imaginerait pas qu'un PE soit valide sans toutes ses structures standards :

Dos Header, Nt Headers, File Header, Optional Header, Data Directories, Section Headers.

TinyPE a déjà prouvé que les Data directories ne sont pas indispensables, mais les sections elles aussi ne sont pas toujours requises.

Si l'alignement est plus petit que 1000h (800h ou moins), et que le nombre de sections est nul, le loader charge le fichier directement tel quel (RVA = Offset). Et puisque le nombre de sections est nul, plus besoin de table de sections.

Pour utiliser les imports, on a d'habitude juste besoin de définir le Imports directory (juste son adresse virtuelle). La table d'imports (IAT directory) n'est pas obligatoire.
Cependant, dans ce cas particulier, la table d'imports est requise pour définir les priorités correctes sur le bon espace mémoire, donc la taille de la table est requise aussi.

Pour résumer :

NumberOfSection = 0
Alignement < 1000h
RVA = Offset
IAT RVA et SIZE obligatoires (si vous utilisez les imports)

Cela donne un PE qui marche, que beaucoup d'outils estimeront corrompu.

Si vous n'utilisez pas les imports, vous pouvez abandonner tous les data directories. Dans ce cas, l'en-tête sera VRAIMENT vide.

Binaire Source

Mise à jour : SizeOfOptionalHeader a un nom qui peut prêter à confusion. Ce n'est en fait pas la taille du Optional_Header, c'est juste la différence entre le début du Optional_Header et de la table des sections, puisqu'il est utilisé pour la localiser :

SizeOfOptionalHeader = @SectionTable - @Optional_Header

Si on met la table plus loin dans le fichier (même - par exemple - après la première section), SizeOfOptionalHeader sera énorme, bien plus que l'en-tête tout entier (tel que défini dans SizeOfHeaders).
Dans cet exemple, au contraire, on n'a pas (besoin) de table de sections, donc SizeOfOptionalHeader peut être nul, ou n'importe quoi (même une valeur plus grande que la taille du fichier). Mais si il est négatif, le fichier ne marchera pas.
Cela concorde avec le fait qu'on ne puisse pas mettre la table avant l'Optional_Header, entre le DOS_Header et les NT_Headers.

Encore un élément bien flou dans l'en-tête des PE.

din nebunia de culori, vreau sa aleg si alte flori

2010-01-28T22:56:00.003Z

a PE Headers graph
If you're looking for a good representation of the PE format, OpenRCE's poster from Ero Carrera is the standard.
I gave it a try making my own representation, and started a multi-page one, lighter to open, easier to print (A4-formatted), where elements are shown differently depending on their importance.

The first page is done: the Headers (without the directories).

the source file, an Inkscape SVG, is available under the Creative Commons Attribution licence.

PE Format 1 : Headers (PDF)

[...]
un graphe des en-têtes du PE
Si vous cherchez une bonne représentation du format PE, le poster d'OpenRCE par Ero Carrera est le standard.
J'ai essayé de faire ma propre représentation, et j'en ai commencé une, multi-pages, plus légère, plus facile à imprimer (format A4), et les éléments sont représentés en fonction de leur importance.

La première page est finie : les en-têtes (sans les directories).

Le fichier source, un SVG Inkscape, est fourni sous la license Creative Commons Attribution.

PE Format 1 : En-têtes (PDF)

On aura plus de pain sur la planche, parce que la planche aura brûlé

2010-01-22T23:39:00.004Z

messing with sections physical offset
With a high alignment (>= 1000h), nothing prevents 2 sections to come from the same physical data.
Thus, if 2 sections with different virtual addresses have the same PointerToRawData and SizeOfRawData, their content will be initially the same. Relocations and imports will be applied afterward though.

SECTION_0:
.VirtualSize dd Section0Size
.VirtualAddress dd Section0Start - IMAGEBASE
.SizeOfRawData dd Section0Size
.PointerToRawData dd Section0Start - IMAGEBASE
...
SECTION_1:
.VirtualSize dd Section0Size *same
.VirtualAddress dd Section1Start - IMAGEBASE
.SizeOfRawData dd Section0Size *same
.PointerToRawData dd Section0Start - IMAGEBASE *same

A section can be virtually non-empty and physically empty. In this case, it will just be full of zero. It's a common way to create space for uninitialized data, or in packers, to create memory space for the original sections without the need to allocate memory yourself.

You'd expect a physically empty section to have an empty physical size.
But if only the PointerToRawData is null (and not SizeOfRawData), the section will still be seen as physically empty, thus full of zero.
However, if PointerToRawData is smaller than 0200h (this value is independent of the Section or File Alignment), it will be rounded to 0, without the 'empty zero-ed effect'.
So, with a Section with a PointerToRawData between 1 and 1ffh, and a physical size equal to the PE, you can map the whole PE in a duplicate way.

whole_pe_offset equ 1; < 200h otherwise not rounded to 0
SECTION_1:
.VirtualSize dd pe_size
.VirtualAddress dd pe_size
.SizeOfRawData dd pe_size - whole_pe_offset
.PointerToRawData dd whole_pe_offset

In the 2 files, I made the code jump to its copy. Don't set your breakpoints in the wrong parts that are not executed!

Thanks to Costin Ionescu.

Sources and binaries

[...]
faire des misères physiques aux sections
Dans le cas d'un alignement élevé (>= 1000h), rien n'empêche 2 sections d'être basées sur les mêmes données physiques.
Donc, si 2 sections aux adresses virtuelles différentes ont les mêmes PointerToRawData et SizeOfRawData, leur contenu sera initialement le même. Les relocations et les imports seront pris en compte ensuite, cependant.

SECTION_0:
.VirtualSize dd Section0Size
.VirtualAddress dd Section0Start - IMAGEBASE
.SizeOfRawData dd Section0Size
.PointerToRawData dd Section0Start - IMAGEBASE
...
SECTION_1:
.VirtualSize dd Section0Size *même valeur
.VirtualAddress dd Section1Start - IMAGEBASE
.SizeOfRawData dd Section0Size *même valeur
.PointerToRawData dd Section0Start - IMAGEBASE *même valeur

Une section peut être virtuellement non vide, et physiquement vide. Dans ce cas, elle sera juste remplie de zéros. C'est une méthode standard pour créer de l'espace pour les données non initialisées, ou dans les packeurs, pour créer de l'espace mémoire à la place des sections originales, sans avoir à initialiser de la mémoire soi-même.

On s'attend à ce qu'une section vide physiquement ait une taille physique vide.
Mais si seul le PointerToRawData est nul (et non la SizeOfRawData), la section sera toujours vue comme physiquement vide, donc pleine de zéros.
Cependant, si PointerToRawData est plus petit que 0200h (cette valeur est indépendante des alignements de fichier ou de section), il sera arrondit à zéro, sans l'effet 'rempli de zéro'.
Donc, avec une section avec un PointerToRawData entre 1 et 1ffh, et une taille physique égale au PE, on peut mapper le PE entier dans une copie.

whole_pe_offset equ 1; < 200h otherwise not rounded to 0
SECTION_1:
.VirtualSize dd pe_size
.VirtualAddress dd pe_size
.SizeOfRawData dd pe_size - whole_pe_offset
.PointerToRawData dd whole_pe_offset

Dans les 2 fichiers, j'ai fait sauter le code vers sa copie. Ne mettez pas les points d'arrêts sur la partie jamais exécutée!

Remerciements: Costin Ionescu.

Sources et binaires

Policeman got no gun, U don't have 2 run

2010-01-21T22:34:00.006Z

SMSW based anti-emulator/stepping
SMSW (store machine status word) stores the 16 lowest bits of cr0 in the operand register. In the case of SMSW with a reg32, the highest word is not defined - it seems to be always 8001h, though.

It makes it a weird reg32 opcode (why accepting a 32b operand if you undefine the highest bits and if there is a 16b operand counterpart ?) but it definitely changes the highest word (some disassembler show invariably a word operand, which is wrong).

While 'mov eax, cr0' is a priviledged instruction, SMSW isn't.

In cr0, bits 1 and 3 are called MP (Monitor Coprocessor) and TS (Task switched). Their state depends on FPU operations. This leads to several anti-* similar to the GS one.

They are usually set. This is no anti-debugger, but it might just be used as an anti-emulator.

smsw eax
cmp ax, 03bh
jnz bad

Execute any FPU opcode (even FNOP), then both bits will be cleared. Similarly to the GS trick, if you step, both bits will be in their usual set. To bypass it easily, you have to start running BEFORE the fpu opcode. Starting execution from the fpu opcode will give MP and TS their wrong state.

fnop
smsw eax
cmp ax, 031h
jnz bad

But after the FPU opcode, the bits will eventually revert to their set state.
So a wrong emulation might be stuck in an infinite loop.

_1:
smsw eax
cmp ax, 031h
jz _1

Another version of that test is to wait for one bit to be set and then check the other is set too.
the Intel docs says:

The SMSW instruction is only useful in operating-system software; however, it is not a privileged instruction and can be used in application programs.

Now, you know it's also useful as an anti-*.

In some case (1 out of 20?), execution fails. Likely, the FPU opcode might trigger those bits too late. So double checking will fix this race condition.

Thanks to Peter Ferrie.

Source and binary
[...]
anti-émulateur/pas à pas basé sur SMSW
SMSW (store machine status word) met les 16 bits de poids faibles de cr0 dans le registre de l'opérande. Dans le cas de SMSW avec un reg32, le mot de poid fort n'est pas défini - il semble cependant être toujours 8001h.

Ca donne un opcode bizarre pour reg32 (pourquoi accepter une opérande de 32b si le mot de poids fort n'est pas défini et qu'il existe une version sur 16b ?) mais qui modifie pour sûr le mot de poid fort (certains disassembleurs montrent toujours une opérande sur 16b, ce qui est faux).

Alors que 'mov eax, cr0' est une instruction privilégiée, SMSW ne l'est pas.

Dans cr0, les bits 1 et 3 sont appelés MP (Monitor Coprocessor) et TS (Task switched). Leur état dépend des opérations du FPU. Cela donne quelques anti-* similaires à celui de GS.

Ces bits sont à 1 d'habitude. Ce n'est pas un anti-débogueur, mais ça peut être utilisé simplement comme anti-émulateur.

smsw eax
cmp ax, 03bh
jnz bad

Executez n'importe quel opcode FPU (même FNOP), et les 2 bits seront à zéro. De même que pour GS, si on avance en pas à pas, les deux bits seront remis à leur valeur initiale. Pour le passer facilement, il faut commencer l'exécution AVANT l'opcode FPU. Si on démarre à partir de l'opcode FPU, MP et TS auront leur mauvaise valeur.

fnop
smsw eax
cmp ax, 031h
jnz bad

Mais après l'opcode FPU, les bits vont finir par revenir à leur état initial. Donc une mauvaise émulation pourrait être bloquée dans une boucle infinie.

_1:
smsw eax
cmp ax, 031h
jz _1

Une autre version de ce test revient à attendre qu'un des 2 bits soit redéfini, et ensuite vérifier que le 2ème l'est aussi.

La documentation Intel dit :

L'instruction SMSW n'est utile que pour le système d'exploitation; quoi qu'il en soit, elle n'est pas privilégiée et peut être utilisé dans des applications.

Maintenant, vous savez que c'est aussi utile comme anti-*.

De temps en temps (1 sur 20?), l'exécution échoue: l'opcode FPU change probablement les bits trop tard, auquel cas faire un 2eme test peut s'avérer nécessaire.

Merci à Peter Ferrie.

Source et binaire

The hen never laid and the corn never growed

2010-01-20T20:09:00.003Z

anti-* with the GS register
On thread switch, the GS register value is not restored (32 bits only).
It's a simple statement that leads to anti-* (debugger/tracing/emulator) that defy common sense. (one of my favorite anti-*, since it doesn't call any API and requires to think out of the box).

When stepping, threads are switched, so your debugger might lose the right value.
Try it yourself:

open debugger
set GS to a non-zero value
step, even once
GS might be zero already!

so it's makes an easy anti-stepping:

set GS to a non-zero value
debugger detected if GS is 0

On the other hand, after some time of normal execution, thread switch will happen, and GS will be reset.

set GS to a non-zero value
loop as long as GS is not zero

If an emulator is not resetting GS after some time, execution will be stuck in an infinite loop.

Last, thread switching requires will take some time before it occurs. So, such a 'loop if not zero' used with a timing method can be used to detect a debugging session (with an anti-timer) or an emulator.

check current time
wait for thread switch with the GS loop trick
check current time again
compare both values, shouldn't be too low

There is no 'mov gs, immediate_value' opcode, the only opcodes to modify GS are:

mov gs, reg16
pop gs

Any code using GS should be taken as suspicious, as it's only used in recent binaries for anti-* purposes, in my opinion.

Source and binaries

[...]

anti-* avec le registre GS
Au moment du changement de thread, la valeur du registre GS n'est pas restaurée (en 32 bits uniquement).
Cette simple phrase permet des anti-* (débogueur/analyse/émulateur) qui défient le bon sens. (c'est un de mes anti-* favoris, car il ne nécessite aucun appel à API et demande de sortir du cadre).

Quand on analyse pas à pas, les threads changent, donc votre débogueur peut perdre la bonne valeur.
Essayez vous-même :

ouvrez le débogueur
donnez à GS une valeur non nulle
faites un juste un pas
il est possible que GS soit déjà nul !

Donc ça fait un anti pas à pas facile:

mettre à GS une valeur non nulle
vérifier que GS est non nul. Sinon, débogueur détecté !

D'autre part, après un certain temps d'exécution normale, le changement de thread va se produire, et GS deviendra nul.
Ce qui nous donne l'anti-émulation suivant:

mettre à GS une valeur non nulle
attendre que GS ne soit pas nul

Si l'émulateur ne remet pas à zero GS au bout d'un certain temps, l'exécution sera bloquée dans une boucle infinie.

Enfin, le changement de thread met un certain temps à se produire. Donc une telle 'attente que GS ne soit pas nul' utilisé avec une méthode de chronométrage peut être utilisée pour trouver un débogueur (avec un anti-timer) ou un émulateur.

regarder l'heure
attendre le changement de thread via la boucle d'attente de GS
regarder l'heure à nouveau
comparer les deux valeurs, elles ne devraient pas être trop proche

Il n'y a pas d'opcode 'mov gs, immediate_value', les seuls opcodes pour modifier GS sont :

mov gs, reg16
pop gs

Le moindre code utilisant GS devrait vous alerter, car dans des binaires récents, il n'est utilisé que pour les anti-*, à mon avis.

Sources et binaires

You can rock this land, baby

2010-01-19T21:37:00.007Z

the other subsystems
In your Windows directory, most drivers have many sections, including the PAGE and INIT ones, where the EP is. All this is pretty scary, while, in the end, only a very small amount of information (compared to a GUI PE) is necessary to create a working driver:
as expected, the Subsystem has to be set to NATIVE, then relocations are compulsory since you can't tell in advance where the driver will be loaded, and a correct PE checksum is required to have the driver running.
And that's all!

at IMAGE_OPTIONAL_HEADER32.Subsystem, dw IMAGE_SUBSYSTEM_NATIVE
...
EntryPoint:
reloc1_1:
push helloworld ; PCHAR Format
call DbgPrint
add esp, 4 ; correct the stack

mov eax, STATUS_DEVICE_CONFIGURATION_ERROR
retn 8

reloc2_2:
;%IMPORT ntoskrnl.exe!DbgPrint

Similarly, usual console binaries import Msvcrt to deal with the console, which makes them bloated and complex. While in the end, you don't need anything besides changing the subsystem. You can still call GUI APIs the usual way, and writing to console output is just a matter of getting the OUTPUT handle and writing to it.

at IMAGE_OPTIONAL_HEADER32.Subsystem, dw IMAGE_SUBSYSTEM_WINDOWS_CUI
...
EntryPoint:
push STD_OUTPUT_HANDLE ; DWORD nStdHandle
call GetStdHandle
mov [hConsoleOutput], eax

push 0 ; LPVOID lpReserved
push lpNumbersOfCharsWritten ; LPWORD lpNumbersOfCharsWritten
push HELLOWORLD_LEN ; DWORD nNumbersOfCharsToWrite
push helloworld ; VOID *lpBuffer
push dword [hConsoleOutput] ; HANDLE hConsoleOutput
call WriteConsoleA

Sources and binaries

[...]
les autres subsystems
Dans votre répertoire Windows, la plupart des drivers ont beaucoup de sections, y compris les sections PAGE and INIT, où se trouve l'EP. Tout cela peut sembler compliquè, alors qu'au final, peu de changements sont nécessaires (par rapport à un PE GUI) pour créer un driver fonctionnel :
comme attendu, le Subsystem doit être NATIVE, ensuite les relocations sont obligatoires puisqu'on ne sait pas à l'avance à quelle adresse le driver sera chargé, et une somme de contrôle correcte est requise pour charger le driver.
Et c'est tout!

at IMAGE_OPTIONAL_HEADER32.Subsystem, dw IMAGE_SUBSYSTEM_NATIVE
...
EntryPoint:
reloc1_1:
push helloworld ; PCHAR Format
call DbgPrint
add esp, 4 ; corriger la pile
mov eax, STATUS_DEVICE_CONFIGURATION_ERROR
retn 8

reloc2_2:
;%IMPORT ntoskrnl.exe!DbgPrint

De manière similaire, les binaires console habituels importent Msvcrt pour gérer la console, ce qui les rend gros et complexes. Mais au final, on n'a besoin de rien hormis changer le Subsystem. On peut toujours appeler les APIs graphiques comme d'habitude, et écrire vers la console n'est qu'une affaire d'obtenir le handle OUTPUT et d'y écrire.

at IMAGE_OPTIONAL_HEADER32.Subsystem, dw IMAGE_SUBSYSTEM_WINDOWS_CUI
...
EntryPoint:
push STD_OUTPUT_HANDLE ; DWORD nStdHandle
call GetStdHandle
mov [hConsoleOutput], eax

push 0 ; LPVOID lpReserved
push lpNumbersOfCharsWritten ; LPWORD lpNumbersOfCharsWritten
push HELLOWORLD_LEN ; DWORD nNumbersOfCharsToWrite
push helloworld ; VOID *lpBuffer
push dword [hConsoleOutput] ; HANDLE hConsoleOutput
call WriteConsoleA

Sources et binaires

Sail to the edge and I'd be there

2010-01-18T22:09:00.011Z

Messing with the TLS
TLS, aka Thread Local Storage, is a way to execute some code before the EntryPoint or after ExitThread/ExitProcess.
the 10th Data Directory points to a structure, and one of the elements (VA, not RVA) points to null-terminated list of callbacks, which will be called one after the other.
This list is stored as VAs (it includes the ImageBase then), which makes it quite uncommon among the PE structures.

IMAGE_TLS_DIRECTORY32:
...
AddressOfCallBacks dd Callbacks ; VA
...
Callbacks:
dd TLS
dd 0 ; null-terminated list

The size of the Data Directory is not taken into account. Some tool may ignore wrongly the TLS if it's not defined, though.

Callbacks are executed on (before) thread start and on (after) thread exit. However, (credits goes to Peter Ferrie and Kris Kaspersky here), TLS callbacks execution won't happen if no dll importing kernel32 is imported itself. So, if kernel32.dll is the only 'official' import (it doesn't mean it's the only dll in the program space), the callbacks are not executed.

Nothing happens if there is no (valid) callbacks. It will trigger an exception but it's handled by the system so it doesn't trigger an visible error. After an exception or a null dword is found, the list is not parsed anymore. Tools building the list until a null dword is found can be fooled, which would create bogus entries.

The list is reloaded between each callback. Callback N might modify the list at position N+1 and that will be taken into account.
Similarly, if the EntryPoint code updates the callbacks' list, it will be taken into account during thread exit.
the 'no callback execution if only Kernel32 is imported' status is updated during the EntryPoint code too: if the EntryPoint code loads, say, user32, the callbacks list will be executed on thread exit. If, at this point, one of the callbacks frees user32, the next callback will still be executed.

Like EntryPoint values, the Callback address can point outside the PE, similar to my previous post (it's just a VA though, not an RVA), which can make the callbacks list difficult to analyze, but it's not a standard case - even among packers.

Consequences:
Because some debuggers automatically put a software breakpoint on the EntryPoint, and code at TLS is executed first, the TLS code can detect it (check if it's CC) and act accordingly.

the 'only kernel32' rule can be used as an anti-emulator.

Sometimes this rule seems wrong because a debugger plugin loaded another dll itself.

If a callback on loading calls ExitProcess, the other callbacks (and EP) are never executed. Which makes TLS callbacks another way to ignore the EP value altogether, like mentioned in my previous post.

Setting a TLS callback from the EntryPoint and exiting can be yet another way to 'Jump'. It's just so unnatural to expect code after the 'final' ExitProcess call. (there IS a life after death!). Same for setting a callback from a previous one, but the 'beyond final' effect is lost.

To break on TLS callbacks in OllyDbg, using OllyAdvanced is an easy solution. Otherwise, set the 'first pause' on 'System breakpoint'.

Files:
tls_standard just uses standard tls callbacks.
tls_fake fills the callbacks list with bogus entries:

Callbacks:
db 'lets fill the Callbacks...'

no_relocs_tls_loader uses a callback outside the pe

;%IMPORT no_relocs.dll!Export
...
Callbacks:
dd 330200h

tls_on_the_fly shows that modifying the callback list is taken into account

TLS0:
mov dword [Callbacks + 4], TLS
retn
TLS:
push MB_ICONINFORMATION ; UINT uType
push aTls1 ; LPCTSTR lpCaption
...

tls_no_user32 shows that just loading kernel32 doesn't enable the usual callbacks behavior, then loading user32 in the EP code re-enables it.

EntryPoint:
push aUser32 ; LPCTSTR lpFileName
call LoadLibraryA
...

Sources and binaries

[...]

Faire des misères au TLS
Le TLS, autrement dit le Thread Local Storage, permet d'exécuter du code avant l'EntryPoint ou après un appel à ExitThread/ExitProcess.
Le 10ème Data Directory pointe vers une structure, et un des éléments (VA, pas RVA) pointe vers une liste de callbacks terminée par zéro, qui seront
appelés l'un après l'autre.
Cette liste est stockée sous forme de VAs (ImageBase inclue, donc), ce qui est inhabituel dans les strucures du PE.

IMAGE_TLS_DIRECTORY32:
...
AddressOfCallBacks dd Callbacks ; VA
...
Callbacks:
dd TLS
dd 0 ; null-terminated list

La taille du Data Directory n'est pas prise en compte. Certains outils pourraient ignorer - à tort - le TLS si elle n'est pas définie.

Les callbacks sont exécutés à l'initialistation (avant) du thread start et après sa fin. Cependant, (l'honneur revient à Peter Ferrie et Kris Kaspersky, ici), l'exécution n'aura pas lieu si aucune DLL n'important kernel32 n'est elle-même importée. Donc, si kernel32.dll est le seul import 'officiel' (cela ne veut pas dire que ca soit la seule DLL dans l'espace mémoire), les callbacks ne sont pas exécutés.

Rien ne se passe si il n'y a pas de callbacks (valide). Ça va déclencher une exception, mais elle sera gérée par le système, donc pas d'erreur visible. Après une exception ou un zéro terminal, la liste n'est plus parcourue. Les outils construisant la liste jusqu'à un zéro terminal peuvent être induit en erreur, ce qui créeraient des entrées factices.

La liste est rechargée à chaque callback. le N-ème Callback N peut changer la liste à la position N+1, et cela sera pris en compte.
De manière similaire, si l'EntryPoint modifie la liste, cela sera pris en compte lors de la sortie du Thread.

Le statu de la règle 'pas d'exécution si seule Kernel32 est importée' est mis à jour lors du code de l'EntryPoint également : si l'EntryPoint charge - par exemple - user32, les callbacks seront exécutés lors de la sortie. Si, à ce moment-là, un des callbacks décharge User32, le callback suivant sera toujours exécuté.

A l'instart des EntryPoint, les callbacks peuvent être en dehors du PE, comme dans mon billet précédent (c'est une juste une VA, pas une RVA), ce qui peut rendre la liste des callbacks difficile à analyser, mais ce n'est pas un cas standard, même dans les packeurs.

Conséquences:
Puisque certains débogueurs (désinsectiseurs ? :) ) mettent un point d'arrêt logiciel sur l'EntryPoint, et que le code des callbacks est exécuté d'abord, le code du callback peut le détecter (vérifier si c'est CC), et agir en conséquence.

La règle 'seule Kernel32' peut-être utilisée comme un anti-émulateur.

Parfois cette règle semble fausse car un plugin du débogueur a lui-même chargé une DLL supplémentaire.

Si un callback appelle ExitProcess lors de l'initialisation, les callbacks suivent et l'EP ne seront jamais exécutés. Ce qui fait que le TLS est un moyen de plus d'ignorer l'EP, comme dans mon billet précédent.

Définir un callback de l'EntryPoint et terminer est un moyen de plus de 'sauter'. Mais il est tellement inhabituel d'attendre du code apres l'appel 'final' à Exitprocess. (Il y A donc une vie après la mort !). De même de définir un callback à la suite d'un autre, mais l'effet 'après la mort' est perdu.

Pour s'arrêter sur les callbacks dans OllyDbg, utiliser OllyAdvanced est une solution simple. Sinon, mettre 'first pause' sur 'System breakpoint'.

Fichiers:
tls_standard utilise le TLS standard.
tls_fake remplit la liste d'entrées factices :

Callbacks:
db 'lets fill the Callbacks...'

no_relocs_tls_loader utilise un callback hors du PE :

;%IMPORT no_relocs.dll!Export
...
Callbacks:
dd 330200h

tls_on_the_fly montre les que les changements apportés à la liste sont pris en compte à la volée :

TLS0:
mov dword [Callbacks + 4], TLS
retn
TLS:
push MB_ICONINFORMATION ; UINT uType
push aTls1 ; LPCTSTR lpCaption
...

tls_no_user32 montre qu'importer uniquement kernel32 n'active pas le comportement habituel, et que charger user32 dans l'EP le rétablit.

EntryPoint:
push aUser32 ; LPCTSTR lpFileName
call LoadLibraryA
...

Sources et binaires

If you got the money honey, we got your disease

2010-01-17T19:14:00.019Z

Messing with the EntryPoint
In most files, the EP is in the first section. In many packers or file infecters, it will be in another section. It's actually common in the header itself (Upack, FSG), and sometimes (like - among others - in collapsed.asm), it's at RVA 0, in which case the MZ signature is just interpreted as dec ebp, pop edx, which is benign. Many packers just put some trampoline code at RVA 0, then the rest of the code further.
So, usually:

Section0 VA <= EntryPoint <= Section0 VA + Physical Size

and to a general extend:

0 <= EntryPoint <= SizeOfImage

But no check is actually done on the EntryPoint value!

If there is no need to execute any code, no problem will occur:
some PE files are just used as resource containers, for example storing images and icons used in several products or softwares. In this case, there is no code whatsoever, thus no expected execution. The only form of interaction with this file is via the resource APIs.

In a DLL, the code at the EntryPoint (DllMain) is executed on loading and unloading, whether it's loaded normally or via LoadLibraryA/FreeLibrary (LoadLibraryEx is an exception, you can specify it NOT to run DllMain, aka the code at the EP of the DLL).
So, if you always load a DLL with LoadLibraryEx and the right parameters, the EP value will not be used.

In both cases, the EP value could be bogus.

Moreover, if the EP is actually executed (which just means, code at EP + IMAGEBASE is executed) and no problem happens, it's still ok!

Example:

Open Notepad in a debugger, check ExitProcess address: 7C81CB12 ExitProcess 8BFF MOV EDI,EDI)
Set the EP to that address (substract IMAGEBASE): 7c81cv12 - 1000000 = 7B81CB12)
Run...execution starts directly at ExitProcess...

Even better, if you force your code to be at some address, via, for example, a DLL without relocations, and an executable that imports this DLL, with the right EP value, in the expected DLL code, you can get a working PE , with a huge or a negative EntryPoint...

In my example, no_relocs.dll:

IMAGEBASE 330000h, Relocation 0
Section 0 VA 200
push MB_ICONINFORMATION ; UINT uType
push tada ; LPCTSTR lpCaption
...

And the loader no_relocs_loader.exe:

EntryPoint: FFF30200
ImageBase: 00400000
=> Execution at 00330200 = Start of Section 0 of no_relocs.dll

So this file, empty with a negative EntryPoint, just runs fine.

In conclusion, it's difficult to decide in advance if an EntryPoint value is valid or not. It's just possible to say if it's standard or not.

Original idea from Costin Ionescu.

Binaries Sources: dll loader

[...]

Faire des misères à l'EntryPoint
Dans la plupart des fichier, l'EP est dans la première section. Dans beaucoup de packeurs ou d'infecteurs, il sera dans une autre section. C'est aussi courant de le trouver dans l'en-tête lui-même (Upack, FSG), et parfois (comme - entre autres - dans collapsed.asm), il est à la RVA 0, auquel cas la signature MZ est juste interprétée comme dec ebp, pop edx, ce qui est bénin. Beaucoup de packers mettent just du code 'trampoline' à RVA 0, et le reste du code est ailleurs.
Donc, d'habitude :

Section0 VA <= EntryPoint <= Section0 VA + Physical Size

et de manière générale :

0 <= EntryPoint <= SizeOfImage

Mais en fait, il n'y a aucune vérification sur la valeur de l'EntryPoint !

Si il n'y a pas besoin d'exécuter du code, aucune erreur ne se produira :
Certains PE sont juste utilisés comme conteneurs de resources, par exemple pour stocker les images et les icones utilisées dans plusieurs produits ou programmes. Dans ce cas, il n'y a pas le moindre code, donc pas d'exécution à attendre. L'unique forme d'interaction avec se fichier se fera via les APIs de ressources.

Dans une DLL, le code à l'EntryPoint (le DllMain) est exécuté au chargement et au déchargement, que ce soit normalement ou via LoadLibraryA/FreeLibrary) (LoadLibraryEx est une exception, on peut spécifier de ne PAS exécuter le DllMain).
Donc, si on charge toujours une DLL avec LoadLibraryEx et les bons paramètres, la valeur de l'EP ne sera pas utilisée.

In both cases, the EP value could be bogus.

De plus, si l'EP est executé (ce qui signifie uniquement que l'execution est transférée à EP + IMAGEBASE) et que rien ne se passe de mal, tout va bien !

Exemple:

Ouvrez Notepad dans un debugger, notez l'adresse d'ExitProcess : 7C81CB12 ExitProcess 8BFF MOV EDI,EDI)
Changez l'EP vers cette adresse (soustraire l'IMAGEBASE): 7c81cv12 - 1000000 = 7B81CB12)
Lancez... l'exécution débute directement à ExitProcess...

Encore mieux, si vous forcez l'exécution à une adresse, via par exemple, une DLL sans relocations, et un exécutable importe cette DLL, avec la bonne valeur d'EP, qui pointe sur le code de la DLL, on obtient un PE qui tourne, avec un EP trop haut ou au contraire négatif...

Dans mon example, no_relocs.dll :

IMAGEBASE 330000h, Relocation 0
Section 0 VA 200
push MB_ICONINFORMATION ; UINT uType
push tada ; LPCTSTR lpCaption
...

Et dans le chargeur, no_relocs_loader.exe :

EntryPoint: FFF30200
ImageBase: 00400000
=> Exécution à 00330200 = Début de la Section 0 de no_relocs.dll

Donc ce fichier, vide et avec un EntryPoint négatif, fonctionne correctement.

En conclusion, il est difficile de dire à l'avance si un EntryPoint est correct ou non. Mais il est facile de déterminer s'il est standard ou non.

Idée originale de Costin Ionescu.

Binaires Sources: dll loader

With a rebel yell! more, more, more!

2010-01-16T23:58:00.007Z

Description of a compiled PE header
In my previous posts, I started exploring PE Headers with a minimum amount of information (as opposed to the official specifications). On the other hand, standard compilers like MASM add more elements (not necessarily documented), on top of defining, as you would expect, mosts elements of the structures.

To understand things correctly, I assembled and linked a simple HelloWorld code source in Masm, and reproduce the complete structure of the executable with a YASM source (that defines every byte of the header manually).

Between the DOS header and the FILE Header lies the DOS stub, written in 16 bits. It should be aligned to 16, as its entrypoint is defined by the amount of paragraphs. In short, the DOS code can only start at X0, and the value of DOS_HEADER.e_cparhdr will be X (no zero):

DOS_HEADER.e_cparhdr dw (dos_stub - DOS_HEADER) >> 4
...
dos_stub:
bits 16
push cs
pop ds
mov dx, dos_msg - dos_stub
mov ah, 9
int 21h
mov ax, 4c01h
int 21h
dos_msg
db 'This program cannot be run in DOS mode.', 0dh, 0dh, 0ah, '$'

Right after this (16-aligned too) lies the 'undocumented' Rich Header/Signature, which is a signature generated by the compiler with the symbols presents in the file, among other things. Even the padding is not constant, and the whole block is xored with the checksum, which makes it quite odd altogether.

RichHeader:
RichKey EQU 092033d19h
dd "DanS" ^ RichKey , 0 ^ RichKey, 0 ^ RichKey , 0 ^ RichKey
dd 0131f8eh ^ RichKey , 7 ^ RichKey, 01220fch ^ RichKey, 1 ^ RichKey
dd "Rich", 0 ^ RichKey , 0, 0

The rest of the file is clean (no other extra stuff), and only 2 directories are defined, Imports and Imports Table (Some compiler like OpenWatcom define the Copyright directory, just a pointer to a copyright string).

After covering such a 'bloated' header, I can go back to unsual PE files again.
Binaries and Sources

[...]

Description d'un en-tête PE compilé

Dans mes billets précédents, j'ai commencé à explorer des en-têtes PE avec un minimum d'informations (par rapport aux spécifications officielles). A l'opposé, des compilateurs standards comme MASM rajoutent des éléments (pas forcément documentés), en plus de définir - comme on s'y attend - la plupart des éléments de la structure des en-têtes.

Pour comprendre correctement, j'ai assemblé et linké un code source simple de Hello World en Masm, puis reproduit la structure complète de l'exécutable avec un source YASM (qui définit manuellement chaque octet de l'en-tête).

Entre les en-têtes DOS et FILE, il y a le code DOS, en 16 bits. Il doit être aligné sur 16 octets, car son EntryPoint est défini par le nombre de paragraphe. En gros, le code DOS débute forcement à X0, et la valeur de DOS_HEADER.e_cparhdr sera X (pas de zéro) :

DOS_HEADER.e_cparhdr dw (dos_stub - DOS_HEADER) >> 4
...
dos_stub:
bits 16
push cs
pop ds
mov dx, dos_msg - dos_stub
mov ah, 9
int 21h
mov ax, 4c01h
int 21h
dos_msg
db 'This program cannot be run in DOS mode.', 0dh, 0dh, 0ah, '$'

Juste après (aligne sur 16 octets également) se trouve l'en-tête/signature Rich, qui est une signature générée par le compilateur à partir des symboles présents dans le fichier, entre autres. Même le padding n'est pas constant, et le bloc entier est xore avec une somme de contrôle, ce qui rend le tout plutôt étrange..

RichHeader:
RichKey EQU 092033d19h
dd "DanS" ^ RichKey , 0 ^ RichKey, 0 ^ RichKey , 0 ^ RichKey
dd 0131f8eh ^ RichKey , 7 ^ RichKey, 01220fch ^ RichKey, 1 ^ RichKey
dd "Rich", 0 ^ RichKey , 0, 0

Le reste du fichier est propre (plus rien de rajouté), et seul 2 data directories sont définis Imports et Imports Table (des compilateurs comme OpenWatcom définissent le Copyright directory, juste un pointeur vers une chaîne de copyright).

Après avoir couvert un tel en-tête 'superflu', je peux retourner à mes fichiers PE inhabituels.
Binaires et Sources

Hey, hey, hey, what's in your head?

2010-01-14T22:04:00.013Z

PE Header holes / filling them
Since the PE loader in Windows is too flexible, most of the PE Header information can be discarded.
As the Tiny PE project proved, it's possible to get a 97 bytes PE! It also proved a valid PE can't be smaller, as 97 bytes is the minimum size to fit all the structures until OPTIONAL_HEADER.Subsystem, the last compulsory element.

In my short one-section file header (which I use in my helloworld.asm example), I define a minimum (not an absolute minimum, though) amount of elements of the PE structure, to have a file with Imports, Section and EntryPoint (none of them is strictly necessary):

IMAGE_DOS_HEADER
e_magic (constant)
e_lfanew
IMAGE_NT_HEADERS
Signature (constant)
IMAGE_FILE_HEADER
Machine (almost constant)
NumberOfSections (not strictly necessary)
SizeOfOptionalHeader
Characteristics
IMAGE_OPTIONAL_HEADER32
Magic (almost constant)
AddressOfEntryPoint (not strictly necessary)
ImageBase
SectionAlignment
FileAlignment
MajorSubsystemVersion (almost constant)
SizeOfImage
SizeOfHeaders
Subsystem
NumberOfRvaAndSizes (not strictly necessary)
IMAGE_DATA_DIRECTORY
ImportsVA (not strictly necessary)
IMAGE_SECTION_HEADER
VirtualAddress (not strictly necessary)
SizeOfRawData (not strictly necessary)
PointerToRawData (not strictly necessary)

So, in total, a PE can be defined by only 16 elements, 6 of which are not strictly necessary, excluding 3 almost constants (always the same under a modern 32 bit windows) and 2 constants signatures.

Since only a few elements are defined, the file is full of gaps (HelloWorld.exe is made of 67% of 00s).

...that's a lot of space...let's use it !

In collapsed.asm, all the elements that are not part of the header (code, data, imports) are moved into those gaps.
Among others, even the initial signature is a part of the code:

IMAGE_DOS_HEADER
e_magic dw 'MZ' ; will decode as dec ebp, pop edx

and the section name is used as an Import thunk:

SECTION_0:
kernel32.dll_THUNK:
__imp__ExitProcess:
.AddressOfData
DD iExitProcess - IMAGEBASE
DD 0

It makes quite an odd PE, but it still works! some tools may crash or fail loading it though: EntryPoint at 0, non-linear import table, etc...

HelloWorld: Binary Source
Collapsed: Binary Source

[...]

Les trous des en-têtes PE / les remplir

Puisque le système de chargement des PE sous Windows est trop flexible, la plupart de l'en-tête PE peut être oubliée.
Comme l'a prouvé le projet Tiny PE, il est possible d'obtenir un PE de 97 octets ! Il a également été prouvé qu'un PE valide ne peut être plus petit, car 97 octets est la taille minimum pour aller jusqu'au OPTIONAL_HEADER.Subsystem, le dernier élément indispensable.

Dans mon en-tête pour fichier à une seule section (que j'utilise dans l'exemple helloworld.asm), je définis un minimum (pas un minimum absolu cependant) d'éléments de la structure du PE, pour avoir un fichier avec Imports, Section et EntryPoint (aucun des trois n'étant indispensable) :

IMAGE_DOS_HEADER
e_magic (constant)
e_lfanew
IMAGE_NT_HEADERS
Signature (constant)
IMAGE_FILE_HEADER
Machine (quasi constant)
NumberOfSections (facultatif)
SizeOfOptionalHeader
Characteristics
IMAGE_OPTIONAL_HEADER32
Magic (quasi constant)
AddressOfEntryPoint (facultatif)
ImageBase
SectionAlignment
FileAlignment
MajorSubsystemVersion (quasi constant)
SizeOfImage
SizeOfHeaders
Subsystem
NumberOfRvaAndSizes (facultatif)
IMAGE_DATA_DIRECTORY
ImportsVA (facultatif)
IMAGE_SECTION_HEADER
VirtualAddress (facultatif)
SizeOfRawData (facultatif)
PointerToRawData (facultatif)

Donc en tout, un PE peut être défini par 16 éléments uniquement, dont 6 facultatifs, si on exclut les 3 quasi-constants (invariables sous un Windows 32 bits moderne) et 2 signatures constantes.

Puisque seulement quelques éléments sont définis, le fichier est plein de trous (HelloWorld.exe est vide à 67%).

...tout cet espace...utilisons-le !

Dans collapsed.asm, tous les éléments qui ne font pas partie de l'en-tête (code, données, imports) ont été déplacés dans ces trous.
Entre autre, même la signature initiale fait partie du code :

IMAGE_DOS_HEADER
e_magic dw 'MZ' ; sera interprété comme dec ebp, pop edx

et le nom de section est utilisé comme THUNK d'Import :

SECTION_0:
kernel32.dll_THUNK:
__imp__ExitProcess:
.AddressOfData
DD iExitProcess - IMAGEBASE
DD 0

Ça donne un binaire bien bizarre, mais ça marche encore ! Cela dit, certains programmes peuvent planter ou refuser de le charger : EntryPoint à 0, table d'imports non linéaire, etc...

HelloWorld : Binaire Source
Collapsed : Binaire Source

They say jump, you say how high

2010-01-13T22:56:00.009Z

Various ways of JMPing
jumping, aka branching, is one of the most common operations.

I wrote a file that implements many forms of jumping, whether they are common, obfuscated, or rare. Not everything is detailed in this post, check the source for further information.

First, Jumps,

EB 07 JMP SHORT 004000F9
E9 07000000 JMP 00400105
FFE7 JMP EDI ; 00400113
FF25 19014000 JMP DWORD PTR DS:[400119] ; 00400124
EA 32014000 1B00 JMP FAR 001B:00400132
FF2D 38014000 JMP FAR DS:[400138] ; DS:[00400138]=001B:00400145

then CALLs,

E802 CALL 00400103
FF1A CALL FAR [EDX]
FF12 CALL [EDX]
FFD2 CALL EDX
9A 7C014000 1B00 CALL FAR 001B:0040017C

RETurns

C3 RETN ; Return to 004001DE
CB RETF ; Return to 001B:004001EC
CF IRETD ; Return to 001B:004001FB, flags = 206

loop*.

Then, another way of jumping (unconditionally) is to either fake the condition by assuming a start value, or to force it, by setting a register or a flag (pushf, lahf, stc, SEH, iret).

Note that all of them (jumps, jxx, calls, return, loops) are influenced by the operand prefix: it turns dword operands in word, of course, but you will jump to the lower bits of EIP. And as expected, CALL WORD will only push a word on the stack.

004000F0:
66:EB 00 JMP SHORT 000000F3
66:E2 00 LOOPD SHORT 000000F6
66:E8 0000 CALL 000000FA
66:C3 RETN ;Return to 00006D4F, [ESP] = 7C816D4F

Naturally, any of those WORD jumps will be unlikely useful in your code, but it's an unusual way to trigger an exception.

LOOP and JECXZ are also influenced by the address prefix (like REP), which turns the condition on CX only, as you could expect. But, unlike jcxz, neither 67 Loop* or 67 Rep* have an official name (OllyDbg calls it LOOPW, as opposed to LOOPD, though).

With the same ECX value:
67:E2 02 LOOPW SHORT 004001CA ;Loop is NOT taken, CX=0001
E2 07 LOOPD SHORT 004001D1 ;Loop is taken, ECX=FFFF0001

You can also play with the stack, calling code there, pushing then modifying values.

Next are the unusual (more like anti-emulators) ways:
using an API that expects a callback function, spawning a extra thread, or using exceptions.

Last is the ability to create your own segment (local descriptor), and jump to it. With the right values (HighWord.Bits.Type), your debugger might not even be able to display the code being executed, which is quite unusual).

While the rest of the file is pretty easy, the SetLdtEntries parameter are the most difficult part to understand, so I suggest reading Nicolas' explanation if you're curious.

Big thanks to Peter Ferrie for his help (66, 67, SetLdtEntries)

Binary Source

[...]

Diverses façons de sauter
Sauter (jump, branch) est une des opérations les plus répandues.

J'ai écrit un fichier qui implémente plusieurs façons de sauter, qu'elles soient communes, dissimulée ou rare. Tous n'est pas détaillé dans ce billet, allez voir le code source pour plus d'informations.

Tout d'abord, les JMP

EB 07 JMP SHORT 004000F9
E9 07000000 JMP 00400105
FFE7 JMP EDI ; 00400113
FF25 19014000 JMP DWORD PTR DS:[400119] ; 00400124
EA 32014000 1B00 JMP FAR 001B:00400132
FF2D 38014000 JMP FAR DS:[400138] ; DS:[00400138]=001B:00400145

puis les CALL,

E802 CALL 00400103
FF1A CALL FAR [EDX]
FF12 CALL [EDX]
FFD2 CALL EDX
9A 7C014000 1B00 CALL FAR 001B:0040017C

les RETours

C3 RETN ; Return to 004001DE
CB RETF ; Return to 001B:004001EC
CF IRETD ; Return to 001B:004001FB, flags = 206

les boucles (LOOP).

Ensuite, une autre façon de sauter (inconditionnellement) est de feindre une condition, en assumant une valeur initiale, ou de la forcer, en définissant un registre ou un drapeau (pushf, lahf, stc, SEH, iret).

Il faut remarquer qu'ils sont tous (jumps, jxx, calls, return, loops) influencés par le préfixe d'opérandes : bien sur ça transforme les opérandes double mots en mot, mais on sautera a IP, les octets supérieurs étant nul. De plus, CALL WORD va simplement mettre un mot sur la pile, comme on s'y attend.

004000F0:
66:EB 00 JMP SHORT 000000F3
66:E2 00 LOOPD SHORT 000000F6
66:E8 0000 CALL 000000FA
66:C3 RETN ;Return to 00006D4F, [ESP] = 7C816D4F

Evidemment, aucune de ces sauts sur un mot ne semble utile dans du code normal, mais c'est un moyen inhabituel de déclencher une exception.

Loop et Jecxz sont aussi influencés par le préfixe d'adresse (comme REP), qui mettra la condition sur CX uniquement. Mais contrairement à jecxz/jcxz, ni Loop ni Rep n'ont de nom officiel sur un mot (OllyDbg les appelle LoopW, par opposition a Loopd)

avec la meme valeur pour ECX :
67:E2 02 LOOPW SHORT 004001CA ;Loop is NOT taken, CX=0001
E2 07 LOOPD SHORT 004001D1 ;Loop is taken, ECX=FFFF0001

On peut aussi jouer avec la pile, y exécuter du code, empiler puis modifier des valeurs.

Ensuite viennent les moyens moins courant (plutôt juste des anti-émulateurs):
appeler une API qui utilise un callback, créer un nouveau fil, ou utiliser les exceptions.

Enfin, la possibilité de créer votre propre segment (descripteur local) et d'y sauter. Avec les bonnes valeurs (HighWord.Bits.Type), on peut même empêcher votre débogueur d'afficher le code en cours d'exécution, ce qui est plutôt inhabituel.

La majeure partie du code source est plutôt facile à comprendre, mais les paramètres de SetLdtEntries sont bien compliques, donc allez voir l'explication de Nicolas si vous voulez en savoir plus.

Un grand merci à Peter Ferrie pour son aide (66, 67, SetLdtEntries)

Binaire Source

Storm warning, but there's no fear

2010-01-12T22:10:00.014Z

relocater < mutater < virtualiser
I already wrote about a relocater and different kinds of virtual machines. Between the two of them, there is another kind of executable, simpler than virtual machine but particularly suitable for obfuscation:
a mutater, or polymorphic code.
Similar to virtual machines, some data represents the virtual code to execute. However, in this case, the architecture is strictly the same as the cpu. The main point of mutation is randomization. And if you add some junk code in the middle, you get what happens when virii modifies themselves from one file to the other.

this is indeed simpler than virtualization, yet quite efficient to make reverse engineering (or identification) more difficult. That's why this technique is present in most advanced virii or packers. In packers, code doesn't mutate itself, it's just some part of code that is randomly generated on the fly before being executed, like in the example of this post.

Here are 2 different executions:

MOV ECX,FC07379C PUSH 40
XOR ECX,FC0737DC PUSH Tada
PUSH ECX NOP
NOP PUSH Helloworld
PUSH Tada PUSH 0
NOP NOP
MOV ECX,F8477840 CALL MessageBoxA
XOR ECX,F80779BC MOV ECX,0A2EF248
PUSH ECX XOR ECX,0A2EF248
NOP PUSH ECX
PUSH 0 CALL ExitProcess
CALL MessageBoxA
PUSH 0
PUSH 00400136
PUSH ExitProcess
CALL $ + 5
RETN

Download links: Binary Source

[...]

déplaceur < muteur < virtualiseur

J'ai déjà parlé d'un déplaceur et de différentes formes de machines virtuelles. Entre les deux, il y a une autre forme d'exécutable, plus simple que les machines virtuelles, mais particulièrement utile pour la dissimulation :
un muteur, autrement dit du code polymorphique.
Comme pour les machines virtuelles, des données représentent le code virtuel à exécuter. Mais dans ce cas, l'architecture est la même que le processeur. Le point important est que le code est généré aléatoirement. Et si on ajoute du code inutile au milieu, on obtient ce qui se produit quand un virus se modifie d'un fichier à l'autre.

C'est effectivement plus simple que la virtualisation, mais c'est quand même efficace pour rendre l'analyse de code (ou l'identification) plus difficile. C'est pour cela que cette technique existe dans tous les virus ou packeurs avancés : dans un packeur, le code ne mute pas lui-même, c'est juste une partie du code qui est générée à la volée de manière aléatoire avant d'être exécutée, comme dans l'exemple de ce billet.

Voici deux exécutions consécutives :

MOV ECX,FC07379C PUSH 40
XOR ECX,FC0737DC PUSH Tada
PUSH ECX NOP
NOP PUSH Helloworld
PUSH Tada PUSH 0
NOP NOP
MOV ECX,F8477840 CALL MessageBoxA
XOR ECX,F80779BC MOV ECX,0A2EF248
PUSH ECX XOR ECX,0A2EF248
NOP PUSH ECX
PUSH 0 CALL ExitProcess
CALL MessageBoxA
PUSH 0
PUSH 00400136
PUSH ExitProcess
CALL $ + 5
RETN

Télécharger : Binaire Source

And go where you're going to

2010-01-11T23:29:00.008Z

DIY PE
To be able to create custom PEs, I wrote a simple script that helps with simple tasks like generating import structures, PE checksum and default values.

So, add all PE structures manually (or better, use the same one over and over), generate imports, and voila! you have a handmade PE file in which you control every byte.

I didn't extend (yet?) that script to Exports/Resource/Relocations/TLS/Sections, because I don't use them so often.
Also, different Section/File alignments are not supported. Once again, I don't really need it (often).

Source directory

[...]

PE maison

Pour pouvoir créer des PEs spéciaux, j'ai écrit un script simple, qui permet de faire des petites choses comme générer les structure des imports, calculer la checksum ou mettre des valeurs par défaut.

Donc, ajoutez les structures PE a la main (ou mieux, utilisez toujours le même en-tête), générez les imports, et voilà! vous avez un PE fait main, dans lequel vous contrôlez chaque octet.

Je n'ai pas (encore?) ajouté la gestion des Exports/Resource/Relocations/TLS/Sections, car je n'en ai pas besoin si souvent.
De même, les alignements Section/File différents ne sont pas possibles. Là aussi, je n'en ai pas besoin (souvent).

répertoire Source

Useless but original

2010-01-11T22:49:00.011Z

An different form of junk code
You probably know about the overlapping instruction technique used to fool disassemblers:
due to the way x86 CPUs work, jumping over a E8 byte will make a bogus CALL instruction appear in the code.

if you use a longer instruction like IMUL, you can fit any instruction, so you can create a blocky piece of code.
So from the outside, whether from hex or from assembly, it looks quite blocky

EB 02 JMP SHORT 004000F4
69846A 40681C01 4000EB02 IMUL EAX,[EDX+EBP*2+11C6840],2EB0040
698468 22014000 9090EB02 IMUL EAX,[EAX+EBP*2+400122],2EB9090
69846A 00E81E00 0000EB02 IMUL EAX,[EDX+EBP*2+1EE800],2EB0000
69846A 00E81900 00005461 IMUL EAX,[EDX+EBP*2+19E800],61540000

while the execution trace looks almost normal:

EB 02 JMP +4
6A 40 PUSH 40
68 1C014000 PUSH 0040011C
EB 02 JMP +4
68 22014000 PUSH 00400122
90 NOP
90 NOP
EB 02 JMP +4
6A 00 PUSH 0
E8 1E000000 CALL 0040012F
EB 02 JMP +4
6A 00 PUSH 0
E8 19000000 CALL 00400135

Absolutely useless like any form of junk code, but way more original than E8/E9 :)

If you have ever seen an unusual form of junk code or obfuscation, let me know.

Binary Source

[...]

Du code de dissimulation pas comme les autres

Vous connaissez probablement la technique d'instructions superposées, qui permet de tromper les désassembleurs:
A cause du fonctionnement des processeurs x86, sauter un octet E8 fera apparaître une fausse instruction CALL dans votre code.

Si on utilise une instruction plus longue comme IMUL, on peut cacher n'importe quelle autre instruction, et donc créer du code en bloc.

De l'exterieur, que ce soit en hexadecimal ou en assembleur, le code a l'air plutot carre

EB 02 JMP SHORT 004000F4
69846A 40681C01 4000EB02 IMUL EAX,[EDX+EBP*2+11C6840],2EB0040
698468 22014000 9090EB02 IMUL EAX,[EAX+EBP*2+400122],2EB9090
69846A 00E81E00 0000EB02 IMUL EAX,[EDX+EBP*2+1EE800],2EB0000
69846A 00E81900 00005461 IMUL EAX,[EDX+EBP*2+19E800],61540000

alors que la trace d'execution a l'air presque normale:

EB 02 JMP +4
6A 40 PUSH 40
68 1C014000 PUSH 0040011C
EB 02 JMP +4
68 22014000 PUSH 00400122
90 NOP
90 NOP
EB 02 JMP +4
6A 00 PUSH 0
E8 1E000000 CALL 0040012F
EB 02 JMP +4
6A 00 PUSH 0
E8 19000000 CALL 00400135

C'est aussi inutile que toute forme de code de dissimulation, mais c'est bien plus original que les E8/E9 :)

Si vous avez vu d'autres formes originales de dissimulations, faites le savoir.

Binaire Source

You'll stumble in my footsteps

2010-01-11T21:58:00.012Z

A different flow obfuscation: a relocater
I wrote a simple executable, implementing an idea by Piotr Krysiuk, where all routines are made to be executed at the same address. Because of that feature, following the flow is potentially difficult, and creating a direct dump could be annoying as no disassembler allow different pieces of code to be present at the same address.

To give you an example, here are the 2 functions of that binary upon their execution:

First:
004000FA 6A 40 PUSH 40
004000FC 68 6E014000 PUSH 0040016E ; ASCII "Tada!"
00400101 68 74014000 PUSH 00400174 ; ASCII "Hello World!"
00400106 6A 00 PUSH 0
00400108 E8 55000000 CALL 00400162 ; MessageBoxA
Later:
004000FA 6A 00 PUSH 0
004000FC E8 67000000 CALL 00400168 ; ExitProcess

As stated before, they are both made to run at the same address. If you want to have a flat file, you will need to relocate some code.

Such a 'relocater packer' would be the little brother of a mutater or a virtualiser:
in all cases, you'd need to disasm and analyse, but in this case, the only thing you need to identify and relocate are immediate dwords.

Binary Source

[...]

Une dissimulation de flux différente: un déplaceur

J'ai écrit un simple exécutable, d'après une idée de Piotr Krysiuk, où toutes les routines sont faites pour s'exécuter depuis la même adresse. A cause de ce point particulier, suivre le flux de l'exécution peut s'avérer difficile, et créer un dump peut être compliqué, puisqu'aucun désassembleur n'autorise des instructions différentes à la même adresse.

Pour vous donner un exemple, voici les 2 routines du binaire lors de leur exécution:

D'abord:
004000FA 6A 40 PUSH 40
004000FC 68 6E014000 PUSH 0040016E ; ASCII "Tada!"
00400101 68 74014000 PUSH 00400174 ; ASCII "Hello World!"
00400106 6A 00 PUSH 0
00400108 E8 55000000 CALL 00400162 ; MessageBoxA
Ensuite:
004000FA 6A 00 PUSH 0
004000FC E8 67000000 CALL 00400168 ; ExitProcess

Comme mentionné précédemment, elles sont toutes deux faites pour s'exécuter à la même adresse. Pour avoir un fichier à plat, il faut déplacer le code.

Un tel 'packeur déplaceur' serait le petit frère du muteur ou d'un virtualiseur: on doit dans tous les cas désassembler et analyser, mais à priori, on a ensuite juste besoin d'identifier et de recalculer les constantes en DWORD.

Binaire Source

when CPUs have too many opcodes...

2010-01-02T23:54:00.015Z

Back from my last post, to real machines, I decided to release as-is a YASM source that contains most x86 32bits opcodes, including SSE, AVX, FPU,...

My conclusion is that there are way too many!

You can use it just for curiosity or testing your favorite disassembler.

Source Code (Yasm)

the longest opcode (as a word) is

vaeskeygenassist xmm0, xmm0, 0

even though the recent

vbroadcastf128 ymm0, [0]

is not far behind.

and

vpermil2pd ymm0, ymm0, ymm0, ymm0, 0

is commented out (removed from the specs), which is a shame, it would be so great to have 5 operands!

*Update* Thanks to Sebastian Biallas for the correction - btw his HT Editor disassemble everything!

[...]

Quand les processeurs ont trop d'instructions...

Retour aux vraies machines après mon billet précèdent, j'ai décidé de rendre public tel quel un fichier source en YASM, qui contient la plupart des instructions x86 32bits, y compris SSE, AVX, FPU...

Pour résumer, il y en a beaucoup trop!

Vous pouvez jeter un oeil par curiosité, ou pour tester votre désassembleur favori.

Code Source (Yasm)

l'instruction la plus longue (en tant que mot) est

vaeskeygenassist xmm0, xmm0, 0

même si le récent

vbroadcastf128 ymm0, [0]

n'est pas loin derrière.

et

vpermil2pd ymm0, ymm0, ymm0, ymm0, 0

est mis en commentaire (supprimé de l'implémentation officielle), ce qui est dommage, ça serait si génial d'avoir 5 arguments!

*MAJ* Merci à Sebastian Biallas pour la correction - au fait, son HT Editor désassemble tous les opcodes !

when VMs have only one opcode...

2009-12-24T21:06:00.019Z

VMs are common in advanced packers or virii, but they seem to follow the same architectures (x86 or stack machine).
I was curious, and implemented, around a small fibonacci example, the usual models of course, but as well the TTA and Subleq ones, two models of one instruction set architectures.

Opcode-less VMs are quite small in code, but the virtual code is quite obscure - which makes an easy but annoying challenge:
typically, you would expect that MOV is the most basic opcode, and arithmetic operations tend to be more complex. But in Subleq, a standard MOV is made of 4 lines of code, while SUB+JLE is only 1.
I was quite surprised myself (yet, it works, of course!), which proves I'm too familiar with standard models.

What about you ?

Binary Source (MASM32)

To give you an idea, here is the virtual code in the Subleq example (while on the other hand, the VM code itself is only 14 lines of asm):

000: reg1, reg1, 00C
00C: rom0, reg0, 018
018: reg0, reg1, 024
024: reg0, reg0, 030
030: reg2, reg2, 03C
03C: reg0, reg0, 048
048: reg0, reg2, 054
054: reg0, reg0, 060
060: reg3, reg3, 06C
06C: rom1, reg0, 078
078: reg0, reg3, 084
084: reg0, reg0, 090
090: reg4, reg4, 09C
09C: reg3, reg0, 0A8
0A8: reg0, reg4, 0B4
0B4: reg0, reg0, 0C0
0C0: reg2, reg0, 0CC
0CC: reg0, reg4, 0D8
0D8: reg0, reg0, 0E4
0E4: reg2, reg2, 0F0
0F0: reg3, reg0, 0FC
0FC: reg0, reg2, 108
108: reg0, reg0, 114
114: reg3, reg3, 120
120: reg4, reg0, 12C
12C: reg0, reg3, 138
138: reg0, reg0, 144
144: rom2, reg0, 150
150: reg0, reg1, 15C
15C: reg0, reg0, 168
168: reg1, reg0, 180*
174: reg0, reg0, 090*
180: reg0, reg0, 18C
18C: reg0, reg1, 1A4*
198: reg0, reg0, 090*
1A4: reg1, reg1, 1B0
1B0: reg3, reg0, 1BC
1BC: reg0, reg1, 1C8
1C8: reg0, reg0, 1D4

* conditional jumps

[...]
Quand les MVs n'ont qu'une seule instruction...

Les machines virtuelles sont courantes dans les packeurs avancés ou les virus, mais elles semblent toujours faites avec les mêmes architectures (x86 ou a pile). J'étais curieux, et j'ai écrit, autour d'un petit exemple de Fibonacci, les architectures classiques, bien sûr, mais aussi la TTA et la Subleq, qui sont toutes deux des modèles a une seule instruction.

Une machine virtuelle sans instruction a un code minuscule, mais le code virtuel est plutôt obscur, ce qui en fait un challenge facile laa implémenter mais plutôt casse-pied. D'habitude, on s'attend a ce que MOV soit l'instruction la plus simple, et que les opérations arithmétiques soient plus complexes. Mais dans une machine Subleq, un MOV standard nécessite 4 lignes de code, alors qu'un SUB+JLE, une seule.
J'étais très surpris moi-même (même si ça marche, bien sûr), ce qui prouve que je suis trop habitués aux modèles standards.

Et vous ?

Binaire Source

Pour vous donner une idée, voici le code virtuel de l'exemple en Subleq (alors que le code de la machine virtuelle ne fait que 14 lignes d'assembleur):

000: reg1, reg1, 00C
00C: rom0, reg0, 018
018: reg0, reg1, 024
024: reg0, reg0, 030
030: reg2, reg2, 03C
03C: reg0, reg0, 048
048: reg0, reg2, 054
054: reg0, reg0, 060
060: reg3, reg3, 06C
06C: rom1, reg0, 078
078: reg0, reg3, 084
084: reg0, reg0, 090
090: reg4, reg4, 09C
09C: reg3, reg0, 0A8
0A8: reg0, reg4, 0B4
0B4: reg0, reg0, 0C0
0C0: reg2, reg0, 0CC
0CC: reg0, reg4, 0D8
0D8: reg0, reg0, 0E4
0E4: reg2, reg2, 0F0
0F0: reg3, reg0, 0FC
0FC: reg0, reg2, 108
108: reg0, reg0, 114
114: reg3, reg3, 120
120: reg4, reg0, 12C
12C: reg0, reg3, 138
138: reg0, reg0, 144
144: rom2, reg0, 150
150: reg0, reg1, 15C
15C: reg0, reg0, 168
168: reg1, reg0, 180*
174: reg0, reg0, 090*
180: reg0, reg0, 18C
18C: reg0, reg1, 1A4*
198: reg0, reg0, 090*
1A4: reg1, reg1, 1B0
1B0: reg3, reg0, 1BC
1BC: reg0, reg1, 1C8
1C8: reg0, reg0, 1D4

* sauts conditionnels

This is not a pipe

2009-12-19T23:27:00.003Z

...nor a virus.... just the EICAR test file.
I never took the time before to look at it in details, so I wrote a commented source to re-create it exactly.

Source code

a few fixes

2009-05-10T17:20:00.001+01:00

I created a minimal project to keep libdasm updated.
a few fixes were already submitted, thanks to Silvo Cesare and Georg Wicherski, to fix a few FPU, TEST and MOV opcodes.

Stupid sequence of the day

2009-04-16T11:42:00.009+01:00

Inspired from ReWolf:
9A 69 E8 C8 C2 CD C3
generates instructions that decode correctly at every bytes, independantly of the following bytes...

9A 69E8C8C2CDC3 callf 0C3CD:0C2C8E869
69 E8C8C2CDC3 imul ebp,eax,0C3CDC2C8
E8 C8C2CDC3 call 0C40E0C36
C8 C2CDC3 enter 0CDC2,0C3
C2 CDC3 retn 0C3CD
CD C3 int 0C3
C3 retn

sadly the 69 imul doesn't always decode that way, it's not a generic 5 bytes cloaker.

no more hidden progress

2009-02-01T09:32:00.002Z

After having converted several working hashes algorithms to classes, I decided to put everything from my personal wip repository to a branches/wip on the public repository.

next step : reduce the /wip branch to the minimum.

a different challenge

2008-05-19T21:53:00.005+01:00

A colleague brought an interesting puzzle to solve.
I like the fact that you can always remove any part of this puzzle, even the first one you put, it's not stuck under the next ones. It gives you the impression that it's very easy and you can solve it within minutes. err....
Sadly, I realized I wouldn't have enough time IMO, so I went for the bruteforcing - and learned to make shallow copies of lists :)

codesource (python) here

changes

2008-03-02T18:54:00.004Z

New job and new family situation made me stop working on challenges as much as I wanted to...
No more teach-me neither, at least for now. Still planning to do many things, but right now everything is on hold.

done

2007-11-11T21:07:00.000Z

haiklr's hysteria crackme

unusual keyfileme with weaknesses to find. patience & logic

BlueOwl's UpxEd

funny hand-crafted upx, simple obfuscation

done

2007-11-09T17:59:00.000Z

imp's SimpleS

Socket. original & simple. looking forward to a sequel.

done

2007-11-06T20:57:00.000Z

Unicorn CrackMe1

pure logic, original. Couldn't prove there is only one serial though.

done

2007-10-31T21:16:00.000Z

Palto's Crackme

Custom Upx-based packer, AutoHotKey, XCBC, Tea

Hmx0101 CrackMe#3

NE, 16 bits, Nag, Serial = CleanAlgo(Name). Todo:keygen

done

2007-10-29T11:37:00.000Z

dila's Fishing with Dila v0.1, 2, 3, 4, 5

simply funny.

Hmx0101's CrackMe8

RVA, Upx+Epp, 2 Anti-Olly, serial=CleanAlgo(name)

Hmx0101's CrackMe7

same packing, serial=CleanAlgo(name)

Hmx0101's CrackMe6

packer = custom (junk + xor loop) + UPX, original test,
the check should have been much more complex. very original but disappointing in the end

Hmx0101's CrackMe5

original too. not difficult but entertaining.

Hmx0101's CrackMe4

original again. Anti-debug & unpacking, 3 serials, complex algo

Hmx0101's CrackMe2

hardcoded buggy password

Hmx0101's secretme1

Serial=CleanAlgo(CurrentPID, GetComputerName)
I didn't like the mix of patching and keygenning, though.

Hmx0101's KeyFileMe

line1 = Name, line2 = Serial, Serial=BloatedAlgo(Name)

Hmx0101's junky_1

limited junk, hardcoded password, simple decryption

raven's no_reason

clean. minimalist anti-debug. serial=GoodAlgo(Name)

raven's no_reason2

original anti-debugs & checks. serial=GoodAlgo(Name). Interesting!

done

2007-10-27T14:13:00.000+01:00

Hmx0101's SecretMe2

if (GetComputerName == HardcodedName)
{HardcodedSerial = CleanAlgo(HardcodedName)}

haunte's Crachme

serial = CleanAlgo(name, GetComputerName)

n00b's C#KeygenMe1Custom

.Net, serial = CleanAlgo(name)

n00b's KeygenMeX

.Net, registry, serial = CleanAlgo(name)

n00b's CKeygenMe1

Delphi, Base64, TRegWare... a big mess for a simple serial

encrypto's Easy Keygenme 4.0

Delphi, MD5, serial = CleanAlgo(GetComputerName, name)

done

2007-10-21T14:58:00.000+01:00

Adjiang Keygenme3

Annoying wizard, Serial = string + CleanChecksum(string)

lafarge's crackme 1

2007-10-18T20:14:00.000+01:00

It's a custom & original packer, FindWindow, ZwQuery, indirect imports. I created an ImpRec plug-in.

Predator's Pirupiru

2007-10-18T20:11:00.000+01:00

solution

done

2007-10-18T20:09:00.000+01:00

Predator's Pirupiru

VB, appended data rc4 binder, strlen

and Bastard1

same binder, serial == CleanAlgo(name)

done

2007-10-17T21:16:00.000+01:00

LaFarge's crackme 0.2 & 1 & 2

serial == CleanAlgo(name)

challenges websites

2007-10-11T10:51:00.001+01:00

CrackMes DE
the best and biggest, reviewed solutions. great !
Tuts For You
Biggest unpackme repository

In French:
Défis FC
Le site de BigBang

done

2007-10-10T19:01:00.001+01:00

chaise's crackmechaise2

Serial == CleanAlgo(ComputerName, Name)

skapunky's skrackme1

Nag (JMP Table)
Button (__vbasetobj)
Serial (__vbastrcmp)

done

2007-10-08T20:12:00.000+01:00

opcode0x90's crackme_nop

serial check, but original

lilcw's just a simple xor encryption

2007-10-07T10:52:00.000+01:00

Here is my solution for this interesting yet not difficult challenge. Enjoyable.

done

2007-10-07T09:21:00.000+01:00

lilcw's just a simple xor encryption

logic, asm

chaise's crackmechaise1

basic serial, time

_khAttAm_'s unUPX me

upx, vb, binder

mucki's protector

simple packer

thecipher's IcantDoThis

nothing special

warleyalex's Delphi for PHP

delphi, javascript

TiGa's Vista Sidebar Gadget

.gadget, javascript