KPNC

! שָׁלוֹם I mean goeie dag from Tel-Aviv!

what’s a wonderful place! I feel like I traveled another planet, or returned from the future, where architecture is absolute different from everything I have ever seen before, not speaking how amazing shore line is, the line’s occupied by endless hotels scratching the sky and bursting my mind with nuclear bomb of exploding creativeness. I shot a few photos and started to upload some of them on my photo-blog: http://zen-way.org

outside Israel some people believe that there is a war and Tel-Aviv is not safe for traveling. bullshit! just a few girls with guns and… soft-ice. could you believe? girls who love soft-ice more than OllyDbg?! wow! they ever more sexy than girls with guns. I asked to touch a gunpoint or at least kiss her but was sent out. well, except for that people are very friendly. whether is just fine, men are incredible smart - it was a pleasure for me to share my ideas with them (I learned many new things at the same time :-). dozens security firms are interested by my work - means a lot of job - no way to be unemployed there and no way to starve. food is natural, cheap and unbelievable delicious. what’s else one could whish for?

it was my second but definitely not the last visit to Israel. I like Israel with all my heart. too much so positive feelings. too many so good and so smart people there. it’s just incredible. it can’t be, but it’s real. it’s a dream, or maybe a dream came true? I don’t know, but I’m 100% sure that Israel is the best place of Earth to live and work. um, I have not seen other countries yet (Malaysia is an exception). well, going to fly to South Africa, Johannesburg Area on Feb-19 to lecture RE course (the syllabus is not available yet) to Sense-Post company - we met at the last HITB 2008 conference and were exchanging tons of mail for a while. Sense Post is very creative company crafted with experienced people who definitely know what they are doing and what for.

…in a few hours I will leave my den, step aboard and fly to Tel-Aviv to lecture RE course for reverse engineers. the syllabus is available. who ever would have thought it! for years I had never crossed the border of my country. think what a sacrifice he has made. I lost my solitariness. but I’m still free. don’t know how long though. right now I’m working for Endeavor Security, Inc. it’s a non-exclusive position means my boss closes his eyes to my little “business”. so I lecture RE courses world-wide. it does not bring a lot of money and I’m thinking maybe it’s a good idea to get a full-time job, but… all offers I have got - they are exclusives => losing my freedom. so, I’m thinking… is that worth what it costs? well, maybe not. anyway, I’ll do my best to continue lecturing reverse courses just to meet smart clever people, just to share ideas with. it’s really amazing! well, if you’re interesting, drop me a line or leave a comment.

as a reverser working for Endeavor Security, Inc nezumi gets used to analyze zillions security patches and, like many other reversers, its hard tool is Patch-Diff (free analogue of commercial Bin-Diff). Patch-Diff is great, but… too graphical (don’t like gui stuff very much, nezumi loves cheese and console).

too hard to trace there wires

Patch-Diff works good if there are just a few changes, but dealing with a totally rewritten function driving me bats and takes too much time. these graphs… oh… well, nezumi has came to much better solution.

1) use Patch-Diff or Bin-Diff to find matched function(s);
2) ask Hex-Rays to decompile them into high-level C-code;
3) compare patched and un-patched C-code with WinDiff or GNU diff3;

it’s works! but… there is a problem. guess, patched function has more local vars, so the stack frame is completely different from the old one, so, Hex-Rays gives different names to the same variables!!! thus, WinDiff goes crazy and shows many false positive unmatched lines.

what we’re going to do? well… Hex-Rays is an interactive decompiler (View/Open Sub-view/Opcode or F5), so it’s possible (and not too hard!) to rename variables, I mean to synchronize them. it takes time, but it’s definitely worth what it costs!!!

this trick helped me to analyze MS09-01 patch extremely fast. of course, right now, it’s just a pure idea, but I’m going to improve it.

btw, does anybody know the best tool for smarting comparing C-sources? plz, write me back (info#re-lab.org) or leave comment here.

not Baghdad actually, just Borland stuff. it’s russian jargon. borland => baghdad (they sound quite similar). well, you want to hack a Baghdad program? and breakpoints do not help you to hack it fast? well, guys…

set breakpoints on library functions. IDA-Pro recognizes them and once they have been recognized and addresses determined - feel free to use any debugger - Olly or Soft-Ice.

the most interested functions are listed bellow (of course, the list is incomplete, just gives you an idea what to do):

@TControl@GetText$qqrv ; TControl::GetText(void)
@System@@LStrCmp$qqrv ; System::__linkproc__ LStrCmp(void)
@Sysutils@Now$qqrv ; Sysutils::Now(void)
@Sysutils@DecodeTime$qqr16System@TDateTimerust2t2t2 ;; Sysutils::DecodeTime(System::TDateTime,ushort &,ushort &,ushort &,ushort &)
@Sysutils@StrToInt$qqrx17System@AnsiString ; Sysutils::StrToInt(System::AnsiString)
@Controls@TControl@SetVisible$qqro ; Controls::TControl::SetVisible(bool)
@Controls@TControl@SetText$qqrx17System@AnsiString ; Controls::TControl::SetText(System::AnsiString)
@Mask@TCustomMaskEdit@GetText$qqrv ; Mask::TCustomMaskEdit::GetText(void)

btw, there is a good plugin for Olly - GoDup (by godfather+) allowing to use IDA-Pro signatures directly.

suddenly, I felt the need of automatic upx OEP finder. it’ easy to do with my hands, but I wanted to analyze files in batch mode, so I open the folder with large collection of Olly Scripts. tried one. nothing. ok, the second. nothing. well, third. nobody wants to work. upx 3.01. um…

it took about a minute to write my own script. it’s work. tested on upx 0.76, 1.20, 1.24, 3.01, the code is follow. maybe somebody will find it useful.

var s

mov s, [eip]
and s, FF
cmp s, 60
jne not_upx

eob Break_1
mov s, esp
sub s, 04
bphws s, “r”
run

Break_1:
BPHWC s
eob Break_2
mov s, eip
sub s, 1
findop s, #E9#
cmp eip, $RESULT
JAE last_jmp

bphws $RESULT, “x”
run

Break_2:
BPHWC $RESULT
last_jmp:
sti
ret

not_upx:
MSG “not upx?!”
ret

I’m going to Tel-Aviv to lecture RE-course for security engineers well, I went to my favorite S7 Air company web site to book tickets and what I saw? wow! site was not working more than six hours due to hacker attack and I’m still not sure that my booked tickets are good enough to flight. ok, we will see…

click to see full-size image

as a reverser, working for a security company, I used to analyze a lot of shell-codes every days. most of them were caught by AMP and stored in .pcap format with packet header(s) and other stuff like this that has nothing to do with actual machine code. a typical shell-code looks like this:

typical shell-code

where is our Entry Point? how to find it fast? a common approach - just to start disassemble the code from different locations until we get the most sentence listing, but sometimes shell-code starts from an encrypted block followed by the decryptor and we just waste our time.

by accident I came upon the better way. just look for “EBh” (jmp short) opcode. it works well in most cases, brining us very close to real entry point. maybe you will get a few false positives, but not more.

it works coz almost every shell-code has “jmp short” command near to the entry point, so looking for EBh opcode is a good approach to find the entry point very fast! don’t ask me, “why EBh, man? why EBh works better than anyone elese?!” I don’t know. I just know this works. theoretically, CALL and LOOP should work as well, but… they don’t. EBh works much better helping me to reverse shell-code faster :-) it takes about 3 seconds to find Entry Point with HIEW in average.

in our case, EBh has been found at 544h offset. of course, this is _not_ the read entry point, but something very close to it. EBX is not used (it’s reinitialized by following commands), so just skip 53Ch line. two second lines opens stack frame to allocate some memory for local variables, thus 53Dh _probably_ is the real entry point. “probably” coz we can’t be sure until analyze the rest of shell-code, but in this case our suggestion is absolute correct and finding the entry point took just a second.

Entry Point has been found

there is a way to find out if a program was packed or not. XP/S2K3 has a bug that has to be taken into account unless a packer wants to crash a packed program.

FreeLibrary() does not unload statically linked libraries, but frees dynamically linked ones. consider the following code. it should work. at least it works on XP/S2K3 (W2K is a bug free):

// get USER32 module handle
HANDLE h; h = GetModuleHandle(”USER32.DLL”);

// free the library (3 times just to guarantee the reference count is zero)
FreeLibrary(h); FreeLibrary(h); FreeLibrary(h);

// time to unload
Sleep(3000);

// call any function from statically linked USER32
MessageBox(0,”:-)”,”[x]“,0);

ok, now remove USER32 from the import table and load it on the fly.

// load USER32 and get the module handle
HANDLE h; h = LoadLibrary(”USER32.DLL”);

// free the library (3 times just to guarantee the reference count is zero)
FreeLibrary(h); FreeLibrary(h);FreeLibrary(h);

// time to unload
Sleep(3000);

// call any function from dynamically linked USER32
(int (WINAPI *)(int, char*, char*, int)) GetProcAddress(h,”MessageBoxA”)(0, “:-)”, “[x]“, 0);

wow! the program crashes!!! interesting… but… it has nothing to do with packers! um, actually it has. some packers (and especially protectors) leaves only KERNEL32.DLL there and loads the rest on the fly.

guess, we have a file with statically linked libraries. guess, the program frees one or more libraries doing it deliberately or maybe there is a bug. this bug does not appear, coz FreeLibrary not unloads statically linked DLLs. imagine what happens if we pack the file by packer removes all DLL from the import table? the answer: the program will crash!!!

download the POC (original exe and file packed by RLPack) and test your packer/protector collection.

…in a few hours I’ll fly to Moscow to meet USA’ consul for an interview and giving them my fingerprint. if everything will be fine (a dream that’s coming true) I will fly to San Francisco on Feb-4 till Feb-9. I would be happy to meet you guys there! my cell phone is: +7 (918) 268-37-76. buzz me or send SMS.

San-Francisco is an amazing, beautiful and kinky city! never been there, but why knows, maybe it will be my second home. an atomic opportunities to change my life. it’s a nuclear bomb. a real one, earthshaking everything that surround me and all. it’s not about the job or big salary, it’s all about the most interesting people to work with there, doing right things. the pot of gold at the end of the rainbow. ok, like my favorite movie hero says: just wait and see.

blackd0t () started working on his own PE packer and reached the moment where everything is fine, but MSVC++ 2005 floating point files refuse to work and end up with the runtime error: “R6002: floating point not loaded error” . it’s a common problem. many commercial packers meet the same bug.

well, let’s find out what’s this bug all about! first of all I wrote a simple floating-point program and translated it with Microsoft Visual C++ 2008 (Express). the source code is followed (if don’t have MS VC under your hands, just download the archive):

int a; double x = 1.2f;
for (a = 0; a < 10; a++) x += sin(x); cout << x;
return 0;

ok. run it and get 3.14159. the program runs fine! now, we’re going to make “.rdata” writable. why? blackd0t mentioned what he already found out: if “.rdata” is writable, we get the error. the question is why?! maybe there is a bug: if .rdata section is writable - floating point library damages critical data, maybe not, who knows?

open exe with HIEW, press ENTER to go to hex-mode, F8 to call PE-header, F6 for ObjTable, move cursor to “.rdata”, F3 to edit, find “Attributes” there, F3 to edit, change the highest bit from 0 to 1 and press F9 twice to save changes. ESC (twice) to exit.

ops! now we see:

$R6002bug-demo.exe
runtime error R6002
- floating point support not loaded

ok. run HIEW and restore the attributes back. everything works fine as before. load exe into OllyDbg, View -> Memory, find “.rdata” and set memory breakpoint on write. run the program. the program runs fine, nobody tries to write something to “.rdata” section. hm… strange…

ok, ask HIEW to make “.rdata” writable again, reload the file into OllyDbg and run it (with memory breakpoint). the program does not work (the same error), but our breakpoint has been not triggered. what’s a helll?!

make “.rdata” non-writable, reload the file into OllyDbg, View -> Memory and change access of “.rdata” section to RW. run the file. no error! the program works fine.

ok. we got it!!! the floating point library checks not access attributes themselves, but verifies PE-header. go to dump windows (in Olly). press CTRL-G and type the address of the header (400000h in this case). find “.rdata” there and move cursor to 40 00 00 40 (the last DWORD before “.data”). set hardware breakpoint on access and press F9 to run the program, the breakpoint is triggered!!!
how do you like this:

.text:0040E780 __IsNonwritableInCurrentImage proc near
.text:0040E780
.text:0040E782 push ebp
.text:0040E783 mov ebp, esp
…
.text:0040E7C1 call __ValidateImageBase
…
.text:0040E7D6 push 400000h
.text:0040E7DB call __FindPESection
.text:0040E7E0 add esp, 8
.text:0040E7E3 test eax, eax
.text:0040E7E5 jz short loc_40E822
.text:0040E7E7 mov eax, [eax+24h] ; !!! breakpoint is triggered here !!!
.text:0040E7EA shr eax, 1Fh

_IsNonwritableInCurrentImage() reads PE-header in order to checks - if its argument belongs to non-writable section.

so, packers are obligated to keep original PE sections layout (or restore only PE header in memory) unless they want to crash floating point applications translated with MS VC and maybe other compilers.

thanks blackd0t for the interesting question!

I wonder: how may packers/protectors will be unable to process this file? going to find out. plz, test all packers/protectors you only have under your hands and leave comments. time to send bug reports :-)

first of all it’s bug of MS RTL - bitch should check real page attributes, not just PE-header!

second of all: numerous packers/protectors do not restore PE-header or damage it to prevent dumping or… disables all PE-header pages (PAGE_NO ACCESS)