Log in

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

https://zairon.wordpress.com/2013/09/26/hardcoded-dll-export-address/
blabberer
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
Code:




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

Code:


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

Code:




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



ntdll!DbgBreakPoint:

7c90120e cc              int     3

0:000> bp 401000



0:000> g



Breakpoint 0 hit



msgbox!start:

00401000 6a00            push    0



0:000> u

msgbox!start:

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>

0:000>
ZaiRoN
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...
Kayaker
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.
blabberer
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 )

Code:


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)}
ZaiRoN
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
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