Help with PsGetCurrentProcess

[guga]

Hi guys

i´m trying to make a dump frm the debugger by running a process from memory. I found a c code that lead me to PsGetCurrentProcess from ntoskrnl. In masm it contains this PsGetCurrentProcess function, but if i try to call it directly it crashes the app.
Is there any working example of using this function (with or without using it as a sys file) ?

The C code i´m trying to port to asm is:

Code Select Expand



code removed because it contains references to hidding processes and injecting DLLs into other people's code and use of undocumented functions withe non ethical purposes


BestRegards,
Guga

[guga]

Btw: It seems that using a similar function as run process from memory is better then the ones i´m currently using on the debugger, because when using in memory, the loader mounts the PE file correctly with it´s sections  properly placed. I suceeded to make a full dump of a specific file from the debugger, and also i´m suceeding to make it dump and fix some packed files without too much efford. The problem is that some files after showed from memory have PointerToRawData in IMAGE_SECTION_HEADER set to zero, meaning that the file is being constructed on the virtual section of the PE. (LIke UPX does). I succeded to dump such cases, but i´m having dificulties in rebuilding the sections properly in order to fix the IAT/EAT/resource tables etc.
Since winows loader seems to build and fix the file and ´t´s sections restoring them internally to the way as it is if the file were not packed, it seems to me that loading the file from a process directly from memory should fix this kind problems, allowing me to dump the file correctly.

[qWord]

Your code is obviously part of a driver that hide processes!
:boohoo:

[guga]

HI qword

yes...it seems it is, but i wonder if for dumping any file from the debugger it won´t be better doing it from memory after it is loaded inside the debugger. I mean when i 1st try to dump any file is uses his PID to query information to memory using VirtualQueryEx. Then it reads this memory (ReadProcessMemory) and copy the founded data to a buffer.

Then i analyse the sections, dos header and make a couple of fixes to dump the loaded module to disk. For unpacked files, the process is OK, and also for some packed PEs whose PointerToRawData is not zero (i´m almost fixing all of this cases, simply finding some gaps in the data directory table - Works for PECOmpact so far)...The problem is when PointerToRawData is set to zero and the original sections are ruined.

On the cases the loader uses the virtual memory to build/run the module, i wonder if i run the file directly from memory won´t rebuild the section header and data directory table more properly.

[hutch--]

Guga,

Its bveen a long time since I have touched this stuff but from memory reconstructing a PE file from a compressed EXE using tools like UPX is always going to be difficult and would probably need to be dedicated to the specific exe compressor used. Over time various compressors have used different techniques to lay out the PE sections which they construct from the compressed data and it is rarely ever standard. For your debugger I would be inclined to keep it for uncompressed exe's only as they are at least predictable.

[guga]

Hi Steve

What do you mean with predictable ? Making the debugger shows a message whenever teh user tries to dump a packed module ? If  it is, this seems to be not that hard. I found 2 ways of doing this so far. One when the PointerToRawData is zero and other when the EXPORT or IMPORT directory table points to a virtual section. Also, i can implement a entropy check.
But, for such cases the windows loader runs the file from memory, and get the IAT/EAT etc, following the data/functions in the entrypoint of the packed PE (That in memory is not packed any more). The problem is when i try to dump and fix such cases, i understood how to get the "good" functions (when the loader reaches the eip and find the dumped codes), but..the IAT/EAT, etc, even if it is fully in the memory segments, i cannot be able to automatically fiind their addresses in order to properly rebuild the pe header.  For example,  once a upx packed file is running from memory, the debugger shows their contents and i can dump it completelly...But...since it is running in memory (From a file that was hosted), the debugger shows properly their segments separated each 01000 bytes that represents (or seems to represent) the original sections of the PE. The dificult is in identifying wich segment belongs to the proper data table.
If i succeded to dump and fix for non zero raw data. I keep wondering if it won´t also work if i simply reloaded the same modeule directly frm memory on another thread/process for example. Windows loader seems to rebuild automatically teh pe header for non zer cases.
The question is.. do win loader also rebuilds it from another process in memory that was derivated from itself ? (Like a debugging a modeul and then debugging it again but, now not from file, but from the debugged memory)

[qWord]

I still wonder what HideProcess() has to do with debugging. There is no legitimate reason to hide a process, even for debugging!

[guga]

I found this code while searching for a function that was able to run a process from memory. If you know another way (or function) that does this, please let me know.

[qWord]

I found this code while searching for a function that was able to run a process from memory. If you know another way (or function) that does this, please let me know.

Loading and running EXEs and DLLs from memory

unbelievable, but it seems like that Vortex doesn't need to manipulate the system's process list for loading a PE from memory  :wink

[guga]

Many thanks..i`ll give it a try.

Best Regards,

guga

[guga]

Hello guys

i saw the function...but..i don´t think it will work for unpacked memory. The call to LoadLibrary needs that the IAT at the data directory table be correct. And on unpacked files, this value does not points to the original IAT, but to the one related to another segement of the packer routines.

What is neeed is to create another process using createprocess allowing windows to do the job and find the correct IAT (With all imported functions and not only the ones related to the packer).

Maybe this can be usefull ? What do you guys think ?
... link removed because it contains a lot of material that is not allowed on this forums

[BogdanOntanu]

Hello guys

i saw the function...but..i don´t think it will work for unpacked memory. The call to LoadLibrary needs that the IAT at the data directory table be correct. And on unpacked files, this value does not points to the original IAT, but to the one related to another segement of the packer routines.

What is neeed is to create another process using createprocess allowing windows to do the job and find the correct IAT (With all imported functions and not only the ones related to the packer).

Maybe this can be usefull ? What do you guys think ?
... link removed because it contains a lot of material that is not allowed on this forums

Guga,

Please observe the rules of those forums. Reversing, hideing processes from enumeration, injecting your DLL into other's people executable (games) is not tolerated here.

Please DO NOT hide yourself behind "debugger" and other fuzzy unclear explanations and please do restrict yourself from copy paste of non ethical code or links on those forums.

There are many many other forums that deal with such stuff... we do not want this kind of dirt in here :D

Now...  please do explain me what exactly do you want to obtain with this "research" of yours and what is the legitimate purpose of that?

[guga]

Hi Bogdan

Reversing what ? The code was not intended to hide process or injecting dlls etc etc....I was trying to make a fix for the module dumper for rosasm debugger.
Not sure if you remember me...but i´m Beyond2000! and currently restarted upgrading RosAsm project.

I have no idea what weird material may contain on the code/links i provided, since i was trying to understand the way windows loader works internally to fix a module that is being debugged with rosasm. The link i was interested only on that code and didn´t botter to look what was inside the website.  Sorry, but i was concentrated in fix RosAsm´s debugger and didn´t payed attention on the contents of the site. I google it searching for "load a file from memory" or something like that and found that site.

The debugger works fine when the module is loaded as a file, but i was having troubles to fix the iat when a user chooses to dump the module to disk or pass it through RosAsm´s disassembler (I plan to allow the user save a file that was on the debugger list and pass it from the disassembler or simply save the fixed file to disk).  This is why i was asking about a way to analyse the module when it is already loaded on memory . When you debug a file with rosasm a list containing the main executable and it´s dlls dependencies is shownd. Now it have the hability to dump that module to disk.

Sorry for the rules of the forum, but i have no idea and no intention to break any ruyles or make any app related to injected code or whatever illegal activities. All i was analysing is a way to load a module directly from memory instead of from a file.
But..no problem...i´m quite finished fixing it without the needs of loading the module from it´s copy that was loaded in memory on another process. All that was needed was analyse inconsistences on the section header of the module to see if it is or not packed in order to the user saves it to disk properly (when i say properly i mean fixed).

I hope i´m being able to make my self clear on this. What i was testing was a dll i made for vdub. When rosasm disassemble (and debug) or ropen a dll it opens a dialog allowing the user to choose the host application related to to that dll, and then the module and the app is debugged properly. The problem i was facing was that after loading the host (vdub) it loaded it´s dependencies and one of them was packed (divx.dll i think), and hwhen i saved that dll to disk the dll crashed badly. (Not only that. Even my vdub dll was crashing after loading vdub as it´s host)

What I also found is that rosasm have a small bug in one of the macros (c_call) that was causing a stack error. After fixing that, I analysed the dumped (saved) dll and saw that it was broken internally....That´s why I made the fix. (well...i´m trying to fix it)

Best Regards,

guga

[BogdanOntanu]

Hi Bogdan

Hi,

Reversing what ?

An application (packed or protected) that is loaded in debugger and then dumped to the disk and/or reassembled with RosASM for example.

The code was not intended to hide process or injecting dlls etc etc....

I can not know what was your real intention since I can not read minds (usually).

I consequence I simply look at what people post on the forums. Your post contained clear references to HdeProcess, InjectDll, and other such clear "intentions".

I was trying to make a fix for the module dumper for rosasm debugger.

If this is true then please do take the time an explain exactly (conceptually) what you want to achieve and try to create an simple working example (in MASM)  with your problem and then maybe people here will give you great hints or ideas about how to solve your problem.

But please do restrain yourself from posting what you find on dubious sites here. This can harm the forums because the site can be disabled or marked if such references are fund. All people would loose in this case.

Not sure if you remember me...but i´m Beyond2000! and currently restarted upgrading RosAsm project.

Sorry but I do not think that  people's names or internet nicknames are relevant.  I only check what people post here.

I have no idea what weird material may contain on the code/links i provided,

Please take the time needed to filter the material you refer to and/or post here. It is only fair to do so if you want other people to use their time and read it an analyze it and answer your questions.

"I have no idea / I do not know" is not a valid answer.

since i was trying to understand the way windows loader works internally to fix a module that is being debugged with rosasm.

The windows loader is undocumented at best. You would have to reverse it in order to understand how it works :D.

And it's inner workings change or can change with each Windows update.

In your case this loader has nothing that can help you fix and dump an unpacked or protected exe.

The loader ONLY LOADS standard files. The unpacking and additional Imports fixing are done by the packer/protector. While they do this most protectors also erase the Imports information EXACTLY in order to make rebuilding and dumping to disk to a valid executable HARD for beginners.

If instead of posting wrong code and wrong links you would have simply asked a fair question about this THEN many people here could have answered fast .... but of course they would also express concerns about the purpose of your questions.

And again I must also say that there are a LOT of other sites that provide tutorials and explanations exactly about how to perform those kind of actions.

The link i was interested only on that code and didn´t botter to look what was inside the website.

Next time please do bother to look.

  Sorry, but i was concentrated in fix RosAsm´s debugger and didn´t payed attention on the contents of the site. I google it searching for "load a file from memory" or something like that and found that site.

Apologies accepted.

The debugger works fine when the module is loaded as a file, but i was having troubles to fix the iat when a user chooses to dump the module to disk or pass it through RosAsm´s disassembler

This is expected when the IAT is manipulated by a packer or protector. A debugger is NOT expected to dump the file to disk. If it does this the it opens a can of worms.

Visual studio debugger does not, WinDbg does not, GDBG does not IMHO so why would RosASM do it?

(I plan to allow the user save a file that was on the debugger list and pass it from the disassembler or simply save the fixed file to disk).

And why do you want to have a working disassembled file ... ready to be reassembled by RosASM? This way you could make each program "your own" :D

  This is why i was asking about a way to analyse the module when it is already loaded on memory . When you debug a file with rosasm a list containing the main executable and it´s dlls dependencies is shownd. Now it have the hability to dump that module to disk.

Why would anybody want to do this?

Sorry for the rules of the forum, but i have no idea and no intention to break any ruyles or make any app related to injected code or whatever illegal activities. All i was analysing is a way to load a module directly from memory instead of from a file.

There is no way to do this. At least not a way that works every time. Not without breaking some rules. And I fail to see why your would need to do this in the context of an legitimate debugger when you have the sources fro your application available.

IF you do not have the sources then it is called "reversing" and it might be legitimate BUT it is beyond the rules of this forums ;)

I do see why you would want to do this in the context of reversing or cracking :D

But..no problem...i´m quite finished fixing it without the needs of loading the module from it´s copy that was loaded in memory on another process. All that was needed was analyse inconsistences on the section header of the module to see if it is or not packed in order to the user saves it to disk properly (when i say properly i mean fixed).

I work in this area every day ;) So let me express my doubts about it ... or at least about "working every time" aspect of it ;)

I hope i´m being able to make my self clear on this.

NO you are not clear at all. Once you want something then something slightly different then again something else...

All issues are apparently related to a debugger ... I see... but still very unclear. And I also think that you search in the wrong places and consider the wrong options and concepts for the task at hand ;)

What i was testing was a dll i made for vdub. When rosasm disassemble (and debug) or open a dll it opens a dialog allowing the user to choose the host application related to to that dll, and then the module and the app is debugged properly.

The normal way is to place a breakpoint in DllMain of your DLL if you have the sources.

Another normal way it to debug your application and trace the DLL loading if dynamic or place a persistent breakpoint and restart your application in debugger.

The problem i was facing was that after loading the host (vdub) it loaded it´s dependencies and one of them was packed (divx.dll i think), and hwhen i saved that dll to disk the dll crashed badly. (Not only that. Even my vdub dll was crashing after loading vdub as it´s host)

You are not supposed to do that. ;)

What I also found is that rosasm have a small bug in one of the macros (c_call) that was causing a stack error. After fixing that, I analysed the dumped (saved) dll and saw that it was broken internally....That´s why I made the fix. (well...i´m trying to fix it)

Best Regards,

guga

I still think that you are doing this the wrong way ...

Best regards ;)