ASM Community

Couldn't help but notice:



Both examples fail coz you're declaring a string ... you should bo with db 081h,045h,0e0h,001h,00h ... Otherwise masm will treat as text, then convert it to hex.

Just in case you were still wondering.

Fake

Math book maybe (jk)
If you are unsure what 'hexidecimal' is:
http://www.the-eggman.com/seminars/about_hex.html

Those real long hex strings you are using are called GUIDS.
Not a math thing,a M$ thing.
Read the MSDN on GUIDS.
"{01E04581-4EEE-11D0-BFE9-00AA005B4383}"
is the string representation of the GUIDs.

And I think all of the "Mapping the PE,that's a nice idea;but how to solve the jump table problem?" posts are people that are confused as to what your goal is.

Because your original post you where trying to passed a text file to regedit.exe from memory instead of the HDD , which is impossible since that executable 'regedit.exe' just assumes you have a .reg to pass it on the cmd line.

Synopsis:
You need to write GUIDs to a section of the registry as a series of bytes. you where unsuccessful in the past and used shellexecute to load them as .reg files. Now you can insert them with the registry API. You may be confused about 'hexadecimal' and most likely what a GUID is.

Good Luck

RobotBob

Nope, just a hassale to code all its functions. :grin:

I think i asked this question the wrong way. I got a buffer inside my executionable that has the REGEDIT4 Header and my own string under it to replace a registy key.

But i have to createfile than writefile to disk than execute it from disk.

I think i have no choise but to do it this way but just in case maybe i might have been suprise.

Now i can just OpenKey and SetKey but if it is possible to do it with shellexexecute "somehow" and NOT have to write it to disk to do it would be a plus.

That what i was trying to ask.

Vortex:

roticv:

Vortex:

roticv:

Well roticv, What is a PE loader that can load an image into memory and then run it? How should it work in general?

Vortex, the problem with running a process from memory is not the API jumptable. API function real addresses and jump table can relativly easily be adjusted. I have done these adjustments in the attached code example. My intention was to try to run Iczelion's dialog box tutorial 10.2 exe file from memory. To do this I put the Dialog.exe as RCDATA resource of my exeres.exe. I loaded the resourse to memory and made some adjustments. The adjusted hex values are copied to an allocated memory and expanded according to file headers. Running the code from allocated memory the API functions call works.

The problem is label addresses, process addresses and data addresses. The compiler sets the image base address, code offset, file alignment and section alignment and compiles the code according to these fact. In the example process above the ImageBase=400000h, code offset=1000h, file alignment=200h and section alignmen=1000h. Which means that code starts at 401000h equal to first section (.text). Next section starts at 402000h and data section (.data) starts at 403000h.

All label and process addresses in code are compiled in relation to 401000h. If code under "DlgProc proc" (push ebp, mov ebp,esp) starts at offset 26h the real address of the process is 401026h. The compiler compiles the DlgProc address to "push 401026h" (68 26 10 40 00) as parameter to API function DialogBoxParam.

Data is stored from address 403000h starting with Initialized data (.data) and after that Non-initialized data (.data?). So if hInstance is declared data under .data? the compiler compile hInstance with for example "40303ch" = placeholder in .data section i.e.

invoke GetModuleHandle, NULL

      mov hInstance,eax

as "mov 40303ch,eax" (A3 3C 30 40 00).

So you see the jump table is the smallest problem.

As I understand the whole no adjustmensts of ImageBase, and other data of headers will have any effect on running from memory because the compiler have it all set from the beginning. There are only two ways of solving this.
1. create a memory space with starting address = 400000h. (How do I do that?)
2. Scan the whole code and change every data addresses and label addresses. (Not realistic option)

Any comments?

How do I use CreateProcess? The function wants a null-terminated string that specifies the module to execute or a null-terminated string that specifies the command line to execute. Any other API suggestions? I don't know any.

I changed my code and made a scan in Dialog.exe code for addresses at the same time I changed the jump table.

JMPTABLE:	

	;API jmp table=====================================

	MOV edi,NtHeaders

	assume edi:ptr IMAGE_NT_HEADERS

	MOV esi,edi

	ADD esi,sizeof IMAGE_NT_HEADERS

	ADD esi,2*4

	MOV cx,word ptr [esi]

	AND ecx,0ffffh

	MOV eax,[edi].OptionalHeader.AddressOfEntryPoint

	ADD eax,pMem

	.while ecx!=0

		CMP word ptr [eax],0040h

		JNE @F

		MOV edx,dword ptr [eax-2]

		SUB edx,400000h

		ADD edx,pMem

		MOV dword ptr [eax-2],edx

@@:

		INC eax

		DEC ecx

	.endw

Now it reads and writes data to and from right position in data section. But it still don't work because the first lines in dialog.exe

	invoke GetModuleHandle, NULL

	mov    hInstance,eax

results in hInstance=400000h which is the handle of the exeres.exe. So my conclusion is that it is impossible to run a file from memory.

The PE loader topic should be moved into a separate thread, it isn't really what this was originally about.

Coding a PE loader is pretty damn simple. You load in the sections, apply relocations, fix up imports - and you're more or less done. However, you can't do it exactly like windows does (well, perhaps with some NT native API calls, I dunno). For instance you cannot create a new process address space without CreateProcess, you cannot make resources work, you cannot make the image appear in the internal process list, etc.

However, if you want to load "basic" PE files, it can be done. I'm doing this for my PE packer/crypter.

it matches the thread topic, but only because cmax's drugs are so much better than what I have available ;)

My packer is extremely beta - and will never be public. sorry.

vortex, my packer loads the original PE in a sort of traditional way, so no resource problems here; the PE-loading is done for my "level2 loader", so the main grunt of the decompression, obfuscation, etc can be written without the "delta trick" - hell, I can even (and I am) writing it in C.

What's the point then? Trash it.