{"componentChunkName":"component---src-templates-post-template-js","path":"/magical-windbg-vol2-04-en","result":{"data":{"markdownRemark":{"id":"44e3410d-415a-5963-8929-86001cfd356c","html":"
\n

This page has been machine-translated from the original page.

\n
\n

In this chapter, we dynamically analyze DoPClient’s checkPassword function with WinDbg to identify the first Flag.

\n

Dynamic analysis is a technique that analyzes a program based on its behavior when it actually runs, along with information such as memory and registers.

\n

This includes not only suspending program execution with a debugger such as WinDbg and analyzing it while inspecting (or modifying) memory and registers, but also collecting process monitor logs or network traces while the program is running.

\n

In this book, we primarily use WinDbg for analysis.

\n\n

Table of Contents

\n\n

Run the Program in WinDbg and Set Breakpoints

\n

Generally, when debugging a user-mode program with a debugger such as WinDbg, you either run the program under the debugger or attach the debugger to a process that is already running.

\n

This time, we will analyze it by running the program under the debugger.

\n

After launching WinDbg in the virtual machine where you placed DoPClient.exe, click [File] > [Start Debugging], then click [Launch executable(advanced)].

\n

In the [Executable] field, specify the path to DoPClient.exe placed in the virtual machine.

\n

Also, specify the program’s working folder in [Start Directory].

\n

For identifying the first Flag this time, setting [Start Directory] is not necessary, but depending on how the target program is implemented, you may need to set [Start Directory] properly to the program’s working folder.

\n

\n \n \n \n \n \n \n \n \n

\n

After making the above settings, leave [Record with Time Travel Debugging] unchecked and click the [Debug] button. The program starts, and the debugger attaches to it.

\n

Time Travel Debugging (TTD) 1 is a powerful feature that captures a trace of process execution so that you can freely inspect register and memory state during execution, but we do not use it in this book.

\n

When a user-mode application is started by the debugger, execution is paused while processing is still inside the image loader (Ldr) in ntdll.dll, which is a user-mode system DLL, and the debugger attaches at that point.2

\n

At this point, the code implemented inside the program’s main function has not yet run.

\n

\n \n \n \n \n \n \n \n \n

\n

Before resuming program execution, set a breakpoint at the call site of the checkPassword function used for password validation that we examined in Chapter 3.

\n
14000198b  lea     rcx, [rsp+0x40 {inputText}]\n140001990  call    checkPassword
\n

When using WinDbg, breakpoints can be set in various ways 3, but this time we will simply use the bp command to set a breakpoint at the specified address.

\n

Most Windows programs are relocated at runtime, so the virtual address (VA) that can be specified when setting a breakpoint with the bp command changes each time.

\n

Therefore, when setting a breakpoint, it is more convenient not to specify the virtual address directly, but instead to specify the executable’s image base address plus the relative virtual address (RVA).

\n

For example, if you want to set a breakpoint at the address shown as 0x140001990 in Binary Ninja with default settings, specify the program’s image base address, accessible as DoPClient (or !DoPClient), plus the relative virtual address 0x1990, as shown below.

\n
bp DoPClient+0x1990
\n

After setting the breakpoint with the command above and resuming execution with g, DoPClient displays the screen asking the user to enter a password.

\n

Then, as confirmed in Chapter 3, if you enter a 45-character string such as AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA and press Enter, execution stops again at the address DoPClient+0x1990, and you can confirm that debugger control is possible.

\n

\n \n \n \n \n \n \n \n \n

\n

The code below extracts only the structural portions from that decompiled output.

\n
int64_t checkPassword(char* arg1)\n\n{\n    void var_f8;\n    int64_t rax_1 = (__security_cookie ^ &var_f8);\n    char* r10 = arg1;\n    int64_t rax_2 = -1;\n    do\n    {\n        rax_2 = (rax_2 + 1);\n    } while (arg1[rax_2] != 0);\n    int32_t rcx = 0;\n    if (rax_2 != 0x2d)\n    {\n        exit(0);\n        /* no return */\n    }\n\n    int32_t i = 0;\n    int128_t var_d8;\n    int32_t* r11 = &var_d8;\n    do\n    {\n        uint64_t rdx_1 = ((uint64_t)((int32_t)*(uint8_t*)r10));\n        if (i > 0x16)\n        {\n            if (i > 0x22)\n            {\n                if (i == 0x29)\n                {\n                    rcx = ((int32_t)(rdx_1 + 0x5f6));\n                }\n                else if (i == 0x2a)\n                {\n                    rcx = ((rdx_1 * 0x21) + 0x23);\n                }\n                /* omitted */\n                switch (i)\n                {\n                    case 0x23:\n                    {\n                        rcx = ((rdx_1 * 0x35) + 0xdab8);\n                        break;\n                    }\n                    /* omitted */\n                }\n            }\n            /* omitted */\n        }\n\n        /* omitted */\n\n        __builtin_memcpy(&var_d8, \"<hardcoded byte sequence>\", 0xb4);\n\n        if (rcx != *(uint32_t*)r11)\n        {\n            printf(\"Password is Wrong\\n\", rdx_1);\n            exit(0);\n        }\n\n        i = (i + 1);\n        r10 = &r10[1];\n        r11 = &r11[1];\n    } while (i < 0x2d);\n    __security_check_cookie((rax_1 ^ &var_f8));\n    return 0;\n}
\n

You can see that the following code executed from 0x14000138a to 0x140001392 is almost the same as the string-length verification code examined in Chapter 3.

\n
char* r10 = arg1;\nint64_t rax_2 = -1;\ndo\n{\n    rax_2 = (rax_2 + 1);\n} while (arg1[rax_2] != 0);\n\nint32_t rcx = 0;\nif (rax_2 != 0x2d)\n{\n    exit(0);\n}
\n

The checkPassword function receives, as its first argument (arg1), a pointer to the input string stored on the stack.

\n

After obtaining the length of this string in a loop, it checks again that the string length is 45 (0x2d) characters.

\n

Once the string-length check is passed, you can see that a loop containing complex conditional branches is implemented between 0x14000139b and 0x1400017dd.

\n
int32_t i = 0;\nint128_t var_d8;\nint32_t* r11 = &var_d8;\ndo\n{\n    uint64_t rdx_1 = ((uint64_t)((int32_t)*(uint8_t*)r10));\n    if (i > 0x16)\n    {\n        if (i > 0x22)\n        {\n            if (i == 0x29)\n            {\n                rcx = ((int32_t)(rdx_1 + 0x5f6));\n            }\n            /* omitted */\n        }\n        /* omitted */\n    }\n    /* omitted */\n\n    __builtin_memcpy(&var_d8, \"<hardcoded byte sequence>\", 0xb4);\n    if (rcx != *(uint32_t*)r11)\n    {\n        printf(\"Password is Wrong\\n\", rdx_1);\n        exit(0);\n    }\n\n    i = (i + 1);\n    r10 = &r10[1];\n    r11 = &r11[1];\n\n} while (i < 0x2d);
\n

If you look closely at this loop implementation, you can see that in each of the 45 (0x2d) iterations, something is validated by the code if (rcx != *(uint32_t*)r11), and if it does not match, the string Password is Wrong is printed.

\n

Also, the RCX register being compared here seems to hold a transformed value of rdx_1, based on lines such as rcx = ((int32_t)(rdx_1 + 0x5f6));.

\n

On the line uint64_t rdx_1 = ((uint64_t)((int32_t)*(uint8_t*)r10)), rdx_1 receives one character from the input string per loop iteration.

\n

Also, r11 holds int32 integer values taken in order from the hardcoded byte sequence var_d8.

\n

In other words, it seems reasonable to infer that checkPassword takes the input string from the beginning inside the loop, performs some calculation after passing through complex branching, checks whether the result matches the hardcoded byte sequence, and returns 0 only when validation succeeds for all characters.

\n

Dynamically Analyze the checkPassword Function

\n

Now, let’s use the debugger to verify whether the above hypothesis is actually correct.

\n

First, run the following commands in the Command window in order.

\n
.restart\nbp !DoPClient+0x13a2 ; bp !DoPClient+0x17ca ; g
\n

Running the .restart command restarts the target program being debugged and also resets settings such as breakpoints.

\n

Then, bp !DoPClient+0x13a2 ; bp !DoPClient+0x17ca ; g sets two breakpoints in a one-liner and resumes program execution.

\n

In this way, WinDbg lets you execute multiple commands together by chaining them with semicolons (;).

\n

In the command above, breakpoints are set at two locations: the code that extracts one character from the input inside the loop, and the code that compares the result of some calculation on the input character with a hardcoded integer value.

\n

When you run the program and enter 45 A(0x41) characters, execution first pauses immediately before the code movsx edx,byte ptr [r10], which extracts one character from the input string.

\n

At this point, the EDX register contains the value 0x7cc0f490, not the input character.

\n
0:000> g\nBreakpoint 0 hit\nDoPClient+0x13a2:\n00007ff6`dd0913a2 410fbe12  movsx   edx,byte ptr [r10] ds:000000bd`b9cffc80=41\n\n0:000> r edx\nedx=7cc0f490
\n

If you step the program with the p command here, you can confirm that the first character A(0x41) is loaded into EDX from the address stored in r10.

\n
0:000> p\nDoPClient+0x13a6:\n00007ff6`dd0913a6 4183f816        cmp     r8d,16h\n\n0:000> r edx\nedx=41
\n

Next, if you resume program execution once more with the g command, execution pauses at the second breakpoint, DoPClient+0x17ca.

\n
0:000> g\nBreakpoint 1 hit\nDoPClient+0x17ca:\n00007ff6`dd0917ca 413b0b          cmp     ecx,dword ptr [r11] ds:00000055`a5effc90=000021a7
\n

At this point, the ECX register contains the integer value 2076, but the pointer address referenced by the R11 register, which is the comparison target, contains the integer value 8615.

\n
0:000> r ecx\necx=2076\n\n0:000> dd r11 L1 ; ? $p\n00000055`a5effc90  000021a7\nEvaluate expression: 8615 = 00000000`000021a7
\n

Therefore, when the first input character is A(0x41), validation by the code if (rcx != *(uint32_t*)r11) fails, and the program exits after outputting Password is Wrong.

\n

By the way, the command dd r11 L1 ; ? $p used here relies on WinDbg pseudo-registers 10.

\n

A pseudo-register is a value used to hold specific data inside the debugger.

\n

And the pseudo-register $p stores the value output by the most recent Display Memory command.

\n

Therefore, by evaluating ? $p after running dd r11 L1, the DWORD-sized value pointed to by the R11 register can be output as the decimal integer 8615 instead of 0x21a7.

\n

This kind of syntax using pseudo-registers is useful to remember, because it can be applied when writing one-liner commands or scripts.

\n

Analyze the Behavior When Entering the Correct String

\n

Although a breakpoint was set at the location that appears to validate password characters, when AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA was used as the input string, the validation could not be passed.

\n

So next, let’s run the program again using the 45-character string FLAG{ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklm}, which satisfies the correct Flag format, as the input value.

\n

Then, at the code for the first breakpoint (movsx edx,byte ptr [r10]), the value stored in the EDX register changes from A(0x41) to F(0x46).

\n
0:000> g\nBreakpoint 0 hit\nDoPClient+0x13a2:\n00007ff6`dd0913a2 410fbe12        movsx   edx,byte ptr [r10] ds:0000001a`ed4ffaf0=46\n\n0:000> p\nDoPClient+0x13a6:\n00007ff6`dd0913a6 4183f816        cmp     r8d,16h\n\n0:000> r edx\nedx=46
\n

And at the line configured as the second breakpoint, the value of the ECX register matches the integer value pointed to by the R11 register, which tells us that when the first character is F(0x46), the first validation can pass.

\n
0:000> g\nBreakpoint 1 hit\nDoPClient+0x17ca:\n00007ff6`dd0917ca 413b0b          cmp     ecx,dword ptr [r11] ds:0000001a`ed4ff9d0=000021a7\n\n0:000> r ecx\necx=21a7\n\n0:000> dd r11 L1 ; ? $p\n0000001a`ed4ff9d0  000021a7\nEvaluate expression: 8615 = 00000000`000021a7
\n

This also supports the hypothesis that, inside the 45 (0x2d) iterations of the checkPassword function, the input string is taken one character at a time, some calculation is applied to it, and the result is checked against a hardcoded integer value.

\n

If you continue execution after that, the program passes the validation performed by if (rcx != *(uint32_t*)r11) five times, then fails on the sixth validation and exits.

\n

It seems very likely that the first five characters of the input string, FLAG{, matched the correct password, which is why the first five validations succeeded and the sixth failed.

\n

Use JavaScript-based Debugger Scripts

\n

To obtain the correct Flag, let’s investigate in a bit more detail how DoPClient behaves when it validates the password.

\n

Specifically, I want to determine whether Flag validation is performed one character at a time from the beginning of the input string.

\n

To do that, the following operations need to be performed with the debugger.

\n
    \n
  1. Set a breakpoint at DoPClient+0x13a6, immediately after one character is extracted from the input string, and confirm whether characters are being taken from the beginning of the string throughout the 45 iterations of the loop.
    2. \n
  2. Set a breakpoint at DoPClient+0x17cd, immediately after the result of some calculation on the input character is compared, and confirm whether the validation passes.
    3. \n
  3. If validation fails for an input character, tamper with the zero flag so that the loop continues without letting the program terminate.
    4. \n
\n

To perform the operations above, this time we will automate WinDbg command handling.

\n

WinDbg provides several ways to automate debugging operations, but first we will use the JavaScript-based debugger scripts available in the current WinDbg 11.

\n

Recent WinDbg versions can use JavaScript-based debugger scripts by default, but to be safe, let’s confirm that the script provider is loaded in the debugger.

\n

In the currently running WinDbg, execute the .scriptproviders command. If JavaScript (extension '.js') appears in the list, you can conclude that the script provider is loaded in the debugger.

\n
0:000> .scriptproviders\nAvailable Script Providers:\n    NatVis (extension '.NatVis')\n    JavaScript (extension '.js')
\n

When using JavaScript-based debugger scripts, you need to load a JavaScript file created in advance with the .scriptload or .scriptrun command.

\n

Before creating a script that actually analyzes the challenge binary, let’s try running the following sample script.

\n
\"use strict\";\n\nfunction initializeScript()\n{\n    host.diagnostics.debugLog(\"RunCommands>; initializeScript was called \\n\");\n}\n\nfunction invokeScript()\n{\n    host.diagnostics.debugLog(\"RunCommands>; invokeScript was called \\n\");\n}\n\nfunction uninitializeScript()\n{\n    host.diagnostics.debugLog(\"RunCommands>; uninitialize was called\\n\");\n}\n\nfunction RunCommands(cmd)\n{\nvar ctl = host.namespace.Debugger.Utility.Control;   \nvar output = ctl.ExecuteCommand(cmd);\nhost.diagnostics.debugLog(\"RunCommands> Displaying command output \\n\");\n\nfor (var line of output)\n{\nhost.diagnostics.debugLog(\"  \", line, \"\\n\");\n}\n\nhost.diagnostics.debugLog(\"RunCommands> Exiting RunCommands Function \\n\");\n}
\n

This sample script can also be downloaded from the following GitHub repository.

\n
\n

RunCommands.js:

\n

https://github.com/kash1064/ctf-and-windows-debug/

\n
\n

After saving this sample script to the virtual machine as C:\\CTF\\RunCommands.js, try running the .scriptrun command in WinDbg.

\n

The .scriptrun command loads the script and then executes the root code, followed by the initializeScript and invokeScript functions in order.

\n

Therefore, when you execute .scriptrun C:\\CTF\\RunCommands.js, the debugLog calls defined in the initializeScript and invokeScript functions run as shown below, and you can also confirm with the .scriptlist command that the script has been loaded into the debugger.

\n
0:000> .scriptrun C:\\CTF\\RunCommands.js\nRunCommands>; initializeScript was called \nJavaScript script successfully loaded from 'C:\\CTF\\RunCommands.js'\nRunCommands>; invokeScript was called\n\n0:000> .scriptlist\nCommand Loaded Scripts:\n    {omitted}\n    JavaScript script from 'C:\\CTF\\RunCommands.js'\nOther Clients' Scripts:\n    <None Loaded>
\n

Next, after unloading the script with the .scriptunload C:\\CTF\\RunCommands.js command, let’s try loading it this time with .scriptload C:\\CTF\\RunCommands.js.

\n

When the .scriptunload C:\\CTF\\RunCommands.js command is executed, the uninitializeScript function runs as the unload routine.

\n

And when the .scriptload command is executed, only the initializeScript function runs.

\n
0:000> .scriptunload C:\\CTF\\RunCommands.js\nRunCommands>; uninitialize was called\nJavaScript script unloaded from 'C:\\CTF\\RunCommands.js'\n\n0:000> .scriptload C:\\CTF\\RunCommands.js\nRunCommands>; initializeScript was called \nJavaScript script successfully loaded from 'C:\\CTF\\RunCommands.js'
\n

Since the script file loaded successfully, let’s execute the custom RunCommands function from the debugger.

\n

This function runs the debugger command passed as an argument in WinDbg and displays the output on the console.

\n
function RunCommands(cmd)\n{\nvar ctl = host.namespace.Debugger.Utility.Control;   \nvar output = ctl.ExecuteCommand(cmd);\nhost.diagnostics.debugLog(\"RunCommands> Displaying command output \\n\");\n\nfor (var line of output)\n{\nhost.diagnostics.debugLog(\"  \", line, \"\\n\");\n}\n\nhost.diagnostics.debugLog(\"RunCommands> Exiting RunCommands Function \\n\");\n}
\n

Use the dx command to access functions loaded into the debugger.

\n

To execute the RunCommands function, run dx Debugger.State.Scripts.RunCommands.Contents.RunCommands(\"<command>\").

\n

Below are the results of executing RunCommands(\"lm\") and RunCommands(\"~k\").

\n

You can see that the same results are obtained as when you run the lm and ~k commands directly from the WinDbg Command window.

\n
0:000> dx Debugger.State.Scripts.RunCommands.Contents.RunCommands(\"lm\")\nRunCommands> Displaying command output \n  start             end                 module name\n  00007ff6`dd090000 00007ff6`dd099000   DoPClient C (no symbols)           \n  00007fff`675f0000 00007fff`6760d000   VCRUNTIME140   (deferred)             \n  00007fff`7cb20000 00007fff`7cc20000   ucrtbase   (deferred)             \n  00007fff`7cc20000 00007fff`7cf16000   KERNELBASE   (deferred)             \n  00007fff`7d080000 00007fff`7d0a7000   bcrypt     (deferred)             \n  00007fff`7dc90000 00007fff`7ddb3000   RPCRT4     (deferred)             \n  00007fff`7deb0000 00007fff`7df4e000   msvcrt     (deferred)             \n  00007fff`7e610000 00007fff`7e6b0000   sechost    (deferred)             \n  00007fff`7e970000 00007fff`7ea2d000   KERNEL32   (deferred)             \n  00007fff`7eb90000 00007fff`7ec40000   ADVAPI32   (deferred)             \n  00007fff`7f130000 00007fff`7f328000   ntdll      (pdb symbols)          C:\\ProgramData\\Dbg\\sym\\ntdll.pdb\\1669C503FDE3540E0A2FBE91C81204361\\ntdll.pdb\nRunCommands> Exiting RunCommands Function \nDebugger.State.Scripts.RunCommands.Contents.RunCommands(\"lm\")\n\n0:000> dx Debugger.State.Scripts.RunCommands.Contents.RunCommands(\"~k\")\nRunCommands> Displaying command output \n   # Child-SP          RetAddr               Call Site\n  00 00000024`05cff758 00007fff`7f1fca0e     ntdll!DbgBreakPoint\n  01 00000024`05cff760 00007fff`7e987344     ntdll!DbgUiRemoteBreakin+0x4e\n  02 00000024`05cff790 00007fff`7f1826b1     KERNEL32!BaseThreadInitThunk+0x14\n  03 00000024`05cff7c0 00000000`00000000     ntdll!RtlUserThreadStart+0x21\nRunCommands> Exiting RunCommands Function \nDebugger.State.Scripts.RunCommands.Contents.RunCommands(\"~k\")
\n

Incidentally, it is inconvenient to execute Debugger.State.Scripts.RunCommands.Contents.RunCommands(\"<command>\") every time you want to run a custom function.

\n

For that reason, it is convenient to register the loaded script information (Debugger.State.Scripts.RunCommands.Contents) as a custom variable using the dx command.

\n

To register RunCommands.js as a variable, execute the command dx @$runCommand = Debugger.State.Scripts.RunCommands.Contents.

\n

This makes it possible to run the custom RunCommands function by executing dx @$runCommand.RunCommands(\"lm\") or dx @$runCommand.RunCommands(\"~k\").

\n
0:000> dx @$runCommand = Debugger.State.Scripts.RunCommands.Contents\n@$runCommand = Debugger.State.Scripts.RunCommands.Contents                 : [object Object]\n    host             : [object Object]\n\n0:000> dx @$runCommand.RunCommands(\"lm\")\nRunCommands> Displaying command output \n  start             end                 module name\n  00007ff6`dd090000 00007ff6`dd099000   DoPClient C (no symbols)           \n  00007fff`675f0000 00007fff`6760d000   VCRUNTIME140   (deferred)             \n  00007fff`7cb20000 00007fff`7cc20000   ucrtbase   (deferred)             \n  00007fff`7cc20000 00007fff`7cf16000   KERNELBASE   (deferred)             \n  00007fff`7d080000 00007fff`7d0a7000   bcrypt     (deferred)             \n  00007fff`7dc90000 00007fff`7ddb3000   RPCRT4     (deferred)             \n  00007fff`7deb0000 00007fff`7df4e000   msvcrt     (deferred)             \n  00007fff`7e610000 00007fff`7e6b0000   sechost    (deferred)             \n  00007fff`7e970000 00007fff`7ea2d000   KERNEL32   (pdb symbols)          C:\\ProgramData\\Dbg\\sym\\kernel32.pdb\\B07C97792B439ABC0DF83499536C7AE51\\kernel32.pdb\n  00007fff`7eb90000 00007fff`7ec40000   ADVAPI32   (deferred)             \n  00007fff`7f130000 00007fff`7f328000   ntdll      (pdb symbols)          C:\\ProgramData\\Dbg\\sym\\ntdll.pdb\\1669C503FDE3540E0A2FBE91C81204361\\ntdll.pdb\nRunCommands> Exiting RunCommands Function \n@$runCommand.RunCommands(\"lm\")\n\n0:000> dx @$runCommand.RunCommands(\"~k\")\nRunCommands> Displaying command output \n   # Child-SP          RetAddr               Call Site\n  00 00000024`05cffb08 00007fff`7f1fca0e     ntdll!DbgBreakPoint\n  01 00000024`05cffb10 00007fff`7e987344     ntdll!DbgUiRemoteBreakin+0x4e\n  02 00000024`05cffb40 00007fff`7f1826b1     KERNEL32!BaseThreadInitThunk+0x14\n  03 00000024`05cffb70 00000000`00000000     ntdll!RtlUserThreadStart+0x21\nRunCommands> Exiting RunCommands Function \n@$runCommand.RunCommands(\"~k\")
\n

Automate Debugger Operations with a Script

\n

Now that JavaScript-based debugger scripts are available, let’s create a script that automates the following operations mentioned earlier.

\n
    \n
  1. Set a breakpoint at DoPClient+0x13a6, immediately after one character is extracted from the input string, and confirm whether the string is being read from the beginning throughout the 45 iterations of the loop.
    2. \n
  2. Set a breakpoint at DoPClient+0x17cd, immediately after the result of some calculation on the input character is compared, and confirm whether the validation passes.
    3. \n
  3. If validation fails for an input character, tamper with the zero flag so that the loop continues without letting the program terminate.
    4. \n
\n

To automate the operations above, I created the following JavaScript.

\n
// .scriptrun C:\\CTF\\Autorun.js\n// FLAG{AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA}\n\"use strict\";\n\nlet word = \"\";\nlet a1 = [];\n\nfunction RunCommands(cmd) {\nlet ctl = host.namespace.Debugger.Utility.Control;\nlet output = ctl.ExecuteCommand(cmd);\n\nfor (let line of output) {\nhost.diagnostics.debugLog(\"  \", line, \"\\n\");\n}\n\nreturn output;\n}\n\nfunction SetBreakPoints() {\nlet ctl = host.namespace.Debugger.Utility.Control;\nlet breakpoint;\n\nbreakpoint = ctl.SetBreakpointAtOffset(\"DoPClient\", 0x13a6);\nbreakpoint.Command = \"dx -r1 @$autoRun.CheckPoint1() ; g\";\n\nbreakpoint = ctl.SetBreakpointAtOffset(\"DoPClient\", 0x17cd);\nbreakpoint.Command = \"dx -r1 @$autoRun.CheckPoint2() ; r zf = 1 ; g\";\n\nreturn;\n}\n\nfunction Result() {\nfor (let line of a1) {\nhost.diagnostics.debugLog(\"\", line, \"\\n\");\n}\nreturn;\n}\n\nfunction CheckPoint1() {\nlet context = host.namespace.Debugger.State.DebuggerVariables.curthread.Registers.User;\nlet edxValue = context.edx;\nword = String.fromCodePoint(edxValue);\nreturn;\n}\n\nfunction CheckPoint2() {\nlet context = host.namespace.Debugger.State.DebuggerVariables.curthread.Registers.User;\nvar memory = host.memory;\nlet edxValue = context.ecx;\nlet r11Value = context.r11;\nlet int32Value = memory.readMemoryValues(r11Value, 1, 4);\na1.push(\"Result: Word is \" + word + \" EDX = \" + edxValue.toString() + \" R11 = \" + int32Value.toString() + \" IsValid = \" + (parseInt(edxValue) == parseInt(int32Value)).toString());\nreturn;\n}\n\nfunction initializeScript() {\nreturn [\nnew host.apiVersionSupport(1, 7),\n];\n}\n\nfunction invokeScript() {\nRunCommands(\"dx @$autoRun = Debugger.State.Scripts.Autorun.Contents\");\nRunCommands(\"dx @$autoRun.SetBreakPoints()\");\nRunCommands(\"g\");\nreturn;\n}
\n

This code can be downloaded as Autorun.js from the following GitHub repository.

\n
\n

Autorun.js:

\n

https://github.com/kash1064/ctf-and-windows-debug/blob/main/Autorun.js

\n
\n

When you load this code with the .scriptrun C:\\CTF\\Autorun.js command, the initializeScript function and the invokeScript function are executed first.

\n

In initializeScript, the API version to use is declared with new host.apiVersionSupport(1, 7).

\n

Then, in invokeScript, the @$autoRun object is defined and the SetBreakPoints function is executed.

\n

In SetBreakPoints, Debugger.Utility.Control’s SetBreakpointAtOffset is used to set breakpoints at DoPClient+0x13a6 and DoPClient+0x17cd.

\n

Also, by specifying the Command property, you can specify the command to be executed when the breakpoint is hit.

\n
function SetBreakPoints() {\nlet ctl = host.namespace.Debugger.Utility.Control;\nlet breakpoint;\n\nbreakpoint = ctl.SetBreakpointAtOffset(\"DoPClient\", 0x13a6);\nbreakpoint.Command = \"dx -r1 @$autoRun.CheckPoint1() ; g\";\n\nbreakpoint = ctl.SetBreakpointAtOffset(\"DoPClient\", 0x17cd);\nbreakpoint.Command = \"dx -r1 @$autoRun.CheckPoint2() ; r zf = 1 ; g\";\n\nreturn;\n}
\n

If you run the bl command after this script is executed, you can confirm that breakpoints with commands have been defined.

\n

\n \n \n\nWalkStackForRegisterContext [WalkStackForRegisterContext(inheritUnspecifiedValues, pc, sp, [fp], [regCtx]) | WalkStackForRegisterContext(inheritUnspecifiedValues, regCtx) - Performs a stack walk given the incoming abstract pc, sp, and optional fp or an optional object which contains named registers and values. The returned stack walk is of the same form as <ThreadObject>.Stack]\n

After loading this debugger script, run the program and enter a 45-character dummy Flag such as FLAG{AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA}. Then execution reaches the first breakpoint DoPClient+0x13a6, and dx -r1 @$autoRun.CheckPoint1() ; g is executed.

\n

In the CheckPoint1 function that runs here, the value of the EDX register at the moment execution paused is stored as an ASCII character in the global variable word.

\n

If the analysis in this chapter so far is correct, this word should receive the user’s input password string one character at a time.

\n
function CheckPoint1() {\nlet context = host.namespace.Debugger.State.DebuggerVariables.curthread.Registers.User;\nlet edxValue = context.edx;\nword = String.fromCodePoint(edxValue);\nreturn;\n}
\n

Because the command configured for the first breakpoint is dx -r1 @$autoRun.CheckPoint1() ; g, the program resumes execution with the g command after the CheckPoint1 function runs, so the program does not stay paused.

\n

As a result, it immediately reaches the second breakpoint, DoPClient+0x17cd, and executes dx -r1 @$autoRun.CheckPoint2() ; r zf = 1 ; g.

\n

Then, in the CheckPoint2 function that runs next, the value of the ECX register at DoPClient+0x17cd and the 32-bit integer at the address pointed to by the R11 register are obtained as shown below, and the result is added to the a1 array.

\n

Also, in JavaScript-based debugger scripts, a value at a specific memory address can be obtained with host.memory.readMemoryValues(location, numElements, [elementSize], [isSigned], [contextInheritor]) 12.

\n

In other words, memory.readMemoryValues(r11Value, 1, 4) reads one 4-byte value from the pointer address stored in the R11 register.

\n
function CheckPoint2() {\nlet context = host.namespace.Debugger.State.DebuggerVariables.curthread.Registers.User;\nvar memory = host.memory;\nlet edxValue = context.ecx;\nlet r11Value = context.r11;\nlet int32Value = memory.readMemoryValues(r11Value, 1, 4);\na1.push(\"Result: Word is \" + word + \" EDX = \" + edxValue.toString() + \" R11 = \" + int32Value.toString() + \" IsValid = \" + (parseInt(edxValue) == parseInt(int32Value)).toString());\nreturn;\n}
\n

As confirmed earlier, at the second breakpoint, the command r zf = 1 is executed after the CheckPoint2 function runs.

\n

This causes 1 to be set in the zero flag regardless of the comparison result at the immediately preceding cmp ecx, dword [r11], so the loop continues to the end whether the input character is correct or not.

\n

In fact, if you run dx -r1 @$autoRun.Result() after the program finishes executing, the information collected by the CheckPoint2 function is output as shown below.

\n

\n \n \n \n \n \n \n \n \n

\n

From this result, you can confirm that the user-entered string FLAG{AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA} is validated one character at a time from the beginning, and that only the initial FLAG{ and the final } succeed in password validation.

\n

In other words, it seems that the correct Flag can be identified by brute-forcing the input characters one at a time from the beginning and using the debugger to identify the character that succeeds in the validation performed by cmp ecx, dword [r11].

\n

Identify the Correct Flag by Brute Force

\n

From the analysis results so far, we know that the correct password string is 45 characters long.

\n

Also, because the Flag format is ^FLAG\\{[\\x20-\\x7E]+\\}$, if we identify the Flag by brute-forcing from the beginning, the number of trials required is expected to be at most about 3666, which is 39 characters multiplied by the number of printable ASCII characters (0x7E-0x20).

\n

Naturally, it is not realistic to perform debugger operations manually that many times, so we want to automate the brute-force attack through debugger operations.

\n

However, operations like the one in this case, where rerunning the program is required in order to brute-force the password, are not a good fit for scripts that are loaded into WinDbg, such as the JavaScript-based debugger script in the previous section.

\n

There are several ways to do this, but this time I decided to automate both program execution and debugger control from the outside with a Python script.

\n

In this book, to automate program execution and debugger operations, I take a somewhat brute-force approach and use the command-line debugger cdb.exe from a Python script rather than a dedicated interface.

\n

cdb.exe is a CLI-based debugger included in the Windows SDK, and it can execute the same debugger commands as WinDbg.

\n

To obtain the Flag from DoPClient by brute force, I created the following Python script.

\n
import subprocess\n\ncdb_path = \"C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Debuggers\\\\x64\\\\cdb.exe\"\nexe_path = \"C:\\\\CTF\\\\DoPClient.exe\"\nflag_path = \"C:\\\\CTF\\\\input.txt\"\nscript_path = \"C:\\\\CTF\\\\script.txt\"\n\ndbg_cmd = f\"$$< {script_path}\"\n\nwith open(script_path,\"w\") as f:\n    cmd = \"\"\n    cmd += \"g ;\"\n    cmd += \"p ;\"\n    cmd += \".if (@zf == 1) { .printf \\\"Solver: R8 is %d\\\\n\\\", @r8 ; \" + f\"$$< {script_path}\" + \" } .else { .echo \\\"Fail.\\\" ; .kill }\"\n    f.write(cmd)\n\ncommand = f\"\\\"{cdb_path}\\\" -G -o -kqm -c \\\"bp !DoPClient+0x17ca ; {dbg_cmd}\\\" \\\"{exe_path}\\\" < \\\"{flag_path}\\\"\"\n\ni = 4\nflag = r\"FLAG{\"\nwhile(i < 44):\n    for j in range(0x20,0x7e):\n        with open(flag_path,\"w\") as f:\n            word = \"\"\n            word += flag\n            word += chr(j)\n            word += \"A\"*(45 - (len(flag)+1))\n            word += \"\\n\"\n            f.write(word)\n\n        process = subprocess.Popen(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)\n        stdout, stderr = process.communicate()\n\n        print(\"\")\n        print(\"============================================================\")\n\n        for line in stdout.decode(\"utf-8\").split(\"\\n\"):\n            if line.startswith(\"Solver:\"):\n                print(line)\n            \n            if line.startswith(\"Solver: R8 is\"):\n                t = int(line.split(\" \")[-1])\n\n        print(\"============================================================\")\n\n        if t > i:\n            i = t\n            flag += chr(j)\n            print(f\"Flag: {flag}, i: {i}\")\n            break\n        \nprint(flag)
\n

This script can be downloaded as Stage1_Solver_1.py from the following repository.

\n
\n

Stage1_Solver_1.py:

\n

https://github.com/kash1064/ctf-and-windows-debug/

\n
\n

When this script is executed, it first runs the following command by using subprocess.Popen, a standard library function in Python.

\n
\"C:\\Program Files (x86)\\Windows Kits\\10\\Debuggers\\x64\\cdb.exe\" -G -o -kqm -c \"bp !DoPClient+0x17ca ; $$< C:\\CTF\\script.txt\" \"C:\\CTF\\DoPClient.exe\" < \"C:\\CTF\\input.txt\"
\n

This command starts cdb.exe with the option arguments -G -o -kqm 13 and begins debugging C:\\CTF\\DoPClient.exe. (The password to brute-force is redirected into the program from \"C:\\CTF\\input.txt\".)

\n

It also uses -c \"bp !DoPClient+0x17ca ; $$< C:\\CTF\\script.txt\" to set a breakpoint at !DoPClient+0x17ca at startup and execute the debugger script C:\\CTF\\script.txt.

\n

The debugger script used here differs from the JavaScript-based debugger script in the previous section. Instead, it is simply a script file that contains debugger commands you could execute manually.

\n

WinDbg and CDB provide a feature that lets you load and execute a debugger script file containing multiple debug commands.14

\n

In the Python script above, the following debug commands are saved to C:\\CTF\\script.txt, then automatically executed with the $$< C:\\CTF\\script.txt command.

\n
g ;p ;.if (@zf == 1) { .printf \"Solver: R8 is %d\\n\", @r8 ; $$< C:\\CTF\\script.txt } .else { .echo \"Fail.\" ; .kill }
\n

In this command, g first resumes program execution until the breakpoint at DoPClient+0x17ca is reached.

\n

At DoPClient+0x17ca, the value in the ECX register, which holds the result of applying some calculation to the input character, is compared with the hardcoded 32-bit integer at the address pointed to by the R11 register.

\n

Here, if the input character is correct, the validation succeeds and the zero flag becomes 1.

\n
1400017ca  cmp     ecx, dword [r11]\n1400017cd  jne     0x1400017fa\n\n1400017cf  inc     r8d\n1400017d2  inc     r10\n1400017d5  add     r11, 0x4\n1400017d9  cmp     r8d, 0x2d\n1400017dd  jl      0x1400013a2
\n

Then, the .if (@zf == 1) { omitted } .else { omitted } syntax executed afterwards checks whether the zero flag is 1 immediately after that validation.

\n

If the correct character has been entered, the zero flag becomes 1 after cmp ecx, dword [r11] executes, so the debugger command .printf \"Solver: R8 is %d\\n\", @r8 ; $$< C:\\CTF\\script.txt runs.

\n

In this command, the value of the R8 register is substituted into %d, the string Solver: R8 is %d\\n is displayed, and then the commands defined in the debugger script C:\\CTF\\script.txt are executed once again.

\n

In other words, the operation of resuming program execution and checking the validation result of the next character is repeated until either validation succeeds for all 45 characters or an incorrect character is entered.

\n

As described above, in this Python script, the input string is brute-forced from the beginning by repeatedly debugging with cdb.exe while specifying debugger commands.

\n

If validation of a correct password character succeeds, a string beginning with Solver: R8 is is written to standard output, so the correct input character can be identified from whether that output appears.

\n

If you actually run this script, it takes a very long time to finish, but in the end it lets you determine that FLAG{You_can_use_debug_script_in_WinDbg_Next} is the correct first Flag.

\n

\n \n \n \n \n \n \n \n \n

\n

If you enter the Flag (the correct password) identified by this script into DoPClient from the Command Prompt, you can reach the code that displays the string Clear Stage1.

\n

For that reason, we can conclude that the first Flag identified here is indeed correct.

\n

\n \n