{"componentChunkName":"component---src-templates-post-template-js","path":"/himitsukichi-ctf-rev-ghidra-dynamic-en","result":{"data":{"markdownRemark":{"id":"69fb072b-beb0-5d0a-866a-94a90da7d2e8","html":"
\n

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

\n
\n

This article was written as part of CTF Advent Calendar 2022 Day18.

\n

It was my first time participating in an Advent Calendar, and I was looking forward to it.

\n

Yesterday’s article was Ark’s ”Introducing the most interesting web challenges of 2022“.

\n

Tomorrow’s article is Satoooon’s “Taking a rough look at CTFTime statistics”.

\n\n

Table of Contents

\n\n

Theme of This Article

\n

In this article, we use the Ghidra debugger feature added in version 10.0 to solve simple Reversing challenges on both Windows and Linux.

\n

My original plan was to write about analyzing an Android NDK library loaded via dlopen from a custom binary, but I spent about five days failing to get it working in my own environment, so I pivoted to this topic instead.

\n

It has been quite a while since it was announced that a debugger would be integrated into Ghidra starting with version 10.0.

\n

The Ghidra debugger relies on WinDbg on Windows and GDB on Linux, and it allows dynamic analysis of user-mode applications. However, I almost never see it used in CTF writeups.

\n

I myself tried the debugger once while it was still in preview, and honestly found it a bit uncomfortable to use, so I never touched it again after that.

\n

Some time has passed since then, and I still don’t see much information about the Ghidra debugger, so I decided to poke around, and write up how to use it along with my impressions.

\n

I’ll work through the process of solving simple dynamic-analysis Rev challenges using the Ghidra debugger.

\n

About the Program Used

\n

This time we use a program built from the following code.

\n
#include <stdio.h>\n#include <string.h>\n\nchar flag[30] = {0x4b,0x6a,0x6e,0x6a,0x77,0x70,0x76,0x68,0x6a,0x60,0x6b,0x6a,0x40,0x57,0x45,0x78,0x7a,0x6c,0x76,0x5c,0x74,0x33,0x6d,0x5c,0x67,0x71,0x62,0x22,0x22,0x7e};\n\nint super_secure_checker(char c, int i)\n{\n    if (c == (flag[i]^0x3)) return 1;\n    else return 0;\n}\n\nint main(void)\n{\n    char password[0x100];\n\n    printf(\"Input yout password: \");\n    scanf(\"%s\", password);\n    \n    int len = strlen(password);\n    if (len != 30) {\n        printf(\"Wrong!!\\n\");\n        return 0;\n    }\n    else {\n        for (int i = 0; i < 30; i++) {\n            if (super_secure_checker(password[i], i)) {\n                continue;\n            }\n            else {\n                printf(\"Wrong!!\\n\");\n                return 0;\n            }\n        }\n    }\n    printf(\"Correct!!\\n\");\n    return 0;\n}
\n

The code is straightforward and works as follows:

\n
    \n
  1. Reads a password from standard input.
    2. \n
  2. If the password is exactly 30 characters, passes each character one by one to the super_secure_checker function.
    3. \n
  3. Compares the hardcoded value XOR’d with 0x3 against the input value; returns Correct if all characters match.
    4. \n
\n

This is a typical reversing challenge of the type solvable by brute-force through dynamic analysis or symbol inspection.

\n

Since the logic is very simple, it is also possible to overwrite the return value register of super_secure_checker on each call and retrieve the password one character at a time as it is expanded into the register.

\n

Of course, a password this simple could easily be recovered through static analysis as well, but since the goal of this article is to use the Ghidra debugger, we’ll solve it via dynamic analysis instead.

\n

Using the Ghidra Debugger on Linux

\n

We analyze an ELF binary compiled from the above source code with gcc and no extra options.

\n

The sample program is available for download at Sample Program.

\n

Ghidra version 10.2.2 is used.

\n

Starting the Debugger

\n

After loading the binary, click the bug-like button in the middle of the Tool Chest to launch the debugger.

\n

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

\n

Clicking [Launch] starts the debugger and outputs various information.

\n

By default, the familiar Listing window is displayed in the center, with the Interpreter shown on the right.

\n

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

\n

The Interpreter shows the same output as when GDB is launched from the command line, and GDB commands can be entered directly. (In this environment, gdb-peda is set up, so peda’s output is displayed.)

\n

The left pane shows information about the process being debugged by GDB.

\n

From here you can also view configured breakpoints and loaded modules.

\n

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

\n

Setting Breakpoints and Running the Program

\n

Now that the debugger is up, let’s right-click the line immediately after the super_secure_checker function call in the Decompiler window and set a breakpoint via [Toggle Breakpoint].

\n

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

\n

Setting the breakpoint with SW_EXECUTE causes the color of the breakpointed line to change in the Listing window as well.

\n

The breakpoint can also be confirmed in the Interpreter via GDB.

\n

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

\n

The program can be restarted from the [Quick Launch] button at the top of the Objects window.

\n

The buttons there also allow operations such as [Step Into].

\n

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

\n

Enabling Standard Input in the Ghidra Debugger

\n

With the breakpoint set, let’s run the program.

\n

When running the program normally, execution pauses waiting for standard input at the scanf(\"%s\", password); line.

\n

However, due to an unresolved limitation in the Ghidra debugger, it is not possible to feed standard input to the program from the Interpreter.

\n

Reference: Unable to put input value into interpreter. · Issue #3174 · NationalSecurityAgency/ghidra

\n

To work around this, we check the tty of the running terminal and connect to it from the Ghidra debugger’s Interpreter.

\n

First, run the tty command in your terminal to identify the device’s pts.

\n

Next, run sleep 10000000 in the terminal as a placeholder, then enter set inferior-tty [TTY] in the Ghidra debugger’s Interpreter, and restart the program.

\n

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

\n

Once execution reaches the scanf(\"%s\", password); line, the input prompt will appear in the terminal, allowing you to provide standard input and continue the debugger session.

\n

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

\n

It is a somewhat cumbersome procedure, but other ways to provide standard input to the Ghidra debugger include using GDB scripts or Python.

\n

Additionally, you can provide standard input from the Ghidra Interpreter window by running a GDB command such as run < input.txt.

\n

Inspecting Register and Memory Information

\n

Having successfully provided standard input to the program, execution stopped at the breakpoint we set earlier.

\n
printf(\"Input yout password: \");\nscanf(\"%s\", password);\n \nint len = strlen(password);\nif (len != 30) {\nprintf(\"Wrong!!\\n\");\n    return 0;\n}
\n

Now let’s check the register values in the Register window, which appears in the right pane by default.

\n

Being able to reorder each register freely is quite convenient.

\n

Using the Ghidra debugger, you can view, search, and modify register values.

\n

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

\n

At this point, because the first character of the password was wrong, the value of EAX — which holds the return value of super_secure_checker — is 0.

\n

Let’s change this value to 1.

\n

The Register window is in Read Only mode by default.

\n

To switch to Edit mode, click the pen-like button in the upper right.

\n

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

\n

Let’s also look at memory information.

\n

To open the Memory window, go to [Windows] > [Debugger] > [New Memory View] in the toolbar.

\n

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

\n

Running the program, we can see that the character ‘A’ (which we provided as arbitrary input) is stored in the DIL register, and is being compared against ‘H’, the first character of the decrypted flag.

\n

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

\n

Note that in the Ghidra debugger’s Register window, the Type column can be set to any data type, and when a Value matches the specified type, the Repr column displays the type’s representation.

\n

To let execution continue, we use the Register window’s edit mode to overwrite the AL register value with 0x41.

\n

This allows the password verification to pass, so continuing execution reveals the second flag character.

\n

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

\n

Command-line arguments can be specified here if needed.

\n

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

\n

Once the debugger starts, a WinDbg-like console appears in the Interpreter window, just as with GDB.

\n

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

\n

Setting Breakpoints

\n

With the debugger running, use the decompiler to locate the main function’s address and set a breakpoint.

\n

Static analysis of the PE file is out of scope today, but following the entry function should lead you to main quickly.

\n

Possibly due to compiler optimizations, the decompiled output showed the super_secure_checker function’s logic inlined into main.

\n

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

\n

So, as on Linux, we set an SW_EXECUTE breakpoint at the line that compares the input value against the decrypted password.

\n

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

\n

Starting the program with the breakpoint set launches a console application.

\n

Standard input can be provided directly here, so we didn’t run into the same issue as on Linux.

\n

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

\n

The user-input string is stored on the local stack.

\n

However, it appears that the current Ghidra debugger cannot reference values in memory.

\n

The help documentation suggests a notation like *:4 (RSP+8) for reading memory, but in my environment it raised an exception and the value could not be retrieved.

\n

Looking at the following issue, it seems that memory referencing from Ghidra currently doesn’t work correctly in some cases, and there is no workaround other than using debugger commands from the Interpreter.

\n

Reference: [Debugger]: Stack Frame Memory Viewer / Editor · Issue #2866 · NationalSecurityAgency/ghidra

\n

For this reason, the screenshot above also shows the WinDbg da command being used from the Interpreter to inspect the input string on the local stack.

\n

Obtaining the Flag

\n

Finally, let’s retrieve the flag.

\n

On Linux, we retrieved the flag one character at a time by modifying register values from the Register window, but the Watches window also allows editing register values in edit mode.

\n

This time, by changing the value of RCX to 0x41 (the same as the input), we passed the password check and were able to retrieve the second and subsequent flag characters.

\n

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

\n

Summary

\n

This time we used Ghidra’s debugger feature to solve a simple reversing challenge.

\n

My initial impressions after a quick hands-on session were roughly 40% “this looks promising” and 60% “this is hard to use.”

\n

The main pain points were the critically sparse knowledge base and the very unstable behavior.

\n

On the knowledge side, Ghidra’s own help documentation is minimal, and Googling in English barely turns up any blog posts at all.

\n

On the other hand, the GitHub issues have quite a variety of questions and answers, and those issues served as almost the only useful source of information.

\n

As for stability, it may partly be my own environment, but the debugger crashed or hung with exceptions at seemingly random moments quite frequently.

\n

There are clearly still many unimplemented features in the Ghidra debugger, but since GDB and WinDbg commands can both be run from the Interpreter window, the limitation on actual debugging capability doesn’t feel that severe. That said, having the debugger become unstable so often without doing anything particularly complex was quite frustrating.

\n

Nevertheless, being a free tool that can handle both PE and ELF files in the same UI is genuinely convenient, and being able to set breakpoints directly from decompiled output is also useful. (I’ve barely used IDA, so…)

\n

Also, although not covered in this article, the Ghidra debugger’s Time feature — which captures execution-trace snapshots and allows you to step back and analyze the state at those points — looked very promising.

\n

Being limited to snapshot-based tracing is a drawback, but having a feature similar to WinDbg Preview’s Time Travel Debugging (TTD) available for ELF analysis as well is something to be genuinely excited about.

","fields":{"slug":"/himitsukichi-ctf-rev-ghidra-dynamic-en","tagSlugs":["/tag/ctf-en/","/tag/rev-en/","/tag/ghidra-en/","/tag/english/"]},"frontmatter":{"date":"2022-12-19","description":"Using the Ghidra debugger feature added in version 10.0 to solve simple Reversing challenges on Windows and Linux.","tags":["CTF (en)","Rev (en)","Ghidra (en)","English"],"title":"Use the Ghidra Debugger in 2023! - A Practical Guide","socialImage":{"publicURL":"/static/83a9435807117e1e99c60e9c8ad1fb67/himitsukichi-ctf-rev-ghidra-dynamic.png"}}}},"pageContext":{"slug":"/himitsukichi-ctf-rev-ghidra-dynamic-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}