CodeCracker

Import table not resolved!

18 posts in this topic

Import table not resolved!
Hi guys, I try to load a exe , x64, unprotected (virgin) file using invoke LoadLibrary,&ModuleLoc
anyway import table is not resolved, import table thunks (qwords) are not replaced, have still the orginal unresolved value!
Any ideea how to resolve it?
Hope I won't have to resolve manually (by coding a import resolver)!!
 

Share this post


Link to post
Share on other sites

If you are loading *EXE* using LoadLibrary, you're most likely using LOAD_LIBRARY_AS_DATAFILE flag. When this flag is specified, you can only use PE resources; imports and relications and TLS are not touched. See MSDN docs.

If that is not the case, perhaps relevant lines of your code and a short explanation of what you're trying achieve will help.

Share this post


Link to post
Share on other sites

Posted (edited)

The exe is a 64 bits executable, with no relocations. The exe is loaded on a different address then image base from PE.

ModuleLoc db 'C:\Program Files\gBurner Virtual Drive\GCDTRAY.EXE',0
.code
WinMain proc
invoke LoadLibrary,&ModuleLoc

Never used LOAD_LIBRARY_AS_DATAFILE flag!

Is there any better option then fixing manually these thunks? (fixing manually imports)?
 

Edited by CodeCracker

Share this post


Link to post
Share on other sites

if you manually fix the imports you're probably only scratching the surface of the things you'll need to do.. i dont think you're meant to load an exe in another exe space, so windows is probably being nice and doing the data file thing auto (usually if that is done the base returned is masked with the ending of 01 eg : 0x70000001 ... and you might also have permissions issues given you're loading from c:\program files which is usually a protected folder...

Share this post


Link to post
Share on other sites

As always, MSDN to the rescue..

Quote

The module can be a library module (a .dll file) or an executable module (an .exe file). If the specified module is an executable module, static imports are not loaded; instead, the module is loaded as if DONT_RESOLVE_DLL_REFERENCES was specified. See the dwFlagsparameter for more information

So, no, you can't load exe and expect imports to be resolved. Windows will automagically switch to "don't do stupid stuff" mode! :D

2 people like this

Share this post


Link to post
Share on other sites

Why don't you change the flag of the exe to be considered as a DLL when loaded?

For instance, if you edit the file with CFF Explorer, go to FileHeader, and then Characteristics, push "Click here" and check the "File is a DLL" checkbox and save it. Now test again...

Anyway, if you don't want your exe being executed when loaded, you'd rather load it with a loader and:

- Set a breakpoint at a certain address if debugged

or

- Set an infinite loop at that address if open with createfile "as suspended" and then ResumeThread...

 

Cheers

Nacho_dj

Share this post


Link to post
Share on other sites

if you change the flag etc you'd also be best advised setting no entrypoint as dll's entry points and exe's ones are pretty different... but yeh i'd just listen to all here.. dont bother trying to load an exe into your exe's address space, its not meant to work and something will fornication up and if you summon satan you can put him back into his box yourself

Share this post


Link to post
Share on other sites

Posted (edited)

Hi guys. Some updates: I've chosen to reconstruct imports manually (wasn't that hard to accomplish),
I've rebased to new image all pointers (qwords) from .data and .rdata section and the original program works like a charm!
For x64 (unlike x32) call qword [offset] are relative to the place from where are called (like "call offset" instruction) so won't need aditional fixing, .text section (code section) doesn't need to be fixed!
Didn't finished it yet, some initialization (calling some stuffs from program) are still to be done...
 

Edited by CodeCracker

Share this post


Link to post
Share on other sites

tls etc too ? and ... i mean this in the nicest way.. you're nuts :)

1 person likes this

Share this post


Link to post
Share on other sites
18 hours ago, evlncrn8 said:

tls etc too ? and ... i mean this in the nicest way.. you're nuts :)

Haha... :lol:
The exe file has no tls.
 

Share this post


Link to post
Share on other sites

Here we go again: when I inline patch with x64dbg everything works like a charm.

When I try to do it programalically I epic fail:
mov ebx,dword ptr [ModuleAddress]
add ebx,0358EEh
cmp byte ptr [ebx],074h
jnz NextPatch1
mov byte ptr [ebx],0EBh

The address is correct, when I debug with x64dbg it shows as value 074 (right original byte)
but the jnz will jump meaning that the value isn't right,
if I force to jump to the line mov byte ptr [ebx],0EBh it patches something:
hell if I know where (not the right place anyway).
Once again It is about x64 stuff!
Will be great if someone will guide me in the right direction!
The code I need to patch is in the code section!
 

Share this post


Link to post
Share on other sites

Posted (edited)

The strange thing continue:
; 00000000004458E0 | 49 8B 06                        mov rax,qword ptr ds:[r14]
; 00000000004458E3 | 49 8B CE                       mov rcx,r14
; 00000000004458E6 | FF 90 08 01 00 00        call qword ptr ds:[rax+108]
; 00000000004458EC | 85 C0                            test eax,eax
; 00000000004458EE | 74 46                             je gcdtray.445936

If I try to test/change EE address it fails, if I try to test/change E6 all will work ok!

Edit:
I've chosen to change call qword ptr ds:[rax+108] to xor eax,eax and it works ok!
But it will be great if someone will bring some light here!
 

Edited by CodeCracker

Share this post


Link to post
Share on other sites
4 hours ago, CodeCracker said:

Here we go again: when I inline patch with x64dbg everything works like a charm.

When I try to do it programalically I epic fail:
mov ebx,dword ptr [ModuleAddress]
add ebx,0358EEh
cmp byte ptr [ebx],074h
jnz NextPatch1
mov byte ptr [ebx],0EBh

shouldnt you be using x64 code, like rbx and so on ?

1 person likes this

Share this post


Link to post
Share on other sites

Posted (edited)

I've tried with both x64 registers and x32 registers, same result on both cases.
But you are right.

Crap: I got it! While getting what is at EE I got CC
opcode for INT 3 is 0xCC

I must be stupid LOL! The problem was that I set a breakpoint to that exact address!
 

Edited by CodeCracker
2 people like this

Share this post


Link to post
Share on other sites

Its these moments where you feel like punching yourself in the face.... we've all been there.

I was setting up some SAML authentication in php to connect to AzureAD this week..... took me an hour to realise I had pasted over "<?php" at the start of a .inc file and the code wasn't being treated as php.

2 people like this

Share this post


Link to post
Share on other sites

You would be surprised with unpacking on x64 how much of a pita it is with imports, you can do it correctly but the tools used can f&*k it up.. settings apparently can make a huge difference.. always scan for dwords referenced in other ways aka. pushed or mov esi(edi)(eax), etc...(easily scripted ;) )

if a file contains fixups, it needs to be included in that area.. relocs

mov ebx,dword ptr [ModuleAddress]

for that not to work it would not have the correct pointer there[ModuleAddress].. look into that.. ( if it is wrong you need to figure out why :) ) ASLR is a pita..

1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now