Software Introspection
Software Introspection
Tracing Syscalls
The first one is pretty simple: the syscall tracer, strace.
Given a program to run, strace will use functionality of the Linux operating system to introspect and record every system call that the program invokes, and its result. For example, let’s look at our program from the previous challenge:
1 | |
As you can see, strace reports what system calls are triggered, what parameters were passed to them, and what data they returned. The syntax used here for output is system_call(parameter, parameter, parameter, ...). This syntax is borrowed from a programming language called C, but we don’t have to worry about that yet. Just keep in mind how to read this specific syntax.
In this example, strace reports two system calls: the second is the exit system call that your program uses to request its own termination, and you can see the parameter you passed to it (42). The first is an execve system call. We’ll learn about this system call later, but it’s somewhat of a yin to exit‘s yang: it starts a new program (in this case, your-program). It’s not actually invoked by your-program in this case: its detection by strace is a weird artifact of how strace works, that we’ll investigate later.
In the final line, you can see the result of exit(42), which is that the program exits with an exit code of 42!
Now, the exit syscall is easy to introspect without using strace — after all, part of the point of exit is to give you an exit code that you can access. But other system calls are less visible. For example, the alarm system call (syscall number 37!) will set a timer in the operating system, and when that many seconds pass, Linux will terminate the program. The point of alarm is to, e.g., kill the program when it’s frozen, but in this case, we’ll use alarm to practice our strace snooping!
In this challenge, you must strace the /challenge/trace-me program to figure out what value it passes as a parameter to the alarm system call, then call /challenge/submit-number with the number you’ve retrieved as the argument. Good luck!
翻译
第一个例子相当简单：就是系统调用追踪工具——strace。
给定一个需要运行的程序，strace会利用Linux操作系统的功能来监控并记录该程序触发的每一个系统调用及其返回结果。例如，我们来看之前挑战中的程序：
1 | |
如你所见，strace会报告触发了哪些系统调用、传递了什么参数以及返回了哪些数据。这里输出的语法借鉴了C编程语言，但我们暂时无需深究。只需记住如何阅读这种特定语法即可。
在这个例子中，strace报告了两次系统调用：第二次是你的程序用于请求自我终止的exit系统调用，你可以看到传递给它的参数（42）。第一次是execve系统调用。我们后续会学习这个系统调用，但它与exit形成了某种阴阳互补的关系：它会启动一个新程序（本例中是你的程序）。这里实际上并不是由你的程序触发的：strace能检测到它是由于其工作机制的特殊性，这一点我们稍后会探讨。
最后一行显示了exit(42)的结果——程序以退出码42终止！
虽然无需strace也能轻松监控exit系统调用（毕竟exit的部分意义就在于提供可获取的退出码），但其他系统调用的可见度就低得多。例如，alarm系统调用（系统调用号37！）会在操作系统中设置一个定时器，当指定秒数过去后，Linux将终止该程序。alarm的本意是在程序卡死时将其终止，但这里我们将通过它来练习strace监控技巧！
在此挑战中，你需要使用strace监控/challenge/trace-me程序，找出它传递给alarm系统调用的参数值，然后以获取的数字作为参数调用/challenge/submit-number。祝你好运！
SOLVE
1 | |
Starting GDB
Next, let’s move on to GDB. GDB stands for the GNU Debugger, and it is typically used to hunt down and understand bugs. More specifically, a debugger is a tool that enables the close monitoring and introspection of another process. There are many famous debuggers, and in the Linux space, gdb is by far the most common.
We’ll learn gdb step by step through a series of challenges. In this one, we’ll focus on simply launching it. That’s done as so:
1 | |
In this challenge, the binary that holds the secret is /challenge/debug-me. Once you load it in gdb, the rest will happen magically: we’ll handle the analysis and give you the secret number. In later levels, you’ll learn how to get that number on your own!
Again, once you have the number, exchange it for the flag with /challenge/submit-number.
翻译
接下来我们继续学习GDB。GDB是GNU调试器的缩写，通常用于排查和理解程序错误。更具体地说，调试器是一种能够对其他进程进行密切监控和内省分析的工具。市面上有许多著名的调试器，而在Linux领域，gdb无疑是最常用的工具。
我们将通过一系列挑战逐步学习gdb的使用。在本次挑战中，我们将重点掌握其启动方法。具体操作如下：
hacker@dojo:~$ gdb /路径/到/二进制文件
本次挑战中，存储密钥的二进制文件是 /challenge/debug-me。当你将其加载到gdb后，后续操作将会自动完成：我们将代为进行分析并向你提供密钥数字。在后续关卡中，你将学会如何独立获取该数字！
重申一遍，获得数字后，请通过 /challenge/submit-number 兑换验证标识。
SOLVE
1 | |
Starting Program in GDB
Debuggers, including gdb, observe the debugged program as it runs to expose information about its runtime behavior. In the previous level, we automatically launched the program for you. Here, we will tone down the magic somewhat: you must start the execution of the program, and we’ll do the rest (e.g., recover the secret value from it).
When you launch gdb now, it will eventually bring up a command prompt, that looks like this:
1 | |
You start a program with the starti command:
1 | |
starti starts the program at the very first instruction. Give it a try now, and we’ll configure gdb to magically extract the secret value once the program is running.
翻译
调试器（包括gdb）通过观察被调试程序的运行状态来揭示其运行时行为信息。在上一关卡中，我们已自动为你启动程序。现在我们将适当减少自动化操作：你需要手动启动程序运行，其余工作（例如从中提取密钥值）将由我们完成。
当你启动gdb后，最终会看到如下命令提示符：
(gdb)
你可以使用starti命令启动程序：
(gdb) starti
starti会从第一条指令开始启动程序。现在请尝试使用该命令，当程序运行后，我们将配置gdb自动提取密钥值。
SOLVE
1 | |