WaxfordSqueers wrote:Kayaker might know, he's familiar with the inner working of SI.
Someone offered me an interesting way to examine drivers today. He suggested using Dependency Walker. Load the driver in question in a new directory and copy all the drivers from the windows driver directory into the same directory. I suggested moving the files from system32 into that directory as well. Run DW in that directory and load the driver in question and DW should give you all the imports that are missing.
I have not tried it yet but it sounds interesting. With regard to directdraw, I did a crackme by Silver that involved a DirectX app running a spinning cube in a full screen window. The mouse in the DX window is not the same mouse used in Windows, DX supplies it's own mouse and driver. So you can't use any screen mouse functions to bring it up in SI.
To solve it, I trapped the windows mouse using a hwnd related to LButtonDown then traced the mouse right through ring 0 with SI till it reached the code where the DX mouse was activated. Meantime, I traced from the OEP to just after ShowWindow, where the DX initialization code began. Inside that initialization code was a table where the fullscreen/window mode bit could be toggled, so I was able to turn off full screen and get the DX window in it's own window.
Don't know if DirectDraw can be reached the same way. With the DX crackme, there were video frame buffers that could be accessed.
Don't know if you could do that with windbg. Blabberer would know but he gets hives when you talk about softice.
I have encountered those problems but can't remember how I solved them. Normally I let it run in VGA mode and it was happy.
Since I am working in real windows mode with XP I need a debugger that will trace through ring 0 in real mode, not virtual mode. It is still not clear to me whether windbg will enter ring 0. Blabberer has kindly tried to explain it to me but whenever I try to get past a sysenter call to the system windbg kicks me out the other end without allowing me to trace the code.
I now have remote debugging with real mode/kernel mode capability in W7 and W10 via a serial connection. I have read an article on github wherein someone claims to be able to debug remotely with XP, using windbg.
Ideally, I should be able to start SI in the target and watch it initialize. That is, if SI is not doing something to interfere with windbg operation.
the mouse in windows is read out via i/o in the i8042prt.sys (same goes for the keyboard)
at some point it reaches win32k.sys where it calls a mousemove function in the keservicedescriptortableshadow
this function has a global var flag (since some patch) if the mouse was from i/o or from a classical kernel32.dll function like sendinputa,mouse_event,keybd_event
i once looked how this is done but the most of these functions are converted and then lead up to this function what is then transfered to an application
if this information is not taken that way you have to make the i/o
i did this view, look how close i got to the softice look:
i coded a own softice that is functional but it has to many of bugs and actually only runs in vmware (never worked further)
the dependency walker its been years since i heared about this 1
well yea if its the direct draw api from ring0 , or maybe some super weird ntgdi drawing
we probaly would see the import
i/o would be possible for softice it has functions realted to this but those could be used for like anything realted to i/o even the harddrive
the thing here is tho that softice can use a different method to make this happen without a such import
for example it could search the dxg.sys and call its function via a IRP , or the functions over the driver object , softice has the IoCallDriver function
a other way would be to reconstruct the softice functions and emulate them on your driver but that is really big work special because softice has the biggest of its routines there
blabbarer doesnt like me? i dont know why
you right windbg might be "the one debugger" but close to ollydbg a lot parts are emulated , or limited to the application you are debugging
its not a "classical ring0 debugger" where the operations are pure ring0 the entire window is in ring3 and it also use classical debug functions
thats not what i personally want
what i want would be a virtual machine based softice as close it was in 98 thats why you could break on the IDT instruction for example (kinda useful)
the keyboard should be read manually (mouse is not neccesary needed for me), video buffer should be directly written to not over windows functions
on ntice the vm based part is already gone but at least it has keeped the most other stuff
the video problem could be found if we have a vmbased debugger before softice and having this video problem (in vmware the video problem does not apear, but at least
i could look into the process how it is being done and the problem might be found)
i might would still do this even today
you debugging winxp before it goes into the protected mode ? or from that emulated dos cmd.exe ? i didnt understand that part
