One particularly annoying occurance that’s happened to me on a couple of occasions is losing the password to a long-forgotten test VM that I need to thaw for some reason or another, months from the last time I used it. (If you follow good password practices and use differing passwords for accounts, you might find yourself in this position.)<\/p>\n
Normally, you’re kind of sunk if you’re in this position, which is the whole idea – no administrator password is no administrative access to the box, right?<\/p>\n
The officially supported solution in this case, assuming you don’t have a password reset disk (does anyone actually use those?) is to reformat. Oh, what fun that is, especially if you just need to grab something off of a test system and be done with it in a few minutes.<\/p>\n
Well, with physical access (or the equivalent if the box is a VM), you can do a bit better with the kernel debugger. It’s a bit embarassing having to “hack” (and I use that term very loosely) into your own VM because you don’t remember which throwaway password you used 6 months ago, but it beats waiting around for a reformat (and in the case of a throwaway test VM, it’s probably not worth the effort anyway compared to cloning a new one, unless there was something important on the drive).<\/p>\n
(Note that as far as security models go, I don’t really think that this is a whole lot of a security risk. After all, to use the kernel debugger, you need physical access to the system, and if you have that much, you could always just use a boot CD, swap out hard drives, or a thousand other different things. This is just more convenient if you’ve got a serial cable and a second box with a serial port, say a laptop, and you just want to reset the password for an account on an existing install.)<\/p>\n
This is, however, perhaps an instructive reminder in how much access the kernel debugger gives you over a system – namely, the ability to do whatever you want, like bypass password authentication.<\/p>\n
The basic idea behind this trick is to use the debugger to disable the password cheeck used at interactive logon inside LSA.<\/p>\n
The first step is to locate the LSA process. The typical way to do this is to use the !process 0 0<\/em> command and look for a process name of LSASS.exe. The next step requires that we know the EPROCESS value for LSA, hence the enumeration. For instance:<\/p>\n Now that we’ve got the LSASS EPROCESS value, the next step is to switch to it as the active process. This is necessary as we’re going to need to set a conditional breakpoint in the context of LSA’s address space. For this task, we’ll use the .process \/p \/r eprocess-pointer<\/em> command, which changes the debugger’s process context and reloads user mode symbols.<\/p>\n Next, we set up a breakpoint on a particular internal LSA function that is used to determine whether a given password is accepted for a local account logon. The breakpoint changes the function to always return TRUE, such that all local account logons will succeed if they get to the point of a password check. After that, execution is resumed.<\/p>\n We can dissect this breakpoint to understand better just what it is doing:<\/p>\n Now, log on to the console. Make sure to use a local account and not a domain account, so the authentication is processed by the Msv1_0 package. Also, non-console logons might not run through the Msv1_0 package, and may not be affected. (For example, Network Level Authentication (NLA) for RDP in Vista\/Srv08 doesn’t seem to use Msv1_0, even for local accounts. The console will still allow you to log in, however.)<\/p>\n From there, you can simply reset the password for your account via the Computer Management console. Be warned that this will wipe out EFS keys and the like, however. To restore password checking to normal, either reboot the box without the kernel debugger, or use the bc*<\/em> command to disable the breakpoint you set.<\/p>\n\r\nkd> !process 0 0\r\n**** NT ACTIVE PROCESS DUMP ****\r\nPROCESS fffffa80006540d0\r\n SessionId: none Cid: 0004 Peb: 00000000\r\n ParentCid: 0000\r\n DirBase: 00124000 ObjectTable: fffff88000000080\r\n HandleCount: 545.\r\n Image: System\r\n[...]\r\nPROCESS fffffa8001a893a0<\/span>\r\n SessionId: 0 Cid: 025c Peb: 7fffffda000\r\n ParentCid: 01ec\r\n DirBase: 0cf3e000 ObjectTable: fffff88001b99d90\r\n HandleCount: 822.\r\n Image: lsass.exe<\/span>\r\n<\/pre>\n\r\nkd> .process \/p \/r fffffa8001a893a0\r\nImplicit process is now fffffa80`01a893a0\r\n.cache forcedecodeuser done\r\nLoading User Symbols\r\n.....\r\n<\/pre>\n
\r\nkd> ba e1 msv1_0!MsvpPasswordValidate\r\n \"g @$ra ; r @al = 1 ; g\"\r\nkd> g\r\n<\/pre>\n
\n
![turn on the kernel debugger from the “F8” boot menu<\/a> when booting the system, even if you don’t have kernel debugging enabled in the boot configuration or boot.ini. This will enable kernel debugging on the highest numbered COM port, at 19200bps. (On Windows Vista, this also seems capable of auto-selecting 1394 if your machine had a 1394 port, if memory serves. I don’t know offhand whether that translates to downlevel platforms, though.)<\/p>\n","protected":false},"excerpt":{"rendered":"One particularly annoying occurance that’s happened to me on a couple of occasions is losing the password to a long-forgotten test VM that I need to thaw for some reason or another, months from the last time I used it. (If you follow good password practices and use differing passwords for accounts, you might find […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,3,5],"tags":[],"_links":{"self":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/136"}],"collection":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=136"}],"version-history":[{"count":1,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/136\/revisions"}],"predecessor-version":[{"id":579,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/136\/revisions\/579"}],"wp:attachment":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=136"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=136"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=136"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}](\"http:\/\/www.nynaeve.net\/images\/bootmenu.png\"){kind=link}