As of todays CVS Delphi 5 debugger is fixed.
Well, ok, there are still some bugs. One is a minor bug (Module view reports all modules as a project executable name), but all exports are there. You can even try to disassemble them. But here is where the major problems start. Debugger segfaults on that. This is because NtQueryVirtualMemory and NtProtectVirtualMemory currently don't work on other processes.
I have modified those functions to return STATUS_SUCCESS instead. This allows to access ntdll, kernel32 and possibly any other modules that have the same base address for application and debugger. You might need prelink installed to relocate ntdll and kernel32 to 0x7bxxxxxx addresses. This makes their base addresses the same for all wine apps.
Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others is not that simple. Basically there are no way to do it from other processes. Ok, NtQueryVirtualMemory could be implemented some-what easily using NtReadVirtualMemory and possibly one more server call. But for others I see only three ways to implement them: 1. Adding worker thread to each process. This way we can ask it to perform requested operation for us. But, there is a catch - this will complicate lots of things. Besides, messing with processes is not a good thing(tm). It will brake some apps, that don't expect to see more then one thread. Or if we'll try to hide a worker thread, it will make things even worse. 2. Using signal(s). Unfortunately this is not as simple to do ether. From what I been told, this will require non trivial synchronization, that still doesn't guarantee deadlocks. 3. Infamous wine kernel module. Some how I don't think that kernel guys will go for this type of functionality. Even for debugging proposes, it still poses considerable security risk allowing one process manipulate other process' memory. So it will have to be a wine only module, which means we'll have to maintain in against all supported kernel versions and require kernel development environment.
Any other solutions that I have forgotten/haven't even thought of?
On Tuesday 23 August 2005 20:05, Vitaliy Margolen wrote:
As of todays CVS Delphi 5 debugger is fixed.
Well, ok, there are still some bugs. One is a minor bug (Module view reports all modules as a project executable name), but all exports are there. You can even try to disassemble them. But here is where the major problems start. Debugger segfaults on that. This is because NtQueryVirtualMemory and NtProtectVirtualMemory currently don't work on other processes.
What are the problems with implementing those using SIGSTOP/SIGCONT and ptrace(2)? I imagine that for example changing memory protection for another process could be achieved as follows:
1. SIGSTOP to the process 2. inject code that invokes mprotect() and stops execution 3. change EIP, ESP, etc. then SIGCONT 4. wait(pid,&status,WUNTRACED) on the child 5. remove the injected code, restore registers, SIGCONT
I have never implemented such a beast so I might be way off, nevertheless it'd be interesting to hear what the problems are. phrack might also be a useful read in that respect.
Cheers, Kuba
Wednesday, August 24, 2005, 6:20:40 AM, Kuba Ober wrote:
On Tuesday 23 August 2005 20:05, Vitaliy Margolen wrote:
As of todays CVS Delphi 5 debugger is fixed.
Well, ok, there are still some bugs. One is a minor bug (Module view reports all modules as a project executable name), but all exports are there. You can even try to disassemble them. But here is where the major problems start. Debugger segfaults on that. This is because NtQueryVirtualMemory and NtProtectVirtualMemory currently don't work on other processes.
What are the problems with implementing those using SIGSTOP/SIGCONT and ptrace(2)? I imagine that for example changing memory protection for another process could be achieved as follows:
- SIGSTOP to the process
- inject code that invokes mprotect() and stops execution
- change EIP, ESP, etc. then SIGCONT
- wait(pid,&status,WUNTRACED) on the child
- remove the injected code, restore registers, SIGCONT
I have never implemented such a beast so I might be way off, nevertheless it'd be interesting to hear what the problems are. phrack might also be a useful read in that respect.
Hmm, that looks familiar. Something like that safedisc uses, that currently doesn't work. The only difference - safedisc limited to win API. I guess I can give it a try to see if it will work.
Vitaliy
Kuba Ober kuba@mareimbrium.org writes:
What are the problems with implementing those using SIGSTOP/SIGCONT and ptrace(2)?
The same problems that you'll have with signals, plus a few more <g>
Vitaliy Margolen wrote:
As of todays CVS Delphi 5 debugger is fixed.
.... Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others is not that simple. Basically there are no way to do it from other processes. Ok, NtQueryVirtualMemory could be implemented some-what easily using NtReadVirtualMemory and possibly one more server call. But for others I see only
How does gdb do these things to a Linux process? I would think a Debugger should have such services from the Linux Kernel. Is not the Delphi debugger a Debugger through the debug services Wine implements? (dbghelp and friends)
Free Life Boaz
Il giorno mar, 23-08-2005 alle 18:05 -0600, Vitaliy Margolen ha scritto: [snip]
Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others is not that simple. Basically there are no way to do it from other processes. Ok, NtQueryVirtualMemory could be implemented some-what easily using NtReadVirtualMemory and possibly one more server call. But for others I see only three ways to implement them:
[snip]
Any other solutions that I have forgotten/haven't even thought of?
have you checked this one?
http://www.die.net/doc/linux/man/man5/proc.5.html
especially with regards to mem e map.
it should work, at least on linux.
bye,
/pietrobo
Wednesday, August 24, 2005, 11:00:06 AM, Marco Pietrobono wrote:
Il giorno mar, 23-08-2005 alle 18:05 -0600, Vitaliy Margolen ha scritto: [snip]
Unfortunately fixing NtQueryVirtualMemory, NtProtectVirtualMemory and others is not that simple. Basically there are no way to do it from other processes. Ok, NtQueryVirtualMemory could be implemented some-what easily using NtReadVirtualMemory and possibly one more server call. But for others I see only three ways to implement them:
[snip]
Any other solutions that I have forgotten/haven't even thought of?
have you checked this one? http://www.die.net/doc/linux/man/man5/proc.5.html especially with regards to mem e map. it should work, at least on linux. bye,
Ok, and how would I allocate, free, change protection with that? Wine already has read/write access using ptread.
Vitaliy
-
Alexandre Julliard -
Boaz Harrosh -
Kuba Ober -
Marco Pietrobono -
Vitaliy Margolen