Results 1 to 7 of 7

Thread: Hardcoded dll export address

  1. #1

    Hardcoded dll export address

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

  2. #2
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    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>
    Last edited by blabberer; September 26th, 2013 at 00:38.

  3. #3
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17
    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...
    A mind is like a parachute. It doesnt work if it's not open.

  4. #4
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,079
    Blog Entries
    5
    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.

  5. #5
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    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 Name:  odbg2indcalls.PNG
Views: 238
Size:  34.0 KBusing 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)}

  6. #6
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17
    I feel dumb, I didn't notice Olly reveals the function address inside the box under the disasm... shame on me!
    Thx blabberer
    A mind is like a parachute. It doesnt work if it's not open.

  7. #7
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,486
    Blog Entries
    15
    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
    Attached Images Attached Images  

Similar Threads

  1. Hardcoded dll export address: Python approach
    By My Infected Computer in forum Blogs Forum
    Replies: 0
    Last Post: May 14th, 2014, 17:26
  2. add ordinal to export table
    By AmAdEuS in forum The Newbie Forum
    Replies: 5
    Last Post: September 21st, 2004, 17:42
  3. ? hook to a dll export?
    By _Servil_ in forum OllyDbg Support Forums
    Replies: 2
    Last Post: November 17th, 2002, 11:36
  4. export any functions from a DLL
    By oyang2002 in forum Tools of Our Trade (TOT) Messageboard
    Replies: 2
    Last Post: May 15th, 2002, 14:19
  5. Softice VB export question
    By madmaN in forum Malware Analysis and Unpacking Forum
    Replies: 4
    Last Post: April 11th, 2002, 11:51

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •