Log in

View Full Version : piece of code i don't understand


simonzack
December 29th, 2009, 03:04
hi

I got this piece of code when reversing rorpacker:

PUSH 10
POP EAX
MOV EAX,DWORD PTR FS:[EAX+EAX*2]
MOV EAX,DWORD PTR DS:[EAX+C]
MOV EAX,DWORD PTR DS:[EAX+C]
MOV DWORD PTR DS:[EAX+20],3000
RETN

it points to Ldr.Reserved2[1]?

thanks

anom
December 29th, 2009, 07:35
It sets the process' ImageSize field in PEB to 0x3000 so that you won't dump everything (or too much, but usually common executables take up more space) if you use a dumper relying on these values. LordPE handles the case.

simonzack
December 29th, 2009, 07:50
I was thinking along the same lines
though where can i find the doc for that?
I looked in msdn and couldn't find anything

disavowed
December 30th, 2009, 22:52
Code:

PUSH 10
POP EAX

EAX = 0x10

Code:

MOV EAX,DWORD PTR FS:[EAX+EAX*2]

EAX = FS:[0x10 + 0x10*2] = FS:[0x30]
From http://en.wikipedia.org/wiki/Win32_Thread_Information_Block:
Quote:

FS:[0x30] - Linear address of Process Environment Block (PEB)

In other words, EAX now points to the PEB.

Code:

MOV EAX,DWORD PTR DS:[EAX+C]

From http://msdn.microsoft.com/en-us/library/aa813706(VS.85).aspx:
Code:

typedef struct _PEB {
BYTE Reserved1[2];
BYTE BeingDebugged;
BYTE Reserved2[1];
PVOID Reserved3[2];
PPEB_LDR_DATA Ldr;
...

So EAX now points to PEB_LDR_DATA Ldr.

Code:

MOV EAX,DWORD PTR DS:[EAX+C]

From http://native-nt-toolkit.googlecode.com/svn/trunk/ndk/ldrtypes.h:
Code:

typedef struct _PEB_LDR_DATA
{
ULONG Length;
BOOLEAN Initialized;
PVOID SsHandle;
LIST_ENTRY InLoadOrderModuleList;
...

So EAX now points to the first LDR_DATA_TABLE_ENTRY in the InLoadOrderModuleList.

Code:

MOV DWORD PTR DS:[EAX+20],3000

From http://native-nt-toolkit.googlecode.com/svn/trunk/ndk/ldrtypes.h:
Code:

typedef struct _LDR_DATA_TABLE_ENTRY
{
LIST_ENTRY InLoadOrderLinks;
LIST_ENTRY InMemoryOrderModuleList;
LIST_ENTRY InInitializationOrderModuleList;
PVOID DllBase;
PVOID EntryPoint;
ULONG SizeOfImage;
...

Each LIST_ENTRY is 8 bytes, so 0x20 in points to SizeOfImage, which is overwritten with 0x3000.

So to answer your question, yeah, there's no single good source for all the info, but you can piece it together with Wikipedia, MSDN, and the NDK

naides
December 31st, 2009, 06:54
Quote:
[Originally Posted by disavowed;84427][CODE]
So to answer your question, yeah, there's no single good source for all the info, but you can piece it together with Wikipedia, MSDN, and the NDK


And the master has talked. NOW there is a doc on the issue, authored by disavowed, hosted at:

http://www.woodmann.com/forum/showthread.php?p=84431#post84430 ("http://www.woodmann.com/forum/showthread.php?p=84431#post84430")

Indy
December 31st, 2009, 07:54
ntldr.h, ntpsapi.h, pebteb.h etc.

simonzack
January 4th, 2010, 03:37
thanks I never knew about the ndk

Indy
January 4th, 2010, 09:58
And I too.

LaBBa
January 5th, 2010, 09:26
i wonder..
Today all the dumping application can handle this ..
what could have been done by the protection code to make it harder to dump the process ? somthing that will require a patch to the protection so the dump will work ? somthing that is still related to the PEB..
and also which dumpers today would not been able to dump this type of protection that rorpacker used ?