You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This can actually be observed in cmd.exe.
With the current PEB structure I am reading 0 as the LDR address. After (copying and) inserting a dummy u32, to have padding, I read a potentially more correct LDR address.
EDIT: Sorry for the many title changes. I can't think straight rn. apparently.
The text was updated successfully, but these errors were encountered:
C0D3-M4513R
changed the title
Incorrect PEB64 type
Incorrect PEB type for x64
Apr 7, 2022
C0D3-M4513R
changed the title
Incorrect PEB type for x64
Incorrect PEB_LDR_DATA type for x64
Apr 7, 2022
C0D3-M4513R
changed the title
Incorrect PEB_LDR_DATA type for x64
Incorrect PEB type for x64
Apr 7, 2022
Mhmm. okay. It seems to make a difference if I create a cmd process from the process I read the peb, or if it gets created by something else.
If I create a cmd.exe and then try to read PEB, the ldr addr is always 0.
If the cmd is launched manually, and I try to read PEB, the ldr addr is set.
According to https://docs.microsoft.com/en-us/windows/win32/api/Winternl/ns-winternl-peb the peb for 64bit applications differ, from that of 32-bit applications.
There are 2 peb descriptions on that page. One on the top, and one on the bottom.
This can actually be observed in cmd.exe.
With the current PEB structure I am reading 0 as the LDR address. After (copying and) inserting a dummy u32, to have padding, I read a potentially more correct LDR address.
EDIT: Sorry for the many title changes. I can't think straight rn. apparently.
The text was updated successfully, but these errors were encountered: