The API call used is ReadProcessMemory - according to MSDN: "Before any data transfer occurs, the system verifies that all data in the base address and memory of the specified size is accessible for read access. If this is the case, the function proceeds; otherwise, the function fails." In this situation, the function fails. It may well be possible to get around this (probably producing access violations in the process) some other way; attaching a debugger (such as MSVC) to the winlogon process does not work - it is unable to read the first 64k bytes of memory, but is quite happy to disassemble the code (probably because it uses the same API call). Also, when you stop debugging, you will terminate winlogon, and hence kill NT. As far as allowing the process to be debugged goes, all aministrators are by default granted SeDebugPrivilege, which allows them to debug practically anything - including winlogon, afaik. Alternatively, it may be possible to recover the memory space from either a Windows 2000 hiberfil.sys, or Windows NT's memory.dmp after a bluescreen; possible even the actual pagefile. In fact, if the passwords are stored in plaintext, it should be possible by any number of means. -- Chris Paget C++ Developer - NetInvest LTD. chris.pagetat_private On Wed, 08 Dec 1999 17:38:18 -0500, you wrote: >When you say the first 10,000 bytes are not accessable, do you mean that is >valid memory, probobly where the passwords are stored, but the system has >been hard coded to deny access to it using the debug apis? What if you set >the global flag to enable debugging of winlogon? Or did you have to do >that already?
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:19:23 PDT