Import table not resolved!

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

[kao]

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.

[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 April 6, 2017 by CodeCracker

[evlncrn8]

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

[atom0s]

This may be of interest for what you are describing:

https://www.codeproject.com/Articles/12532/Inject-your-code-to-a-Portable-Executable-file

http://www.ntcore.com/files/inject2exe.htm

Same thing on both links just different visual representation.

[kao]

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!

[CodeExplorer]

Finded documentation:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx

So in the end I have to resolve imports manually!
 

[Nacho_dj]

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

[evlncrn8]

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

[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 April 9, 2017 by CodeCracker

[evlncrn8]

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

[CodeExplorer]

18 hours ago, evlncrn8 said:

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

Haha...
The exe file has no tls.
 

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

[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 April 11, 2017 by CodeCracker

[evlncrn8]

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 ?

[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 April 11, 2017 by CodeCracker

[Loki]

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.

[Nemo]

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

[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 May 23, 2017 by CodeCracker

[CodeExplorer]

gBurner.Virtual.Drive.v4.3.x64.Tool-FIXED-SND.zip:
Fixed a problem with the path.
 

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