{"componentChunkName":"component---src-templates-post-template-js","path":"/magical-windbg-vol2-03-en","result":{"data":{"markdownRemark":{"id":"27496364-ca77-550a-8f7a-86c61b7ff26b","html":"
\n

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

\n
\n

In this chapter, we gather the information needed to identify the Flag by statically analyzing DoPClient.

\n

Static analysis is a method of analyzing a program without actually executing it.

\n

Depending on the definition, the investigation of file metadata and similar information performed in Chapter 2 can also be classified as static analysis, but in this book I use the term static analysis to refer to disassembling the program and analyzing it in detail.

\n

This book uses Binary Ninja as the tool for disassembly.

\n

If you are more comfortable with another tool such as IDA or Ghidra, feel free to use that instead.

\n\n

Table of Contents

\n\n

Disassemble DoPClient with Binary Ninja

\n

First, use Binary Ninja to disassemble DoPClient.

\n

Disassembly is a method of reconstructing a program expressed in machine language into human-readable source code (assembly).

\n

Today, when humans create programs, they almost never type machine language consisting directly of 0s and 1s to create an executable.

\n

Normally, people save source code written in C, assembly language, or a similar language to a file, and then use a compiler and linker to build a machine-language file that a computer can execute.

\n

The method of converting a program built in this way back into source code so that humans can read it again is called disassembly.

\n

When a compiler or linker builds a program, it applies optimizations such as improving the efficiency of the executable code and removing comments.

\n

For that reason, note that the code you can recover by disassembling a built program does not exactly match the original source code.

\n

This book does not cover the detailed steps for building an executable program from C source code or the basic methods and algorithms of disassembly, but those topics are explained in detail in “実践バイナリ解析 バイナリ計装、解析、逆アセンブリのためのLinuxツールの作り方” 1, which is a useful reference.

\n

Disassembling with Binary Ninja is extremely easy: just launch the installed Binary Ninja and drag and drop the executable you want to analyze.

\n

When you load DoPClient.exe into Binary Ninja, the following screen appears.

\n

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

\n

Now the analysis result displayed in the view has become disassembled assembly code.

\n

Next, identify the address of the program’s main function and inspect its disassembly.

\n

Find the main function in the [Symbols] window on the left side of the screen and double-click it to inspect the disassembly result for main.

\n

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

\n

Finally, change the display mode from Linear mode to Graph mode so that the program’s branches and other control flow are easier to follow.

\n

By changing the display mode in the pull-down menu in the center of the screen from [Linear] to [Graph], you can inspect the disassembly result of the main function in Graph view.

\n

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

\n

Rename Functions

\n

If you start reading the disassembly of the main function from the beginning, you can see that the sub_140001008 function is called repeatedly near the start.

\n

Immediately before the call to sub_140001008, a string is loaded from the .data section into the RCX register.

\n

The information in the [Cross Reference] window on the left side also shows that sub_140001008 is being executed with some kind of message text as its argument.

\n

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

\n

There is not much detailed information about __stdio_common_vfprintf, but judging from its name, it seems likely to be related to the CRT library and to the vprintf function that corresponds to printf.

\n
\n

vprintf function:

\n

https://learn.microsoft.com/ja-jp/cpp/c-runtime-library/vprintf-functions?view=msvc-170

\n
\n

You can also confirm that if you actually build C source code containing the library function printf in Visual Studio, processing similar to the sub_140001008 function is called.

\n

This also suggests that sub_140001008 is the printf function and is very likely responsible for outputting the string stored in RCX.

\n

So, in Binary Ninja, right-click the sub_140001008 function, choose [Rename Symbol], and rename it to printf.

\n

Once you do this, sub_140001008 is replaced with printf in the Binary Ninja UI, making the disassembly result easier to analyze.

\n

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

\n

In other words, we have learned that this conditional branch checks whether receiving input with fgets succeeded, and terminates the program if it failed.

\n

When analyzing program behavior, one important point is to focus on conditional branches and on the behavior before and after them, and to investigate what operations cause what processing to be executed.

\n

Read Loops

\n

Next, let’s read the processing that runs after fgets successfully receives the input value, in other words the code from 0x14000194b onward.

\n

Binary Ninja’s Graph view is shown below.

\n

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

\n

First, at 0x14000194b, lea rcx, [rsp+0x40 {var_48}] stores the address RSP+0x40 in the RCX register.

\n

As we already confirmed, the stack area pointed to by the address RSP+0x40 stores the input value received by the fgets function.

\n

For that reason, analysis will probably go more smoothly if you rename the local variable var_48 to something like inputText.

\n

The following instructions execute the first loop in this function.

\n
14000194b  lea     rcx, [rsp+0x40 {inputText}]\n140001950  or      rax, 0xffffffffffffffff\n\n// 以下、ループ処理\n140001954  inc     rax\n140001957  cmp     byte [rcx+rax], dil {inputText}\n14000195b  jne     0x140001954
\n

This assembly code may look a little tricky, but the following loop processing is taking place here.

\n
    \n
  1. First, the loop counter effectively starts at 0. (By replacing RAX with 0xffffffffffffffff using an OR operation and then incrementing it once, the value used when the loop begins becomes 0.)
    2. \n
  2. Next, the cmp instruction compares whether the value at RCX+RAX, in other words inputText[i], matches the value in dil (NULL here).
    3. \n
  3. If inputText[i] does not match the value in dil, execution jumps to 0x140001954 and increments the value in the RAX register.
    4. \n
\n

In this loop, RAX continues to be incremented until inputText[i] becomes a NULL character.

\n

In other words, after this loop finishes, RAX will contain a value equal to “the size of the input received by fgets + 1.”

\n

Now that we can read the code up to this point, let’s look once again at the assembly code including the processing that follows.

\n
14000194b  lea     rcx, [rsp+0x40 {inputText}]\n140001950  or      rax, 0xffffffffffffffff\n\n// ループ処理の開始\n140001954  inc     rax\n140001957  cmp     byte [rcx+rax], dil {inputText}\n14000195b  jne     0x140001954\n\nRAX には「fgets 関数で受け取った入力値のサイズ + 1」分の値が格納されている\n14000195d  dec     rax\n140001960  cmp     rax, 0x2f\n140001964  jae     0x140001aa0\n\n14000196a  mov     byte [rsp+rax+0x40 {inputText}], dil  {0x0}
\n

Once you understand that the processing from 0x140001954 to 0x14000195b keeps incrementing RAX until it becomes a value equal to “the size of the input received by fgets + 1,” it should also make sense that this sequence can be expressed as the following simple code.

\n
inputText[strlen(inputText) - 1] = 0;
\n

This code replaces the last one byte of the input received by fgets with a NULL character.

\n

In other words, it removes the newline character from the input received by fgets.

\n

Incidentally, if you change Binary Ninja’s analysis mode to Decompile (Pseudo C), this sequence of code is replaced by the following pseudocode containing a loop.

\n
 do\n {\n     i = (i + 1);\n } while (*(uint8_t*)(&inputText + i) != 0);\n if ((i - 1) >= 0x2f)\n {\n     _lockexit();\n     breakpoint();\n }\n *(uint8_t*)(&inputText + (i - 1)) = 0;
\n

You can also see that a similar structure appears in the code executed immediately afterward, from 0x14000196a to 0x140001985.

\n
14000196a  mov     byte [rsp+rax+0x40 {inputText}], dil  {0x0}\n14000196f  lea     rcx, [rsp+0x40 {inputText}]\n140001974  or      rax, 0xffffffffffffffff\n\n140001978  inc     rax\n14000197b  cmp     byte [rcx+rax], dil {inputText}\n14000197f  jne     0x140001978\n\n140001981  cmp     rax, 0x2d\n140001985  jne     0x140001a76\n\n14000198b  lea     rcx, [rsp+0x40 {inputText}]\n140001990  call    sub_140001360
\n

In the loop processing from 0x14000196a through 0x14000197f, the length of the string received by fgets is counted again, just as before.

\n

Then, in the code starting at 0x140001981, the program checks whether the length of the received string is 45 (0x2d) characters and performs a conditional branch.

\n

Validate the Input String

\n

When the length of the input string is 45 characters, the sub_140001360 function is called with the input string stored in the RCX register as its argument.

\n

If you inspect the surrounding code in Binary Ninja’s Graph view, you can see that the value in the RAX register, which stores the return value of sub_140001360, is checked with test eax, eax, and that if RAX contains 0, the string Password is Correct is printed.

\n

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

\n

In other words, we can predict that sub_140001360 is a function that validates the input string (password) received by fgets, and returns 0 when the password is correct.

\n

So, let’s rename sub_140001360 to the checkPassword function and analyze it in more detail.

\n

If you double-click the sub_140001360 function (the checkPassword function) in Binary Ninja’s Graph view, you can inspect the code of the target function.

\n

When you view the overall structure of the checkPassword function in Graph view, the processing branches in a complex way and at first glance does not seem easy to analyze.

\n

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

\n

In the branch where the return value of sub_140001148 is not NULL, the string Driver loaded is printed, while in the other branch Driver load failed is printed and the program then exits.

\n

From this, we can infer that sub_140001148 is a function that loads a kernel driver into the system, and that if loading the driver succeeds it is very likely to return a non-NULL value.

\n

For that reason, rename sub_140001148 to something like loadDriver.

\n

Although it is not especially necessary to understand the detailed implementation of the loadDriver function in order to analyze DoPClient and DoPDriver and obtain the Flags, we will take a quick look at it by referring to Binary Ninja’s decompilation result.

\n

Below is an excerpt from the decompiled result of the loadDriver function.

\n
SC_HANDLE loadDriver()\n\n{\n    void var_4a8;\n    int64_t rax_1 = (__security_cookie ^ &var_4a8);\n    SC_HANDLE rax_2 = OpenSCManagerW(nullptr, nullptr, 2);\n    \n    /* 中略 */\n\n    void var_438;\n    uint32_t rax_4;\n    int64_t rdx_2;\n    rax_4 = GetModuleFileNameA(nullptr, &var_438, 0x104);\n    \n    /* 中略 */\n\n    char* rax_5 = strrchr(&var_438, 0x5c);\n    \n    /* 中略 */\n\n    enum ENUM_SERVICE_TYPE var_488 = 0x40003390;\n    void lpBinaryPathName;\n    sub_14000105c(&lpBinaryPathName, 0x208, \"%s\\%s\", &var_438);\n    SC_HANDLE hSCObject = OpenServiceA(rax_2, \"DoPDriver\", 0xf003f);\n    \n    /* 中略 */\n\n    PSTR var_468;\n    __builtin_memset(&var_468, 0, 0x28);\n    \n    uint32_t* lpdwTagId;\n    PSTR lpDependencies;\n    PSTR lpServiceStartName;\n    PSTR lpPassword;\n    SC_HANDLE rax_6 = CreateServiceA(rax_2, \"DoPDriver\", \"DoPDriver\", 0x10030, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, SERVICE_ERROR_IGNORE, &lpBinaryPathName, var_468, lpdwTagId, lpDependencies, lpServiceStartName, lpPassword);\n    \n    /* 中略 */\n    \n    BOOL rax_8;\n    int64_t rdx_4;\n    rax_8 = StartServiceW(rax_6, 0, nullptr);\n    if (rax_8 != 0)\n    {\n        printf(\"Service started successfully\\n\", rdx_4);\n        CloseServiceHandle(rax_2);\n        __security_check_cookie((rax_1 ^ &var_4a8));\n        return rax_6;\n    }\n    printf(\"StartService failed (%d)\\n\", ((uint64_t)GetLastError()));\n    \n    /* 中略 */\n\n}
\n

Some functions still have unclear details, but it appears that OpenSCManager 3 obtains a handle (SC_HANDLE rax_2) to the service control manager database, and that OpenService 4 and CreateService 5 are used to register a service named DoPDriver.

\n

When loading a kernel driver into a Windows system, the CreateService API is used just as it is for user-mode services 6, so this function is probably registering the DoPDriver.sys file as a service named DoPDriver.

\n

For detailed information about kernel driver implementation and loading, books such as “Windows Kernel Programming, Second Edition” 6 are useful references.

\n

The handle to the registered service obtained as the return value of the CreateService function (SC_HANDLE rax_6) is passed as an argument to the StartServiceW function 7, and when starting the DoPDriver service succeeds, the service handle is returned as the return value.

\n

Access the Driver Object

\n

The code below is executed after DoPDriver has been loaded successfully.

\n

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

\n

In a user-mode program, access to the kernel driver becomes possible by using this symbolic link with the CreateFileW function to obtain a handle to the driver object.

\n

When specifying a symbolic link to a device object in the CreateFileW function, you need to add the prefix \\\\.\\ as in \\\\.\\DoPDriver so that the I/O manager does not mistake it for a file named DoPDriver in the current folder.10

\n

The code executed after obtaining a handle to DoPDriver with the CreateFileW function is shown below.

\n
call    qword [rel CreateFileW]\nmov     rdi, rax\ncmp     rax, 0xffffffffffffffff\nje      0x140001a28\n\nlea     rcx, [rel data_140003760]  {\"Please input key to close.\\n\"}\ncall    printf\ncall    _getch\n\nmov     rcx, rdi\ncall    qword [rel CloseHandle]\n\n{省略}
\n

Here, after printing the string Please input key to close, the program appears to wait for user input.

\n

Then, when it receives any input with the getch function, it closes the obtained handle, deletes the loaded kernel driver, and ends execution of the program.

\n

Because the device object obtained through the CreateFileW function is not used afterward, it seems that we will need to analyze DoPDriver in order to obtain the second Flag.

\n

Analysis of DoPDriver is covered in Chapters 5 and 6.

\n

Summary of Chapter 3

\n

In Chapter 3, we performed static analysis of DoPClient, which is a user-mode program.

\n

From the result of disassembling the program with Binary Ninja, we confirmed that DoPClient behaves as follows.

\n
    \n
  1. It receives a password string from standard input with the fgets function.
    2. \n
  2. It verifies that the input string is 45 characters long.
    3. \n
  3. It validates the input password string with the checkPassword function (sub_140001360). At this point, the correct password that passes validation by checkPassword appears to be the first Flag.
    4. \n
  4. If the correct password is entered, it loads DoPDriver.sys into the system as a kernel driver.
    5. \n
  5. It obtains a handle to DoPDriver’s driver object with the CreateFileW function.
    6. \n
  6. It waits for arbitrary input from the user and then exits.
    7. \n
\n

In Chapter 4, we will use WinDbg to dynamically analyze the behavior of the checkPassword function and identify the correct password that becomes the first Flag.

\n\n\n
\n
\n
    \n
  1. \n

    実践バイナリ解析 バイナリ計装、解析、逆アセンブリのためのLinuxツールの作り方(Dennis Andriesse 著 / 株式会社クイープ,遠藤美代子 訳 / KADOKAWA / 2022 年)

    \n↩\n
    2. \n
  2. \n

    詳解セキュリティコンテスト CTF で学ぶ脆弱性攻略の技術 P.375 (梅内 翼, 清水 祐太郎, 藤原 裕大, 前田 優人, 米内 貴志, 渡部 裕 著 / マイナビ出版 / 2021 年)

    \n↩\n
    3. \n
  3. \n

    OpenSCManagerW function https://learn.microsoft.com/ja-jp/windows/win32/api/winsvc/nf-winsvc-openscmanagerw

    \n↩\n
    4. \n
  4. \n

    OpenServiceA function https://learn.microsoft.com/ja-jp/windows/win32/api/winsvc/nf-winsvc-openservicea

    \n↩\n
    5. \n
  5. \n

    CreateServiceA function https://learn.microsoft.com/ja-jp/windows/win32/api/winsvc/nf-winsvc-createservicea

    \n↩\n
    6. \n
  6. \n

    Windows Kernel Programming, Second Edition P.27 (Pavel Yosifovich 著 / Independently published / 2023 年)

    \n↩\n
    7. \n
  7. \n

    StartServiceW function https://learn.microsoft.com/ja-jp/windows/win32/api/winsvc/nf-winsvc-startservicew

    \n↩\n
    8. \n
  8. \n

    CreateFileW function https://learn.microsoft.com/ja-jp/windows/win32/api/fileapi/nf-fileapi-createfilew

    \n↩\n
    9. \n
  9. \n

    インサイド Windows 第 7 版 上 P.558 (Pavel Yosifovich, Alex Ionescu, Mark E. Russinovich, David A. Solomon 著 / 山内 和朗 訳 / 日系 BP 社 / 2018 年)

    \n↩\n
    10. \n
  10. \n

    Windows Kernel Programming, Second Edition P.52 (Pavel Yosifovich 著 / Independently published / 2023 年)

    \n↩\n
    11. \n
\n
","fields":{"slug":"/magical-windbg-vol2-03-en","tagSlugs":["/tag/magical-win-dbg/","/tag/windows/","/tag/win-dbg/","/tag/english/"]},"frontmatter":{"date":"2024-05-26","description":"This is the web edition of Magical WinDbg 2 - Learn User-Mode & Kernel Debugging Through CTFs -, distributed at Tech Book Fest 16.","tags":["Magical WinDbg","Windows","WinDbg","English"],"title":"Magical WinDbg VOL.2 [Chapter 3: Static Analysis of DoPClient]","socialImage":{"publicURL":"/static/e9bfc3718fd53ab58623a496fc9a302e/magical-windbg-vol2.png"}}}},"pageContext":{"slug":"/magical-windbg-vol2-03-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}