Bomb #1

My cur­rent class assign­ment con­sists of reverse engi­neer­ing a piece of code writ­ten by the pro­fes­sor. Basi­cally the pro­gram reads in one line from STDIN at a time and checks to see if it’s the right phrase. If it is, that bomb is defused and it con­tin­ues to the next one. If the phrase is incor­rect that the bomb blows up and I’ll have to try again.

Below is my method­ol­ogy for Phase 1.

** Note that as a stu­dent we were given access to the source code of the “shell” pro­gram that calls the other func­tions that actu­ally do the com­pare. So I know that the func­tions are called phase_1() through phase_6(). The func­tion names could also be guessed by using obj­dump –t bomb.exe and look­ing at the func­tion names.

** Also, solutions.txt con­tains a sin­gle line with con­tent: test­ing

$ gdb bomb
(gdb) b phase_1
(gdb) dis­play /i $pc
(gdb) r solutions.txt

That runs the pro­gram until the break­point is hit. Once it’s hit I run disas to dis­play the assem­bly of the cur­rent func­tion. I notice that there is a call to strings_not_equal and fig­ure that the two val­ues pushed onto %esp are likely the argu­ments, and based on the func­tions name, are likely strings. I then use dis­play /a $eax to take a look at the address con­tained in %eax. Finally, I use x /s 0x405040 and x /s 0x404140 to look at the strings located at those addresses. One is the string I passed in, and the other is the win­ing string. I change my solutions.txt file to have the new string in it and test it to val­i­date. It works! Bomb 1 defused!

Bomb - Phase 1

Deobfuscating JavaScript at the Browser

The Web­sense Secu­rity Labs Blog has an inter­est­ing post up about one method of deob­fus­cat­ing JavaScript. As I’ve eluded to in pre­vi­ous posts, any code thats pushed to the client’s browser must even­tu­ally be under­stand­able by that browser. This is why the mali­cious scripts have to con­tain code to deob­fus­cate them­selves. The trou­ble of course is get­ting the script to run with­out actu­ally run­ning the mali­cious content.

My method has pri­mar­ily been repli­cate the scripts func­tion­al­ity and eval­u­a­tion of code with a perl script on a *nix com­mand line. If every­thing is get­ting printed to STDOUT instead of the source of an html file inside a browser there is no chance that the code could exe­cute. This has worked well be can often be tedious.

The method dis­cussed in the post above involves hook­ing the document.write func­tion of JavaScript inside the mshtml.dll. With this in place an ana­lyst can extract the deob­fus­cated code before it is fully processed by the browser. That’s clever!