Cmax,

It was me who started the PE Loader thing either because I misunderstood your question or didn't have all the facts. Anyway the thread has taken on a life of it's own and IMHO has become one of the more interesting ones in a while. It's nice to have a break from the endless GUI API questions and get down to something that involves the lower levels of Windows.
Posted on 2003-07-15 23:50:51 by donkey
Hey donkey ,

I deep into the string thing where you post how to cat one byte. I went way back there and having a ball.

Anyway, It would be more than cool to place roticv, Vortex and minor28 in a new thread as suggested. (same subject name or near is fine with me.) minor28 is on to something and it need no backlash.

Even tho my question was of track i hate to see people get confuse with 3 difference subject.
Posted on 2003-07-16 00:20:25 by cmax
One last thing donkey,

If possible please set hit count so people know what intrests has envoled since Vortex laid some laws down.

Posted on 2003-07-16 00:59:17 by cmax

One last thing donkey,

If possible please set hit count so people know what intrests has envoled since Vortex laid some laws down.
Wrong board cmax, I'm not a moderator here ;) I can't set or change anything
Posted on 2003-07-16 01:45:01 by donkey
comrade, "What's the point then? Trash it." - while my packer will never be public, files packed with it will. There's probably 2-3 files floating around the net at the moment packed with beta versions. Unfortunately, I don't currently have the time to work on it - but there's research & rewrite pending. Will be nice when I get the virtual machine stuff implemented.

cmax, nice to hear you stick to the good stuff, and sorry if I poked a bit fun of you - it was meant in a friendly way ^_^

minor28, unfortunately you cannot handle resources with the WriteProcessMemory method. For code and data, it should be OK though - if you either don't use imports, or remember to fix them up. Also, you must take care the code doing the overwriting+JMPing isn't overwritten by the overwrite ( ;) ), easiest way to handle this is to put it on the stack.
Posted on 2003-07-16 01:45:17 by f0dder
I don't mind moving to a new thread.

The jump problem is solved by this code:
PUSH nWritten

PUSH 4000h
PUSH lpBaseOfCode
PUSH 401000h
PUSH eax
PUSH 401000h ;push return address
JMP WriteProcessMemory


In the debugger I can see that the code from address 401000h is replayced. Thus WriteProcessMemory function works. The return from kernel32 ends at address 401000h. It starts to execute dialog.exe but the process ends. I will look into it later.
Posted on 2003-07-16 04:16:05 by minor28
So far all works. Exeres.exe overwrites its own hex code from IMAGE_DOS_SIGNATURE to the end with dialog.exe hex code. The code is overwritten by kernel function WriteProcessMemory. Return address from kernel function is EntryPoint of Dialog.exe. The execution continues with Dialog.exe code below.
start:

invoke GetModuleHandle, NULL
mov hInstance,eax
invoke DialogBoxParam, eax, ADDR DlgName,NULL,addr DlgProc,NULL
invoke ExitProcess,eax

DlgProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
.IF uMsg==WM_INITDIALOG

GetModuleHandle return value is 400000h. But DialogBoxParam retun value is -1. The function fails. I have debug the code in parallell to the original dialog.exe. The two executions are identical, as I can see it. The original succeeds and the other fails. Any suggestions? I attach the code.
Posted on 2003-07-16 11:39:30 by minor28
your problem is most likely caused by resources. The resource data will 99% of the time be located at another RVA than in your "Loader" executable. Overwriting the PE header in memory is _not_ enough to make windows use the new resource directory (well, it works in either 9x or NT, can't remember which - but since it's not universal, don't use it.)

Again, only very simple executables can be loaded your way. Even with more complicated loaders, there's a lot of restrictions on what you can do.
Posted on 2003-07-16 11:48:47 by f0dder
Hi fOdder

I have seen several threads on the board meantioning PE loaders as it was an easy task to do. The last one was this thread. It has never come longer than "you have to code your own PE loader" and how to manage the problems with the jump table. I couldn't understand why the jump table was so specific. I have no project to develop a PE loader (whatever that is). My contribution in this thread is an attempt to provoc the real proffesional coders to come up with something enlightening on PE loaders. I very well understand that if my "loader" would work it only will work with simple executables. I will not use it because I don't know what to use it for.
The resource data will 99% of the time be located at another RVA than in your "Loader" executable.

I have compared the loaded hexcode of real Dialog.exe and "my" Dialog.exe. As far as I have seen they are identical. I haven't looked that close but I will have a closer look at the resource section.

Regards
Posted on 2003-07-16 14:07:35 by minor28
Pseudocode. Only partial, as it's not possible to code a "real fully working" loader from win32 ring3 (well, haven't digged much into NT native API, but I still doubt it's possible.)

Create a filemapping of the PE. Verify MZ & PE signatures.

VirtualAlloc peheader.sizeofimage bytes of memory, preferably located at peheader.imagebase. If that address is already taken, you have to apply relocations. If relocation information has been stripped from image, abort.

Fix up imports (loadlibrary+getprocaddress loop, or your own code to do this if you want to be fancy and suffer potential compatibility errors).

There's a bunch of problems now, though. Resources - I know of no way you can "register" the new resource data with windows. Same with exports from the executable.

And of course, if you wanted to run the executable as a child process, that's a whole other can of worms.

I'm not going to post any code. My code is C++, and it's a PE->MyOwnFormat converter, not a PE loader as such. Also, it's rather specialized code for use with my packer.
Posted on 2003-07-16 14:21:21 by f0dder
Hi All

After a closer look I found resource memory space outside the process memory (400000h-405000h). As I can see, data from resource data section are copied to that space. In structure for resource I found two NumberOfIdEntries and two Offset To Data. First NumberOfIdEntries is the menu with offset to data = 4170h (i.e. 408170h) and the other is "MYDIALOG" with offset to data = 40C0h (i.e. 4080C0h). My try was to create memory spaces at these addresses and copy resource data. However the VirtualAlloc function fails. Here is the code concerning resource. It is inserted just before overwriting code.
;Get data for resource

MOV edi,NtHeaders
ADD edi,sizeof IMAGE_NT_HEADERS
.while nSections!=0
.if dword ptr [edi]=="rsr."
MOV lpResourceSection,edi
.else
ADD edi,28h
.endif
DEC nSections
.endw

assume edi:ptr IMAGE_SECTION_HEADER
PUSH [edi].VirtualAddress
POP lpVirtualAddress

MOV eax,[edi].PointerToRawData ;A00h
ADD eax,Base
assume eax:ptr IMAGE_RESOURCE_DIRECTORY
MOV cx,[eax].NumberOfIdEntries
AND ecx,0ffffh
PUSH ecx
.while ecx!=0
ADD eax,sizeof IMAGE_RESOURCE_DIRECTORY
DEC ecx
.endw
POP ecx
ADD eax,50h
.while ecx!=0
PUSH ecx
ADD eax,10h
assume eax:ptr IMAGE_RESOURCE_DATA_ENTRY
PUSH eax
PUSH [eax].Size1
;call for VirtualAlloc
PUSH PAGE_READWRITE
PUSH MEM_COMMIT
PUSH [eax].Size1
MOV edi,lpVirtualAddress
ADD edi,400000h
ADD edi,[eax].OffsetToData
PUSH edi
CALL VirtualAlloc ;This function fails
POP ecx
;copy code here

POP eax
POP ecx
DEC ecx
.endw

Any suggestions?
Pseudocode. Only partial, as it's not possible to code a "real fully working" loader from win32 ring3 (well, haven't digged much into NT native API, but I still doubt it's possible.)


fOdder, I am bound to agree with you that it is impossible. In fact I have already said it earlier. Is it so that futher talking about coding your own PE loader is talking nonsens????
Posted on 2003-07-17 09:10:12 by minor28
minor, I think you should forget about resources unless somebody has some breakthrough-ish knowledge. That doesn't mean PE loading is a nonsense thing, though - if you're working on OS development PE support is a nice thing. And the limited support you can easily get has been very useful for my packer project - I can use standard tools to write my level 2 code, and I don't have to worry about delta offsets for accessing variables etc.
Posted on 2003-07-17 10:15:02 by f0dder
Well f0dder, I will not forget about resources but I will skip the try to run the dialog.exe from memory.
Posted on 2003-07-17 16:26:43 by minor28