fix access to PEB on 64 bits binaries

[gogo2464]

I have a program that works perfectly when tested on 32 bits binaries but fails on 64 bits.

On the 64 bits binary, this part https://github.com/gogo2464/pwintools/blob/port_to_python3/pwintools.py#L562 fails and prints:

[*] ReadProcessMemory: [WinError 299] Seule une partie d’une requête ReadProcessMemory ou WriteProcessMemory a été effectuée.
[*] Process <Process "MYEXE.exe" pid 15236 (DEAD) at 0x15b6a2c00a0> not initialized ...

I think then this is an issue with PythonForWindows.

[hakril]

From the string <Process "MYEXE.exe" pid 15236 (DEAD) at 0x15b6a2c00a0> in your issue, it looks like the process you are trying to access is already dead. Are you sure that the process is still running ate the time you are trying to enumerate its modules ?

[gogo2464]

I am sure that the process is launched. The issue might be how I implemented the destructors of the classes:

https://github.com/gogo2464/pwintools/blob/port_to_python3/pwintools.py#L370

https://github.com/gogo2464/pwintools/blob/port_to_python3/pwintools.py#L576

I passed everything.

Did I do something wrong?

[hakril]

the (DEAD) string in the object representation comme from https://github.com/hakril/PythonForWindows/blob/master/windows/winobject/process.py#L1011. Which is itself based on the exit code of the process https://github.com/hakril/PythonForWindows/blob/master/windows/winobject/process.py#L53. You could print the __repr__ & exit_code of the process before & after parsing to be sure it is running. Is MYEXE part of the test binaries of pwintools ?

[gogo2464]

before:

<bound method WinProcess.__repr__ of <Process "MYEXE.exe" pid 20936 at 0x2e5010f00d0>>
False

after:

<bound method WinProcess.__repr__ of <Process "MYEXE.exe" pid 20936 (DEAD) at 0x2e5010f00d0>>
True

[hakril]

Well, it looks like the process is dying in between. Is MYEXE part of the test binaries of pwintools can it be generated / found somewhere for testing ? How long this process is supposed to live ?

[gogo2464]

coucou-printf.zip

[gogo2464]

Yes I just have uploaded my file. It is not generated. I compiled it from source. This is just an hello world.

[hakril]

This process is too short-lived to allow any parsing or interesting analysis during its execution without a debugger. As the following script show, if you use a debugger on this target to stop its execution, the parsing works fine.

import windows.debug

class MyDebugger(windows.debug.Debugger):
    def on_setup(self):
        target = self.current_process
        print("Current Debugge process is : {0}".format(target))
        print(" Modules:")
        for m in target.peb.modules:
            print(" - {0}".format(m))
        target.exit()

x = MyDebugger.debug(r"C:\Users\WDAGUtilityAccount\Desktop\coucou-printf\coucou-printf.exe")
x.loop()

Output is :

python3.exe tstdbg.py
Current Debugge process is : <WinProcess "coucou-printf.exe" pid 3620 at 0x26984207dd8>
 Modules:
 - <RemoteLoadedModule "coucou-printf.exe" at 0x26984235748>
 - <RemoteLoadedModule "ntdll.dll" at 0x269842357c8>
 - <RemoteLoadedModule "kernel32.dll" at 0x26984235348>
 - <RemoteLoadedModule "kernelbase.dll" at 0x26984235648>
 - <RemoteLoadedModule "msvcrt.dll" at 0x26984235848>

The parsing of remote PEB is one of the features I use the most and I am positive that whatever issue you are having here is not related to that. The most probable cause is the somewhat short liveness of your process compared to what you are trying to do with it.

[hakril]

Without news, I will guess it was related to the death of the process, thus not a bug. Feel free to reopen the issue if you have more information that it is indeed a bug.

[gogo2464]

@hakril I do not know if this is not a bug. Is there a way to launch a short process with no debugging?

I was very busy I forgot to keep in touch. Sorry.