Defcon 19 b400 writeup
Hint
Retrive the key
Résolution
Pour commencer on va ouvrir le fichier avec PEiD, qui nous détecte :
tElock 0.98b1 -> tE!
tElock
Pour ce type de packer, il va falloir configurer correctement notre Ollydbg, aucune exception ne doit etre passé au programme :
Aprè avoir laissé olly chargé le processus, nous sommes actuellemt à l'entry point :
00438BD6 >^E9 25E4FFFF JMP b400_e32.00437000
Lancez le programme avec F9. Puis enchainez les excpetions avec SHIT + F9.
On va compter combien de fois olly break ( ici 20 fois ), apres qu'une exception est était levé, voir le listing ci - dessous :
- 00438A12 | DIV EDI
- 00438A48 | JNB SHORT b400_e32.00438A26
- 0043708D | NOP
- 00437090 | STC
- 00437099 | CLC
- 0043709E | CLD
- 004370A3 | NOP
- 004370A7 | DIV EBX
- 004376A8 | LEA EAX,EAX ; Illegal use of register
- 00437AA1 | DIV BX
- 00437AE4 | CLC
- 00437B28 | NOP
- 00437B67 | DIV EBX
- 00437BA6 | INT 68
- 00437BF1 | NOP
- 00437DE4 | DIV EBX
- 00437E1E | JNB SHORT b400_e32.00437DFC
- 004386F1 | LEA EAX,EAX ; Illegal use of register
- 004387D7 | DIV EDI
- 00438827 | JNB SHORT b400_e32.00438805
Afin de trouver l'OEP, on va breaker sur le dernier JNB, 19 ième combinaison de SHITF + F9.
A partir de là, on appuie sur ALT + M ( on ouvre le memory map ) et on va set un breakpoint d'accés mémoire sur la section de code :
Une fois le breakpoint set, SHIT + F9 et on tombe ici :
0042A000 B8 DB B8
0042A001 30 DB 30 ; CHAR '0'
0042A002 5C DB 5C ; CHAR '\'
0042A003 43 DB 43 ; CHAR 'C'
0042A004 00 DB 00
0042A005 50 DB 50 ; CHAR 'P'
0042A006 64 DB 64 ; CHAR 'd'
0042A007 FF DB FF
0042A008 35 DB 35 ; CHAR '5'
0042A009 00 DB 00
0042A00A 00 DB 00
0042A00B 00 DB 00
0042A00C 00 DB 00
0042A00D 64 DB 64 ; CHAR 'd'
0042A00E 89 DB 89
0042A00F 25 DB 25 ; CHAR '%'
0042A010 00 DB 00
0042A011 00 DB 00
0042A012 00 DB 00
0042A013 00 DB 00
0042A014 33 DB 33 ; CHAR '3'
0042A015 C0 DB C0
0042A016 89 DB 89
0042A017 08 DB 08
0042A018 50 DB 50 ; CHAR 'P'
0042A019 45 DB 45 ; CHAR 'E'
0042A01A 43 DB 43 ; CHAR 'C'
0042A01B 6F DB 6F ; CHAR 'o'
0042A01C 6D DB 6D ; CHAR 'm'
0042A01D 70 DB 70 ; CHAR 'p'
0042A01E 61 DB 61 ; CHAR 'a'
0042A01F 63 DB 63 ; CHAR 'c'
0042A020 74 DB 74 ; CHAR 't'
0042A021 32 DB 32 ; CHAR '2'
On tombe ici sur le réel OEP du packer tElock : "0042A000".
Je n'ai pour l'instant pas analysé le code car on voit quelque chose d'intéressant, un nouveau packer apparament "PECOMPACT2".
Donc rien ne sert de se précipiter à dump le process et reconsruire l'IAT.
Continuons sur notre lancé et jouons avec PeCompact.
PeCompact
J'ai dumpé le process à partir de ce moment et vérifié avec PEiD :
PECompact V2.X-> Bitsum Technologies * Sign.By.fly *
Si on analyse (CTRL + A) le code vu au dessus, on voit une anti-debug tricks :
0042A000 B8 305C4300 MOV EAX,b400_e32.00435C30 ; Mise en place
0042A005 50 PUSH EAX ; SEH Handler
0042A006 64:FF35 00000000 PUSH DWORD PTR FS:[0]
0042A00D 64:8925 00000000 MOV DWORD PTR FS:[0],ESP
0042A014 33C0 XOR EAX,EAX ; Creation d'une
0042A016 8908 MOV DWORD PTR DS:[EAX],ECX ; PageFault
Un apercu de la fenetre de l'état de la stack, pour confirmer :
Pour bypass cette tricks, il suffit d'aller poser un breakpoint en 00435C30.
Run le programme jusqu'à l'access violation.
Pressez SHIFT + F9 pour passer l'exception au programme.
En "00426016" la meme tricks est présente, on regarde le seh handler : "00430C30", et on va poser notre breakpoint, et SHIFT + F9.
A partir de là, on step over...step over...step over... jusqu'à :
00430CF2 FFE0 JMP EAX
Qui va nous faire arriver sur un PUSHAD :
0042E1E0 . 60 PUSHAD
Ici apparament c'est le réel entry point du packer PeCompact.
Mais comme précedement, continuons l'analyse.
A partir de ce moment, je me dis tiens peut etre de l'UPX derriere, je descends dans le disas :
0042E35D . 61 POPAD
0042E35E . 8D4424 80 LEA EAX,DWORD PTR SS:[ESP-80]
0042E362 > 6A 00 PUSH 0
0042E364 . 39C4 CMP ESP,EAX
0042E366 .^75 FA JNZ SHORT b400_e32.0042E362
0042E368 . 83EC 80 SUB ESP,-80
0042E36B .-E9 F031FDFF JMP b400_e32.00401560
Je pose un breakpoint sur le JMP.
Apres tout ca j'etais perdu, je savais plus trop ou j'allais, le programme m'affichait "hello world".
Et il avait l'air de decrypt encore pas mal de merde dans la section code et data.
Je décide donc de regarder de plus près tout ce qu'il a pu decrypt, je voyais des chaines PE passer, ca m'avait l'air d'etre un semblant de pe header mais malheuresement non.
Pas du tout ou alors je m'y prenais mal car je recuperais le ms dos header du bin orignal afin de reconstruire un nouveau pe.
Bref a force de tourner en rond, j'ai grep sur tout le dump et là la clef est sortie :
> strings dump3.exe | grep PE
HowCanThisPossiblyBeAValidPEFile?
PEC2^O
gEPEI
Key
HowCanThisPossiblyBeAValidPEFile?
Defcon 19 f400 writeup
Hint
Can you beleive people do this? ddTEK doesn't. (http://pwn32.ddtek.biz/)
Résolution
Si on allait sur la page en question avec un user agent différent d'un iphone / ipod, on se faisait jeter sur la page faq.html. Afin d'étudier la page il fallait simplement rentrer dans l'url le keyword "faq"
http://pwn32.ddtek.biz/?suce_mes_couilles=faq
A partir de là, on pouvait étudier les sources comme on voulait. Un wget aurait suffit aussi. On voit que la page request un pdf :
http://pwn32.ddtek.biz/_/iPhone2,1_3.1.2.pdf
Donc on va étudier le pdf en question avec un outil pdf-parser.py.
On peut remarquer que l'objet 13 contient du stream, on décide donc de l'extraire.
python2 pdf-parser.py -o 13 --raw --filter iPhone2,1_3.1.2.pdf > bin
Quand on regarde l'output de cette objet avec la commande string, on a l'impression que c'est une application iphone.
Mais là une chaine nous saute aux yeux :
http://pwn32.ddtek.biz/wad.bin
Une fois ce fichier récupéré, on teste la commande file et se rend compte que ce ne sont que des datas.
Mais on peut voir une archive 7z à l'offset 0x1b521 :
hexdump -C wad.bin | grep -i 7zx
0001b520 01 82 a1 9c ec fd 37 7a 58 5a 00 00 04 e6 d6 b4 |......7zXZ......|
On va extraire donc l'archive :
dd if=./wad.bin skip=111905 of=./wad.xz bs=1 count=3797368
Une fois l'archive récupéré, on se rend compte que c'est un rootfs.
On touille dedans pendant un moment, en se demandant mais qu'est qu'on cherche ?
A partir de là on teste de faire differ à partir du pdf original :
http://jailbreakme.com/_/iPhone2%2c1_3.1.2.pdf
Mise à part des ".svn" un binaire nous saute aux yeux : /usr/bin/dd
Si on string dessus, ca n'a pas du tout l'air d'un binaire dd.
On regarde avec IDA le code ARM mais sans résultat, ce code ne fait strictement rien, d'intéressant.
Par ailleur il y a 4 grand nombres qui ressortent, on décide donc de les mettre dans des double dans un programme en C :
#include <stdio.h>
double
a=41358753080588780315500696417148503196370008505043360338644939021284539327654424368206170740213813076058322365516034006270625614745638277215965686397551374257625369654940618745555501980517665488240640.000000;
double
b=273020167277193934342483321951392739131140631949880731514555218503200924051802886516416983650292597201352459748672990971210795734498587443982103979231419127824384.000000;
double
c=109868682199889090983893607446542759799370795099978204527886814871815275332732684149782782932243583477726231807149879389352427825978796531514954916754473975757796372140255258111985922092457311221042226817127194804092923531694479704498641458322997248.000000;
double
d=8887824086628450300085222950423508459269193936749714415660759918033307608850811297588582757614917095982291010098451602122996273175590810261747631678220597664532468741350897995232883808808537964727011624779797357169712195651789942060581116921485444775936.000000;
int main(void)
{
char *p = NULL;
int i;
p = (char*)&a;
for (i = 0; i < sizeof(double); i++)
printf("%c", p[i]);
p = (char*)&b;
for (i = 0; i < sizeof(double); i++)
printf("%c", p[i]);
p = (char*)&c;
for (i = 0; i < sizeof(double); i++)
printf("%c", p[i]);
p = (char*)&d;
for (i = 0; i < sizeof(double); i++)
printf("%c", p[i]);
}
Key
Et cela nous affiche gentiment la clef qui est :
DDTEKJailbreaksarethemostbestest
Pages : 1