Jump to content
Tuts 4 You

Import table not resolved!


CodeExplorer

Recommended Posts

CodeExplorer

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)!!
 

Link to comment

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.

Link to comment
CodeExplorer

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
Link to comment

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...

Link to comment

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

  • Like 2
Link to comment

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

Link to comment

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

Link to comment
CodeExplorer

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
Link to comment
CodeExplorer
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.
 

Link to comment
CodeExplorer

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!
 

Link to comment
CodeExplorer

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
Link to comment
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 ?

  • Like 1
Link to comment
CodeExplorer

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
  • Like 2
Link to comment
  • 2 weeks later...

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.

  • Like 3
Link to comment

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..

  • Like 1
Link to comment
  • 1 month later...
CodeExplorer

gBurner.Virtual.Drive.v4.3.x64.Tool-SND.zip:

For gBurner Virtual Drive 4.1 and 4.3
gBurner Virtual Drive is free,
this is just a image mounter helper.

Installation note:
Copy gBurnerMount.exe to gBurner Virtual Drive path
ie. C:\Program Files\gBurner Virtual Drive
Import ImagesMountWith.reg to register iso, uif and nrg extension.

gBurnerMount will only mount the image to the first Drive of gBurner Virtual Drive.
Execute gBurnerMount.exe, browse for image by clicking "..." button,
and click on Mount button to mount the image.
You could also drag and drop the image to gBurnerMount.exe and will be
automatically mounted.
 

 

Edited by CodeCracker
Link to comment

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
×
×
  • Create New...