View Full Version : Hardcoded dll export address

My Infected Computer
September 25th, 2013, 19:37
It’s relatively easy to understand what’s going on when you are in front of a clear disasmed malware but most of the time you have to deal with packers, obfuscations, encryptions, useless code, etc etc… the list is long. There are many ways to deal with every single case and everyone follows his own method […]https://stats.wordpress.com/b.gif?host=zairon.wordpress.com&blog=448309&post=840&subd=zairon&ref=&feed=1


September 26th, 2013, 00:07
hi zai ,

you posted ollydbg cant directly understand

i just opened calc.exe (xpsp3 )

assembled a call dword [xxxx] in some arbitrary location
at xxxxxx i place address of user32!MessageBoxW

ollydbg easily recognizes it even without reanalyzing

if you ask ollydbg to assume commands and dwords
it resolves it with arguments too

no analysis just inserted the call and data

01013D71 FF15 793D0101 CALL NEAR DWORD PTR DS:[1013D79] ; USER32.MessageBoxW
01013D77 00 DB 00
01013D78 00 DB 00
01013D79 34 65 XOR AL, 65
01013D7B 46 INC ESI
01013D7C 7E 00 JLE SHORT calc.01013D7E

added assumes ( rightclick -> analysis -> during next analysis treat selection as command on 71 and as doubleword on 79 ) and reanalyzed


01013D71 . FF15 793D0101 CALL NEAR DWORD PTR DS:[1013D79] ; \MessageBoxW
01013D77 . 0000 ADD BYTE PTR DS:[EAX], AL
01013D79 . 3465467E DD USER32.MessageBoxW

is that not the behaviour you find ? or didn't i understand the statement ?

edit i butchered the icztute msgbox to call hardcoded address and loaded it in windbg
windbg can resolve the names too it seems


F:\masm32\icztutes\tute02>cdb butch_msgbox.exe

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: butch_msgbox.exe

7c90120e cc int 3
0:000> bp 401000

0:000> g

Breakpoint 0 hit

00401000 6a00 push 0

0:000> u
00401000 6a00 push 0
00401002 6800304000 push offset msgbox!MsgCaption (00403000)
00401007 6819304000 push offset msgbox!MsgBoxText (00403019)
0040100c 6a00 push 0
0040100e ff152f104000 call dword ptr [msgbox!ExitProcess+0xf (0040102f)]
00401014 6a00 push 0
00401016 ff1533104000 call dword ptr [msgbox!ExitProcess+0x13 (00401033)]
0040101c 0000 add byte ptr [eax],al
0:000> ln poi(40102f)
(7e4507ea) user32!MessageBoxA | (7e450838) user32!MessageBoxExW
Exact matches:
user32!MessageBoxA = <no type information>
0:000> ln poi(401033)
(7c81cb12) KERNEL32!ExitProcess | (7c81cb30) KERNEL32!LdrShutdownProcess
Exact matches:
KERNEL32!ExitProcess = <no type information>

September 26th, 2013, 04:51
Hi blabberer!

You got the point, yes. With my blog post I only wanted to explain one of the ways for solving the problem. The idea was to provide a possible point of discussion, just to learn new methodologies and why not criticize/comment some of them.

I should have been more precise in my post because I didn't tell you I was using Ollydbg v2 (Correct me if I'm wrong but I'm not able to find a way to directly solve the problem with it). Anyway, the good old Ollydbg v1 works well against indirect calls and you don't need to use tricks or external tools because the problem simply doesn't exist.

Your Windbg example works fine too but I think it's quite annoying to resolve every single call at hand...

September 26th, 2013, 09:19
I like your script method, partly because it can be done in IDA running on a completely different OS version (i.e. Win 7) than from where you did the dump (i.e. XP VM). The other option is to do a LoadLibrary/GetProcAddress lookup like you did in your Reveal Imports IDA plugin, but that requires you to do it with the same system dlls as the dump OS. The text file approach is portable.

The x86emu IDA plugin is useful too for resolving those indirect hard coded functions from a dump IDB, as it essentially loads a copy of the system dlls as new segments. Emulate/Windows/Export lookup will tell you the function name for a system address, or you can also single step the indirect call and it will display the emulated parameter values along with the function. What it doesn't do however is annotate the disassembly with the function names, which is what you can do with the IDC approach.

September 26th, 2013, 13:31
no odbg v2.01 beta 2 also resolves them nicely see pic
and in windbg it is not necessary to resolve them manually it gets resolved automatically to symbol when you are on the line
output below 2810using pc (trace over till next call command )


0:000> bp 401000
0:000> g
Breakpoint 0 hit
00401000 6a00 push 0
0:000> pc
0040100e ff152f104000 call dword ptr [msgbox!ExitProcess+0xf (0040102f)] ds:0023:0040102f={user32!MessageBoxA (7e4507ea)}
0:000> pc
00401016 ff1533104000 call dword ptr [msgbox!ExitProcess+0x13 (00401033)] ds:0023:00401033={KERNEL32!ExitProcess (7c81cb12)}

September 26th, 2013, 16:29
I feel dumb, I didn't notice Olly reveals the function address inside the box under the disasm... shame on me!
Thx blabberer

September 27th, 2013, 02:16
learning is a never ending process so they say nothing to be ashamed of
btw odbg 1.10 is kinda better still than v2.0 is a fact odbg will show it in comments too and pick the src too

and hadn't you posted your way i wouldn't have posted these answers so it is a definitive gain overall
btw if you click decode registers for any command in options the box will show the names whether you are on eip or not (this option can lead to misunderstanding so use with caution)
see pic both resolves CreateFileA when the line is selected while eip is at 0x401000