Debugging WINLOGON.EXE at startup on Windows 10

Hello, I’m trying to debug winlogon.exe process at system startup. I read
some posts suggesting to use kernel debugger and ntsd (redirect ntsd I/O to
kernel debugger). So i set the “Debugger” registry key in under
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution
Options\Winlogon.exe to : ntsd -x -g -dand it seems to work OK. However, I
can see some strange behavior of winlogon.exe:When the system starts it
seems like winlogon terminates itself when running under ntsd and then the
system stucks. Does anyone have some good configuration in order to debug
winlogon at startup ?

Idan Freiberg
Mobile: +972-52-2925213

Sent with MailTrack
https:</https:>

This is how I’d do it:

  1. Create backup copy of Winlogon.exe
  2. Open Winlogon.exe in a binary editor (I suggest Hiew), go to the entry point
  3. Remember the byte at the entry point and replace it with 0xCC (int 3)
  4. Restart the system, boot with kernel debugger attached. Winlogon will stop at the entry point
  5. Using eb rip (orig_byte), restore the byte at the entry point
  6. Go debug on your own

L.

On Sun, Jan 03, 2016 at 04:08:56PM -0500, xxxxx@volny.cz wrote:

  1. Create backup copy of Winlogon.exe
    >2) Open Winlogon.exe in a binary editor (I suggest Hiew), go to the entry point
    >3) Remember the byte at the entry point and replace it with 0xCC (int 3)

How does one ‘know’ where the entry point is ?

-Alex

the entry point is standard field in pe header
open the file in any decent hexeditor / disassembler / pe file explorer
navigate to pe-header -. address of entry point
and hexedit a single byte in the address it points to (it is a
relative virtual address )

cdb -c “!dh winlogon.exe;q” -z c:\WINDOWS\system32\winlogon.exe | grep
-i add.*entry
3E5E1 address of entry point

cdb -c “u winlogon.exe+0x3e5e1 l5;q” -z
c:\WINDOWS\system32\winlogon.exe | grep -i reading -A 6
0:000> cdb: Reading initial command ‘u winlogon.exe+0x3e5e1 l5;q’
winlogon!__report_gsfailure+0xf8:
0103e5e1 9c pushfd
0103e5e2 60 pushad
0103e5e3 e836cefcff call winlogon!ActiveSessionsDlgProc+0x16 (0100b41e)
0103e5e8 61 popad
0103e5e9 9d popfd

C:\Documents and Settings\Admin>xxd -l 4 -g 4 -s 0x118
c:\WINDOWS\system32\winlogon.exe
0000118: e1e50300 …

xxd -l 1 -g 4 -s 0x3c c:\WINDOWS\system32\winlogon.exe
000003c: f0 //peheader .

set /a 0xf0+0x28 // peheader + optionalheader
280
xxd -l 4 -g 4 -s 280 c:\WINDOWS\system32\winlogon.exe
0000118: e1e50300 == 0x0003e5e1 …

On 1/4/16, Wilkinson, Alex wrote:
> On Sun, Jan 03, 2016 at 04:08:56PM -0500, xxxxx@volny.cz wrote:
>
>
> >1) Create backup copy of Winlogon.exe
> >2) Open Winlogon.exe in a binary editor (I suggest Hiew), go to the
> entry point
> >3) Remember the byte at the entry point and replace it with 0xCC (int
> 3)
>
> How does one ‘know’ where the entry point is ?
>
> -Alex
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
> drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:
></http:></http:>

btw in addition to this you may need to fix the checksum and or
subvert sfc to patch winlogon i think it has been a long time and
brain tends to rot over age

On 1/4/16, raj r wrote:
> the entry point is standard field in pe header
> open the file in any decent hexeditor / disassembler / pe file explorer
> navigate to pe-header -. address of entry point
> and hexedit a single byte in the address it points to (it is a
> relative virtual address )
>
>
> cdb -c “!dh winlogon.exe;q” -z c:\WINDOWS\system32\winlogon.exe | grep
> -i add.*entry
> 3E5E1 address of entry point
>
> cdb -c “u winlogon.exe+0x3e5e1 l5;q” -z
> c:\WINDOWS\system32\winlogon.exe | grep -i reading -A 6
> 0:000> cdb: Reading initial command ‘u winlogon.exe+0x3e5e1 l5;q’
> winlogon!__report_gsfailure+0xf8:
> 0103e5e1 9c pushfd
> 0103e5e2 60 pushad
> 0103e5e3 e836cefcff call winlogon!ActiveSessionsDlgProc+0x16
> (0100b41e)
> 0103e5e8 61 popad
> 0103e5e9 9d popfd
>
>
> C:\Documents and Settings\Admin>xxd -l 4 -g 4 -s 0x118
> c:\WINDOWS\system32\winlogon.exe
> 0000118: e1e50300 …
>
> xxd -l 1 -g 4 -s 0x3c c:\WINDOWS\system32\winlogon.exe
> 000003c: f0 //peheader .
>
> set /a 0xf0+0x28 // peheader + optionalheader
> 280
> xxd -l 4 -g 4 -s 280 c:\WINDOWS\system32\winlogon.exe
> 0000118: e1e50300 == 0x0003e5e1 …
>
>
>
>
> On 1/4/16, Wilkinson, Alex wrote:
>> On Sun, Jan 03, 2016 at 04:08:56PM -0500, xxxxx@volny.cz wrote:
>>
>>
>> >1) Create backup copy of Winlogon.exe
>> >2) Open Winlogon.exe in a binary editor (I suggest Hiew), go to the
>> entry point
>> >3) Remember the byte at the entry point and replace it with 0xCC
>> (int
>> 3)
>>
>> How does one ‘know’ where the entry point is ?
>>
>> -Alex
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software
>> drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http:
>>
></http:></http:>

> How does one ‘know’ where the entry point is ?

I do it in HIEW editor. Open an EXE, press F8, F5, you are at entry point.

btw in addition to this you may need to fix the checksum

HIEW can do this as well

As for subverting SFC in Vista+, resetting Winlogon.exe’s security descriptor (change owner -> change DACL) should be enough.

Obviously, don’t do this in your production machine, but in a test environment (e.g. VMWARE or testing PC), otherwise you are exposing yourself to Local Privilege Escalation attack. Also, having breakpoint in WINLOGON.EXE in your own working PC would cause your OS being unable to boot.

Hello,
Thank for your reply.

I must say you made me laugh :wink:

I’m pretty sure there must be some other, more straight way to do it.
But i’m gonna try your solution too.

If anyone knows a better way, i’ll be happy to hear.

Thanks.

Sent with MailTrack
https:

On Sun, Jan 3, 2016 at 11:08 PM, wrote:

> This is how I’d do it:
>
> 1) Create backup copy of Winlogon.exe
> 2) Open Winlogon.exe in a binary editor (I suggest Hiew), go to the entry
> point
> 3) Remember the byte at the entry point and replace it with 0xCC (int 3)
> 4) Restart the system, boot with kernel debugger attached. Winlogon will
> stop at the entry point
> 5) Using eb rip (orig_byte), restore the byte at the entry point
> 6) Go debug on your own
>
> L.
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>


Idan Freiberg
Mobile: +972-52-2925213</http:></https:>

> I’m pretty sure there must be some other, more straight way to do it.

Well, if we are talking about debugging anything that is involved in the Windows boot process, I would be surprised if there was. I am sure that MS people who work on it have something special, but I doubt that you can have access to it.

If anyone knows a better way, i’ll be happy to hear.

Likewise.

L.

Sent with MailTrack
https:

On Mon, Jan 4, 2016 at 1:28 PM, wrote:

> > I’m pretty sure there must be some other, more straight way to do it.
>
> Well, if we are talking about debugging anything that is involved in the
> Windows boot process, I would be surprised if there was. I am sure that MS
> people who work on it have something special, but I doubt that you can have
> access to it.
>
I saw couple of references online about debugging winlogon: (which didn’t
work for me)
http://blogs.msdn.com/b/gpalem/archive/2007/01/24/how-to-debug-winlogon-exe.aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/ff541428(v=vs.85).aspx
Thus, I think they meant that people (non-MS developers) will be able use
it.

> > If anyone knows a better way, i’ll be happy to hear.
>
> Likewise.
>
> L.
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>


Idan Freiberg
Mobile: +972-52-2925213</http:></https:>

Don’t use ntsd in this case. It is a limited way to debug the startup of user-mode processes. To debug the startup of user-mode processes when using the kernel-mode debugger you can use the following steps:

  1. bcdedit /set halbreakpoint on

x86

  1. ad /q ImageFileName; bp nt!PspInsertProcess “aS /ma ${/v:ImageFileName} @@c++(((nt!_EPROCESS *) @ecx)->ImageFileName); .block { .if ($spat("${ImageFileName}", "winlogon*")) { } .else { gc }}”; g
  2. .process /r /p @ecx; eb @$peb+2 1; g
  3. .reload /user; bu winlogon!WinMain; g

x64

  1. ad /q ImageFileName; bp nt!PspInsertProcess “aS /ma ${/v:ImageFileName} @@c++(((nt!_EPROCESS *) @rcx)->ImageFileName); .block { .if ($spat("${ImageFileName}", "winlogon*")) { } .else { gc }}”; g
  2. .process /r /p @rcx; eb @$peb+2 1; g
  3. .reload /user; bu winlogon!WinMain; g

Enjoy!

Andrey, thanks for that!
בתאריך יום ד׳, 6 בינו׳ 2016 ב-11:43 מאת Andrey Bazhan >:

> Don’t use ntsd in this case. It is a limited way to debug the startup of
> user-mode processes. To debug the startup of user-mode processes when using
> the kernel-mode debugger you can use the following steps:
>
> 1. bcdedit /set halbreakpoint on
>
> x86
>
> 2. ad /q ImageFileName; bp nt!PspInsertProcess “aS /ma ${/v:ImageFileName}
> @@c++(((nt!_EPROCESS ) @ecx)->ImageFileName); .block { .if
> ($spat("${ImageFileName}", "winlogon
")) { } .else { gc }}”; g
> 3. .process /r /p @ecx; eb @$peb+2 1; g
> 4. .reload /user; bu winlogon!WinMain; g
>
> x64
>
> 2. ad /q ImageFileName; bp nt!PspInsertProcess “aS /ma ${/v:ImageFileName}
> @@c++(((nt!_EPROCESS ) @rcx)->ImageFileName); .block { .if
> ($spat("${ImageFileName}", "winlogon
")) { } .else { gc }}”; g
> 3. .process /r /p @rcx; eb @$peb+2 1; g
> 4. .reload /user; bu winlogon!WinMain; g
>
> Enjoy!
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

You’re welcome! :slight_smile: