Creating an export table

[Nacho_dj]

Hello:

I would like to patch in memory an application, in order to configure an export table. Then I could use it to import some functions from an external application, in order to use some code of the patched application.

First, I launch the application with a loader. The application is packed.
When it is loaded, I write in the memory of the target process the configuration of the entire export table.

When trying to import some functions of that export table with the loader, I do the following:

I do LoadLIbrary of that application (it is an .exe file), then I want to GetProcAddress some functions of that table.

However, this is not working. Not providing any handle but nil.

I do not understand why. Maybe it is because the export table couldn't be created patching in memory when the process is already loaded.

Do you have suggestion? Is it a better way to do that? I do not know if this could be performed with hooks...

Cheers


Nacho_dj

I'm suspecting it's because LoadLibrary is reloading the file from disk, and thus hence not seeing your newly added "section".

What you should try next, as an experiment, it simply passing the memory address of the now loaded packed exe to GetProcAddress. If you are observant enough in your debugging you may have noticed that LoadLibrary returns to you the very Virtual Address of where the file LoadLibrary called was loaded! Which means GetProcAddress then also takes in a pointer directly to the EXE/DLL header. GetProcAddress does a normal export or import table lookup like you would do in your own code were you to write a DLL export scan tool.

So attempt to simply just pass the address of the loaded application.

Remember as well that you cannot use LoadLibary and GetProcAddress across process boundaries ! If you called "LoadLIbrary" inside your loader, and it's an actual seperate program, you will get the "library" which is on disk of course. Which explains why you have no export table.

If the loader and the EXE share the same process however, you should be able to simply pass the VA of the EXE that got loaded into GetProcAddress.


-Lunar

[Nacho_dj]

Hi Lunar Dust:

Thanks for your answer.

You're right, it is as you have mentioned. LoadLibrary takes the file in the hard disk, not the process already launched. So, no patched export table appears.

And there is some more. As the file is a packed .exe, it loads with LoadLibrary without being unpacked, so no code available inside it.

I wonder if CreateProcess could launch the new process in the same memory area that the loader owns, that is, in the same loader process. This would be what I need.
Then, I think it will be easier patching an export table in the loaded process inside the loader process and then accessing the functions exported by the new process.

Anyway, for now I have got two independant processes and therefor no possibilities of accessing from the loader to the code of the loaded application.

I was thinking about let the loader patch totally the application and then when dumped, do a LoadLibrary in order to access that piece of code that is performing the required function.
But I think there could be a better solution than this. If there is a process in memory, won't it exist an easier way?


Cheers


Nacho_dj

Well, what do u think the Export Table Values in the PE-Header are for?
You can patch in an Export table,but i guess you wont be able to get hold of any Exports that easy then..

Why dont u put your stuff in some DLL and inject some code to load that DLL instead?
This would enable you to code all stuff you need in your dll without any relying on the original code, just create the proc and inject some pseudo dll-loader code in the apps context..

cheers

[Nacho_dj]

Thank you NtSC:

Maybe that is the only one thing I could do to perform what the code is doing in the process.

I have to test it. I am trying now to code all that the original program does in that routine of my interest, but it is a little bit hard.

Cheers

Nacho_dj

i happened to remeber some thing i read vaguely but now i neither can find a link or google for it
but have you tried to use those NtCreateSection ZwMapViewOfSection
and load of other undocumented API
the article i speak of was a pdf and it happened to do some thing like
loading a file from memory (included some linux mmap routines too not from disc)
using the above apis

[Nacho_dj]

Hello JuneMouse:

It seems that all those functions are related to files. But when talking about processes in memory...

I have found these links:
http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Section/NtCreateSection.html

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Section/NtMapViewOfSection.html

http://www.sysinternals.com/Information/NativeApi.html

The last URL shows api's that could perform tasks of loading sections of file, but I cannot find any speaking about loading "pieces of code" in memory from another process in the loader process.

Anyway, many thanks for your suggestion

Cheers

Nacho_dj

i just found the pdf its called remote library injection
authours are skape and jt

you should find it in nologin.org papers section
i am not providing a direct link because i would also like you to
take a look on other papers there as well
some just run above head but neverthless a good read

hope you get together some ideas from there

Maybe you could create an additional Section. Then change the EP to this section. You can create a structured Exception Handler there. After you have done this you can set int3's into the unpacking code and then jump back to the EP. You gain control of the code whenever a int3 ist reached. Of course you could also place other illegal Instructions like XOR EAX, EAX - MOV [EAX], EAX, but int3s are much smaller and you don't need to write so much code back. If the programm creates structured Exception Handlers itself it is much more difficult to find the right places to patch.

EDIT: It is also possible to change the values of the registers or on the stack.

[Nacho_dj]

Hello:

Junemouse, I just have downloaded the pdf, I will take a slow reading of it.

Messer, it seems interesting, and a new good point of view, but I have never read anything about "structured Exception Handler". Do you know a good document to work on it?

Thanks for your help

Nacho_dj

[Hero]

Structured exception handler(SEH) is a way for handling exceptions!
You surely seen codes like this in many programs:

push offset handler
push fs:[0]
mov fs:[0],esp
....
pop fs:[0]
add esp,4
ret
handler:
....
mov eax,1
ret

This is a SEH.
If you know rusian,or you will use online translators like babelfish,You can use these tutorials:
http://wasm.ru/article.php?article=Win32SEHPietrek1
http://wasm.ru/article.php?article=Win32SEHPietrek2
http://wasm.ru/article.php?article=Win32SEHPietrek3
or else you can use web site that I attached(I don't remember its URL) for a great tutorial.
In addition I don't forget when I asked the same question here(or woodmann),and get a blame from JMI!

sincerely yours

[Nacho_dj]

Hi Hero:

Very nice of you providing me all this help

I have just downloaded your info, (sorry I do not know a word of russian ) but anyway I will try to translate it as you mentioned. I will read it, sure!

Maybe I have seen that code you are referring in certain debugging session, but now I am sure I didn't know what was happening there

Thanks for all.

Have a good day mate!

Cheers

Nacho_dj

Maybe this could be interesting: hxxp://www.anticracking.sk/EliCZ/infos/SEHall.zip