\n\nThis page has been machine-translated from the original page.
\n
This article explains basic ELF binary analysis techniques for CTF beginners.
\nThis article was written as study material for a workshop I personally host.
\n\nAnalyzing the main Function with Ghidra
\nPeople with a basic understanding of computer architecture and ELF files
\n※ This article focuses on how to use GDB and Ghidra, so detailed explanations of foundational concepts are not provided.
\n※ The assumed level is roughly: you can read C and Python at a casual level, you know the terms CPU, registers, memory, etc. and their general purposes, and you can set up a Linux environment on your own.
\nYou need to have the following applications installed on a Linux environment with an x86_64 platform.
\n\nThe steps in this article have been reproduced in the following environment, but minor differences in application versions should not be an issue.
\n# Environment\nUbuntu20.04 64bit\nGhidra 10.1-BETA\nIDA Free 7.6\ngdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2\nradare2 4.2.1radare2 and IDA Free are installed for reference, but since they are only briefly introduced, it is fine if you do not install them.
\nThe binary used in this article can be downloaded from the link below.
\nChallenge binary: revvy_chevy
\n# Description\n1 Flag, 2 Flag, Red Flag, Blue Flag. Encrypting flags is as easy as making a rhymeNote: I contacted the MetaCTF organizers and received their permission to redistribute the challenge binary on this blog, on the condition that the MetaCTF URL is included in the article.
\nCTF link: MetaCTF | Cybersecurity Capture the Flag Competition
\nIf you are considering further redistribution, please remember to include the link above.
\nwget https://kashiwaba-yuki.com/file/revvy_chevyRun the above command in your Linux environment to download the challenge binary.
\nNow, let’s get started with the analysis.
\nFirst, let’s perform a surface-level analysis of the downloaded binary.
\nSurface-level analysis is a technique for analyzing the information held by the file itself.
\nWe perform surface-level analysis to get an overview of a file before conducting static analysis (such as reverse engineering) or dynamic analysis (actually running the program).
\nThis time, we’ll use the file and strings commands to investigate the file type and readable strings in the binary.
The file command retrieves the file type by performing the following checks in order, returning the result based on the first match:
The actual output looks like this.
\nIn this case, the binary was identified as a 64-bit ELF binary.
\n# Use the file command to check the type of the binary\n$ file revvy_chevy \nrevvy_chevy: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=271c2040193241b806252d57ce67d110b6c8e78c, for GNU/Linux 3.2.0, strippedFor details on the file command, refer to the following:
Reference: Man page of FILE
\nIn particular, the filesystem test, which has the highest priority among file command tests, is based on the result of the stat system call.
$ stat revvy_chevy \nFile: revvy_chevy\nSize: 14480 \nBlocks: 32 \nIO Block: 4096 \nregular file\nDevice: fd00h/64768dInode: 918235 Links: 1\nAccess: (0664/-rw-rw-r--) Uid: ( 1000/ ubuntu) Gid: ( 1000/ ubuntu)\nAccess: 2021-12-11 12:58:48.991810253 +0900\nModify: 2021-12-06 23:58:52.000000000 +0900\nChange: 2021-12-11 12:58:45.839677244 +0900\nBirth: -Reference: Man page of STAT
\nThe strings command lets you list all readable strings (printable byte values in the ASCII range) contained in the binary of the target file.
By default, it outputs readable strings of 4 or more characters.
\nIn surface-level analysis, the output of the strings command can yield useful information for analysis, such as the names of libraries and functions being used, and any text defined in the binary.
# Use the strings command to retrieve readable strings in the binary\n$ strings revvy_chevy \n{{ omitted }}For details, refer to the manual page.
\nReference: Man page of strings
\nThe readelf command is used to retrieve an overview of an ELF file.
It can display information from the ELF header, section headers, segments, and more in a formatted way.
\n$ readelf -a revvy_chevyReference: readelf(1) - Linux manual page
\nFrom the surface-level analysis, we now know that the downloaded file is an executable in ELF format.
\nBy the way, ELF stands for Executable and Linkable Format, an executable file format commonly used on Linux and UNIX systems.
ELF binaries have an ELF header that is 52 bytes long (for 32-bit) or 64 bytes long (for 64-bit).
\nKnowing the ELF header format can be very useful when analyzing ELF binaries.
\nFor details on the ELF header, the English Wikipedia article is very comprehensive and easy to understand, so it is highly recommended.
\nReference: Executable and Linkable Format - Wikipedia
\nOn Linux systems, files have permissions set, and access is restricted from two perspectives: the owner (user and group) and the permitted operations (read/write/execute).
\nIn a default Linux system configuration, the file we downloaded does not yet have execute permission, so we need to grant it first.
\nThe file owner and permissions can be confirmed with the ls -l command.
$ ls -l\ntotal 16\n-rw-rw-r-- 1 ubuntu ubuntu 14480 12月 6 23:58 revvy_chevyFor details, refer to the following:
\nReference: Man page of LS
\nReference: Understanding Linux File Permissions | Linuxize
\nTo grant execute permission to the file, use the chmod +x command.
$ chmod +x revvy_chevy \n$ ls -l\ntotal 16\n-rwxrwxr-x 1 ubuntu ubuntu 14480 12月 6 23:58 revvy_chevyReference: Man page of CHMOD
\nAs shown above, when you check permissions with ls -l and see x, you know that execute permission has been granted.
Now let’s run it.
\n$ ./revvy_chevy \nWhat's the flag? <input text>\nThat's not it...Running the challenge binary prompts you for a string input.
\nWhen we enter an arbitrary string, That's not it... is displayed.
From this result, we can infer that the program is likely comparing the input string against the Flag internally.
\nradare2 is a feature-rich analysis tool that allows you to invoke various operations from the CUI, including disassembly, binary patching, data comparison and search, and decompilation.
\nLaunch radare2 with radare2 revvy_chevy and start analysis by calling the aaa command.
After analysis completes, calling the afl command lists the functions in the binary.
$ radare2 revvy_chevy\n# aaa command\n[0x00001100]> aaa\n[Cannot find function at 0x00001100 sym. and entry0 (aa)\n[x] Analyze all flags starting with sym. and entry0 (aa)\n[x] Analyze function calls (aac)\n[x] Analyze len bytes of instructions for references (aar)\n[x] Check for objc references\n[x] Check for vtables\n[x] Type matching analysis for all functions (aaft)\n[x] Propagate noreturn information\n[x] Use -AA or aaaa to perform additional experimental analysis.\n\n# List functions with afl command\n[0x00001100]> afl\n0x00001130 4 41 -> 34 fcn.00001130Note that the radare2 help is quite clear, so calling help with an option like a -h is a good idea.
The following website is also helpful:
\nReference: Command-line Flags - The Official Radare2 Book
\nTo disassemble and decompile a function with radare2, run the following commands:
\n# Running a function offset moves to that address\n[0x00001100]> afl\n0x00001130 4 41 -> 34 fcn.00001130\n[0x00001100]> 0x00001130\n\n# Running pdf at the function start address gives the disassembly result\n[0x00001130]> pdf\n ; CALL XREF from entry.fini0 @ +0x27\n 34: fcn.00001130 ();\n 0x00001130 488d3de12e00. lea rdi, qword [0x00004018]\n 0x00001137 488d05da2e00. lea rax, qword [0x00004018]\n 0x0000113e 4839f8 cmp rax, rdi\n ┌─< 0x00001141 7415 je 0x1158\n │ 0x00001143 488b058e2e00. mov rax, qword [reloc._ITM_deregisterTMCloneTable] ; [0x3fd8:8]=0\n │ 0x0000114a 4885c0 test rax, rax\n ┌──< 0x0000114d 7409 je 0x1158\n ││ 0x0000114f ffe0 jmp rax\n..\n ││ ; CODE XREFS from fcn.00001130 @ 0x1141, 0x114d\n └└─> 0x00001158 c3 ret\n\n# Running pdc at the function start address gives the decompiled result\n[0x00001130]> pdc\nfunction fcn.00001130 () {\n // 4 basic blocks\n loc_0x1130:\n //CALL XREF from entry.fini0 @ +0x27\n rdi = qword [0x00004018]\n rax = qword [0x00004018]\n var = rax - rdi\n if (!var) goto 0x1158 //likely\n {\n loc_0x1158:\n //CODE XREFS from fcn.00001130 @ 0x1141, 0x114d\n return\n loc_0x1143:\n rax = qword [reloc._ITM_deregisterTMCloneTable] //[0x3fd8:8]=0\n var = rax & rax\n if (!var) goto 0x1158 //likely\n }\n return;\n loc_0x114f:\n goto rax\n(break)\n}Next, let’s check the disassembly and decompilation results from a GUI.
\nGhidra is an open-source reverse engineering tool developed by the NSA.
\nIf you set it up using the official installation method, you can launch it with ghidraRun.
$ ghidraRunReference: Ghidra
\nOnce the Ghidra GUI launches, select [File] > [Import File] from the top left to load the challenge binary.
\nOnce loading is complete, click the imported filename to start analysis.
\nFor detailed usage of Ghidra, the help tool accessible via [Help] > [Content] is quite thorough and is highly recommended.
\nIf you want information in Japanese, there is not much systematically organized content on the web, so reading Ghidra実践ガイド is recommended.
\nOnce the Ghidra analysis window is open, we first want to find the disassembly and decompilation results for the main function.
\nHowever, when searching the Functions list in the Symbol Tree on the left side of the default screen, we could not find the main function.
\n In little-endian format, 0x1100 is the entry point address.
Using the -h option with the readelf command mentioned earlier, you can easily view the information in the ELF header.
$ readelf -h revvy_chevy\nELF Header:\n Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 \n Class: ELF64\n Data: 2's complement, little endian\n Version: 1 (current)\n OS/ABI: UNIX - System V\n ABI Version: 0\n Type: DYN (Shared object file)\n Machine: Advanced Micro Devices X86-64\n Version: 0x1\n Entry point address: 0x1100\n Start of program headers: 64 (bytes into file)\n Start of section headers: 12624 (bytes into file)\n Flags: 0x0\n Size of this header: 64 (bytes)\n Size of program headers: 56 (bytes)\n Number of program headers: 13\n Size of section headers: 64 (bytes)\n Number of section headers: 29\n Section header string table index: 28Now that we know the entry point address is 0x1100, let’s open the entry function address from the Ghidra Symbol Tree.
The disassembly and decompilation results of the entry function are displayed, but looking at the address, it shows 0x101100 instead of 0x1100.
By the way, the Ghidra image base setting can be changed arbitrarily.
\nFor example, setting it to 0x555555555000 allows you to align the displayed addresses with those shown when using tools like gdb.
When analyzing with Ghidra, you can rename function names and variable names at will, so renaming them to something meaningful each time will help you analyze more efficiently.
\nLet’s first look at the decompiled result of the main function. (The local variable definitions are cut for brevity.)
\nint main(void)\n{\n /* omitted */ \n local_20 = *(long *)(in_FS_OFFSET + 0x28);\n \n /* Receive standard input (stdin) from the user and store it in local_68 */ \n __printf_chk(1,\"What\\'s the flag? \");\n /* omitted */ \n pcVar3 = fgets((char *)&local_68,0x40,stdin);\n if (pcVar3 == (char *)0x0) { \n puts(\"no!!\");\n iVar2 = 1;\n }\n \n /* Find the newline character and replace it with a null character */ \n else {\n sVar4 = strcspn((char *)&local_68,\"\\n\"); \n *(undefined *)((long)&local_68 + sVar4) = 0;\n lVar5 = 0;\n \n /* Mysterious loop processing */ \n do {\n cVar1 = FUN_001011e9();\n *(byte *)((long)&local_68 + lVar5) = *(byte *)((long)&local_68 + lVar5) ^ cVar1 + (char)lVar5;\n lVar5 = lVar5 + 1;\n } while (lVar5 != 0x40);\n \n /* Compare local_68 value with PTR_DAT_00104010 for 0x40 bytes */\n iVar2 = memcmp(&local_68,PTR_DAT_00104010,0x40);\n if (iVar2 == 0) {\n puts(\"You got it!\");\n }\n else {\n puts(\"That\\'s not it...\");\n iVar2 = 1;\n }\n }\n /* omitted */ \n}From the above, we can see that this main function is broadly divided into the following four processes:
\nlocal_68\\0)\nReference: c - What is the difference between NULL, ‘\\0’ and 0? - Stack Overflowlocal_68 with PTR_DAT_00104010 for 0x40 bytesFirst, let’s rename the local_68 variable to something like input_text, then proceed to analyze each step in order.
The first part we’ll look at is the following code.
\nThe fgets function reads up to 0x40 characters of input from standard input and stores it in the variable input_text.
If the read fails, it outputs the string no!! and exits.
pcVar3 = fgets((char *)&input_text,0x40,stdin);\nif (pcVar3 == (char *)0x0) { \nputs(\"no!!\");\niVar2 = 1;\n}The fgets function is a function that can read a specified number of bytes from a stream (FILE object).
Reference: C library function - fgets()
\nThe reason this function can receive user input is that on Linux and UNIX-based systems, most devices are abstracted and treated as files.
\nOn Linux systems, as described in the following manual, the FILE object stdin is defined as the input stream for receiving standard input.
Reference: stdin(3) - Linux manual page
\nThat is why fgets can receive input values.
For those who want to learn more, the following book is easy to understand and a good reference.
\nReference: 動かしながらゼロから学ぶ Linuxカーネルの教科書
\nThe next part to focus on is this:
\nsVar4 = strcspn((char *)&input_text,\"\\n\"); \n*(undefined *)((long)&input_text + sVar4) = 0;The strcspn function returns the length of the initial segment of the first argument string that consists only of characters not in the second argument (reject) string.
In other words, using strcspn, you can find the position where a given character first appears.
Here, we are finding the position of the newline character \\n in the string received from standard input, and changing the byte at that position to 0.
The reason for doing this is that the string received from standard input contains a newline character.
\nIf you actually look at the memory contents, you can see that the newline character 0x0a follows the input characters, as shown below.
How to use GDB is described later.
\nLooking at the next process, we can see that it XOR-encrypts the string received from standard input using a value obtained by adding the loop counter lVar5 to the return value of the mysterious function FUN_001011e9.
do {\n cVar1 = FUN_001011e9();\n *(byte *)((long)&input_text + lVar5) = *(byte *)((long)&input_text + lVar5) ^ cVar1 + (char)lVar5;\n lVar5 = lVar5 + 1;\n} while (lVar5 != 0x40);Details about XOR cipher are omitted here.
\nReference: たのしいXOR暗号入門
\nHere, the XOR-encrypted input_text is compared byte-by-byte against the byte sequence defined in PTR_DAT_00104010 for 0x40 bytes to check whether they match.
iVar2 = memcmp(&input_text,PTR_DAT_00104010,0x40);\nif (iVar2 == 0) {\nputs(\"You got it!\");\n}\nelse {\nputs(\"That\\'s not it...\");\n iVar2 = 1;\n}It is presumed that if the string given as initial input is the correct flag, the XOR-encrypted result will match the byte values defined in PTR_DAT_00104010.
Next, let’s examine the value defined in PTR_DAT_00104010.
In an ELF binary, predefined data such as strings is stored in the .data section.
Reference: Data segment - Wikipedia
\nThe .data section is a read-write area, so writable variables and similar data are stored there.
It is possible to jump to the section where this data is defined by clicking PTR_DAT_00104010 in Ghidra’s decompilation result, but let’s first identify the offset of the .data section.
First, let’s perform surface-level analysis using readelf -S.
$ readelf -S revvy_chevy \nThere are 29 section headers, starting at offset 0x3150:\n\nSection Headers:\n [Nr] Name Type Address Offset Size EntSize Flags Link Info Align\n [25] .data PROGBITS 0000000000004000 00003000 0000000000000018 0000000000000000 WA 0 0 8From this output, we can see that the .data section occupies 0x18 bytes starting from virtual address 0x4000.
Next, let’s use the iS command in radare2 analysis to retrieve the section table.
[0x00001100]> iS\n[Sections]\n\nnth paddr size vaddr vsize perm name\n\n0 0x00000000 0x0 0x00000000 0x0 ---- \n1 0x00000318 0x1c 0x00000318 0x1c -r-- .interp\n2 0x00000338 0x20 0x00000338 0x20 -r-- .note.gnu.property\n3 0x00000358 0x24 0x00000358 0x24 -r-- .note.gnu.build_id\n4 0x0000037c 0x20 0x0000037c 0x20 -r-- .note.ABI_tag\n5 0x000003a0 0x28 0x000003a0 0x28 -r-- .gnu.hash\n6 0x000003c8 0x138 0x000003c8 0x138 -r-- .dynsym\n7 0x00000500 0xd1 0x00000500 0xd1 -r-- .dynstr\n8 0x000005d2 0x1a 0x000005d2 0x1a -r-- .gnu.version\n9 0x000005f0 0x40 0x000005f0 0x40 -r-- .gnu.version_r\n10 0x00000630 0xf0 0x00000630 0xf0 -r-- .rela.dyn\n11 0x00000720 0x90 0x00000720 0x90 -r-- .rela.plt\n12 0x00001000 0x1b 0x00001000 0x1b -r-x .init\n13 0x00001020 0x70 0x00001020 0x70 -r-x .plt\n14 0x00001090 0x10 0x00001090 0x10 -r-x .plt.got\n15 0x000010a0 0x60 0x000010a0 0x60 -r-x .plt.sec\n16 0x00001100 0x2b5 0x00001100 0x2b5 -r-x .text\n17 0x000013b8 0xd 0x000013b8 0xd -r-x .fini\n18 0x00002000 0x81 0x00002000 0x81 -r-- .rodata\n19 0x00002084 0x4c 0x00002084 0x4c -r-- .eh_frame_hdr\n20 0x000020d0 0x128 0x000020d0 0x128 -r-- .eh_frame\n21 0x00002d90 0x8 0x00003d90 0x8 -rw- .init_array\n22 0x00002d98 0x8 0x00003d98 0x8 -rw- .fini_array\n23 0x00002da0 0x1f0 0x00003da0 0x1f0 -rw- .dynamic\n24 0x00002f90 0x70 0x00003f90 0x70 -rw- .got\n25 0x00003000 0x18 0x00004000 0x18 -rw- .data\n26 0x00003018 0x0 0x00004020 0x10 -rw- .bss\n27 0x00003018 0x2a 0x00000000 0x2a ---- .comment\n28 0x00003042 0x10a 0x00000000 0x10a ---- .shstrtabThis result also shows that the .data section occupies 0x18 bytes starting from virtual address 0x4000.
So, let’s actually look at the disassembly result at RVA 0x104000 in Ghidra.
Data is stored within the range of 0x18 bytes.
\nOur target is the value at PTR_DAT_00104010, which appears to be stored as a pointer in the .data section.
Therefore, let’s jump further to DAT_00102040, which this pointer points to.
The byte sequence is stored there.
\nUltimately, the line iVar2 = memcmp(&input_text,PTR_DAT_00104010,0x40); references 0x40 bytes of data starting from the address 0x104010.
Since this is hard to read as-is, let’s use Ghidra’s features to format and retrieve this data.
\nThis time, since we want to use it in a Python script later, we decided to retrieve it in Python array format.
\nFirst, select the range of 0x40 bytes starting from 0x104000 and right-click.
Then press [Copy Special] and select [Python List].
\nThis gave us the binary data in a format usable as a Python array, as shown below.
\n[ 0x74, 0x1a, 0x95, 0x4e, 0xba, 0xdb, 0x47, 0x64, 0x09, 0x2d, 0xd1, 0xbf, 0x8a, 0x9d, 0xde, 0x5a, 0xd7, 0x5c, 0x93, 0x16, 0x09, 0x3b, 0x30, 0x6f, 0x97, 0x40, 0xd0, 0x7c, 0x57, 0xdb, 0xde, 0x0c, 0x09, 0xa0, 0x84, 0x9b, 0x8a, 0x76, 0x2f, 0xb1, 0x57, 0xa2, 0xe1, 0x4f, 0xb9, 0x6f, 0x81, 0xbf, 0xb9, 0xbf, 0xe1, 0xef, 0x79, 0xcf, 0x01, 0xdf, 0xf9, 0x9f, 0xe1, 0x8f, 0x39, 0x2f, 0x81, 0xff, 0x00 ]There are various other ways to convert to different data types and copy, so using them as appropriate will allow you to proceed with analysis more smoothly.
\nLet’s continue with the static analysis a bit more.
\nIn the XOR encryption process we analyzed earlier, there was a line that calls the function FUN_001011e9.
do {\n cVar1 = FUN_001011e9();\n *(byte *)((long)&input_text + lVar5) = *(byte *)((long)&input_text + lVar5) ^ cVar1 + (char)lVar5;\n lVar5 = lVar5 + 1;\n} while (lVar5 != 0x40);From here, we’ll trace what this function does.
\nLooking at the Ghidra decompilation result, it was a simple function with just a single line.
\nvoid FUN_001011e9(void)\n{\n DAT_0010402c = DAT_0010402c * 0x41c64e6d + 0x3039 & 0x7fffffff;\n return;\n}DAT_0010402c was an undefined variable, so let’s replace it with an appropriate name like variable.
Now, one question has arisen.
\nLooking at the decompiled result of the caller, cVar1 = FUN_001011e9();, it appears as though the return value of this function is stored in cVar1.
However, looking at the actual decompiled result of this function, it appears to be a void function with no return value.
Which one is correct?
\nWe could determine this by reading the assembly or through dynamic analysis, but this time let’s also look at the decompilation result from IDA Free.
\nSince we asked you to install it in advance, let’s look at the IDA Free analysis result as well.
\nWe’ll omit a detailed explanation of IDA, so please launch it with the following command and import the challenge binary.
\n$ ida64Unlike when we analyzed with Ghidra, it has identified the symbol for the main function from the start.
\nIn IDA, pressing the [F5] key on the disassembly output screen performs decompilation.
\nWhen we identify the function called during XOR encryption from the same line as in Ghidra and check the decompiled result, we can see that it returns an int64 type value, as shown below.
\nAs shown here, decompilation results can differ between decompilers, and sometimes the results are outright incorrect.
\nTherefore, rather than blindly trusting a decompiler, when in doubt it is recommended to carefully read the assembly or compare the results with other tools.
\nNow we know that the return value cVar1 plus the loop counter lVar5 is used to XOR-encrypt input_text one character at a time from the beginning.
*(byte *)((long)&input_text + lVar5) = *(byte *)((long)&input_text + lVar5) ^ cVar1 + (char)lVar5;If we can find the input that makes this encryption result equal to the following byte sequence, we should be able to obtain the Flag.
\n[ 0x74, 0x1a, 0x95, 0x4e, 0xba, 0xdb, 0x47, 0x64, 0x09, 0x2d, 0xd1, 0xbf, 0x8a, 0x9d, 0xde, 0x5a, 0xd7, 0x5c, 0x93, 0x16, 0x09, 0x3b, 0x30, 0x6f, 0x97, 0x40, 0xd0, 0x7c, 0x57, 0xdb, 0xde, 0x0c, 0x09, 0xa0, 0x84, 0x9b, 0x8a, 0x76, 0x2f, 0xb1, 0x57, 0xa2, 0xe1, 0x4f, 0xb9, 0x6f, 0x81, 0xbf, 0xb9, 0xbf, 0xe1, 0xef, 0x79, 0xcf, 0x01, 0xdf, 0xf9, 0x9f, 0xe1, 0x8f, 0x39, 0x2f, 0x81, 0xff, 0x00 ]It is also possible to identify the Flag through static analysis alone, but that’s quite tedious, so from here we’ll perform dynamic analysis.
\nDynamic analysis is a method of analysis performed while actually running the executable.
\nThis time, we’ll use a debugger called gdb to perform dynamic analysis and identify the Flag.
\nFirst, let’s open the challenge binary with gdb.
\nIf you have already installed gdb-peda, a color-highlighted console will open.
\n$ gdb ./revvy_chevyWe’ll skip detailed explanation of gdb-peda, but think of it as an extension that nicely visualizes register and memory information in gdb.
\nReference: longld/peda: PEDA - Python Exploit Development Assistance for GDB
\nThe basic operations when solving CTF problems with gdb are as follows:
\nFirst, let’s try setting a breakpoint at the main function.
\nIn gdb, breakpoints can be set with either of the following commands:
\nb <breakpoint target>\nbreak <breakpoint target>For the breakpoint target, you can specify a function name, a line number in the current file, an offset from the current point, a memory address, etc.
\nIn CTF cases like this one where symbol information is often not provided, setting breakpoints by memory address will generally be the main approach.
\nEarlier, when we identified the main function in Ghidra, the main function address was 0x1208.
However, specifying this address in gdb will not set a breakpoint at the main function.
\nWhen setting a breakpoint in gdb, you need to specify the RVA that gdb loads when it runs the program.
\nThe main function address 0x1208 is a virtual address (VA), so to determine the RVA, we’ll identify the base address to which gdb maps memory when executed.
To identify the base address, let’s run the challenge binary from gdb for now.
\nRunning with the run command prompts for standard input as before.
$ run\nStarting program: /home/parrot/Downloads/revvy_chevy \nWhat's the flag? Press [Ctrl+C] here to interrupt the program.
\nPressing [Ctrl+C] generates a keyboard interrupt SIGINT, which interrupts program execution and lets you interact with gdb.
\nIn this state, run the info proc mappings command.
$ info proc mappings \nprocess 1971\nMapped address spaces:\n Start Addr End Addr Size Offset objfile\n 0x555555554000 0x555555555000 0x1000 0x0 /home/parrot/Downloads/revvy_chevy\n 0x555555555000 0x555555556000 0x1000 0x1000 /home/parrot/Downloads/revvy_chevy\n 0x555555556000 0x555555557000 0x1000 0x2000 /home/parrot/Downloads/revvy_chevy\n 0x555555557000 0x555555558000 0x1000 0x2000 /home/parrot/Downloads/revvy_chevy\n 0x555555558000 0x555555559000 0x1000 0x3000 /home/parrot/Downloads/revvy_chevy\n /* omitted */This gives you the mapping information between the challenge binary offsets and the memory addresses loaded by gdb.
\nIt appears that file offset 0x1000 is mapped to 0x555555555000.
From the surface-level analysis results with readelf and radare2, we know the .text section address is 0x1100, so 0x1100 corresponds to 0x555555555100 at gdb runtime.
It may be a bit confusing, but the fact that address 0x1100 is loaded to 0x555555555100 at gdb runtime means that the main function address 0x1208 is loaded to 0x555555555208 in gdb.
Now that we’ve identified the RVA of the main function, let’s set a breakpoint and run it.
\nSet the breakpoint with the following command.
\nWhen specifying an address for a breakpoint, you need to prefix it with *.
$ b *0x555555555208\nBreakpoint 1 at 0x555555555208Breakpoints can be confirmed with i breakpoint.
We won’t use it this time, but the Num value is the breakpoint ID, which can be used to delete a breakpoint with delete <Num> or d <Num>.
i breakpoints \nNum Type Disp Enb Address What\n1 breakpoint keep y 0x0000555555555208Now that the breakpoint has been confirmed, call the run command.
Processing stopped at the main function call timing, and gdb-peda displayed register and stack information.
\nBy the way, the run command launches a process from gdb; to pass command-line arguments at runtime, call it as run <command-line arguments>.
From here, we’ll proceed with analysis by correlating Ghidra’s decompilation results with gdb, so let’s change Ghidra’s base address to 0x555555554000 to match gdb.
Changing the Ghidra base address can be done from [Options] at file import time, or by opening [Window] > [Memory Map] and clicking the [Set Image Base] button on the right.
\nBy the way, register values can also be obtained using the p command.
$ p $rax\n$2 = 0x3039In particular, since the byte sequence after XOR encryption is of char type in this case, only the lower 8 bits of the RAX register value are used as the XOR encryption key.
\nTo extract only the lower 8 bits of a specific register, output the $al register value with the p command.
$ p $al\n$3 = 0x39This means the key for encrypting the first character is 0x39.
Since this key is generated each time a character is encrypted, using the c command to resume execution will bring us to the next breakpoint at the time of encrypting the second character.
Using this method, we identified the keys for the first four characters.
\n1st character: 0x39\n2nd character: 0x7f\n3rd character: 0xe1\n4th character: 0x2fLet’s try decrypting the first four characters of the Flag using this key and the byte sequence identified from Ghidra earlier.
\n[ 0x74, 0x1a, 0x95, 0x4e, 0xba, 0xdb, 0x47, 0x64, 0x09, 0x2d, 0xd1, 0xbf, 0x8a, 0x9d, 0xde, 0x5a, 0xd7, 0x5c, 0x93, 0x16, 0x09, 0x3b, 0x30, 0x6f, 0x97, 0x40, 0xd0, 0x7c, 0x57, 0xdb, 0xde, 0x0c, 0x09, 0xa0, 0x84, 0x9b, 0x8a, 0x76, 0x2f, 0xb1, 0x57, 0xa2, 0xe1, 0x4f, 0xb9, 0x6f, 0x81, 0xbf, 0xb9, 0xbf, 0xe1, 0xef, 0x79, 0xcf, 0x01, 0xdf, 0xf9, 0x9f, 0xe1, 0x8f, 0x39, 0x2f, 0x81, 0xff, 0x00 ]When we actually decrypted the first four characters, the output was Meta, which matches the MetaCTF flag format.
enc = [ 0x74, 0x1a, 0x95, 0x4e ]\nkey = [ 0x39, 0x7f, 0xe1, 0x2f ]\nfor i in range(4):\nprint(chr(enc[i] ^ key[i]) ,end=\"\")\n>>> MetaNow we just need to identify all 0x40 characters’ worth of keys to get the Flag.
\nHowever, repeating this process 56 more times is quite tedious.
\nSo from here, we’ll automate the gdb processing to obtain the Flag all at once.
\ngdb can be automated using .gdbinit or gdb-python.
Reference: scripting - What are the best ways to automate a GDB debugging session? - Stack Overflow
\nReference: Python (Debugging with GDB)
\n.gdbinit is simpler for automating gdb command operations, but since we want to perform calculations based on the retrieved values this time, we’ll use gdb-python, which makes it easier to define more flexible processing.
When debugging using gdb-python, the following Python script is the basic template.
import gdb\n\nBINDIR = \"~/Downloads\"\nBIN = \"revvy_chevy\"\nINPUT = \"./in.txt\"\nBREAK = \"0x5555555552ba\"\n\nwith open(INPUT, \"w\") as f:\n f.write(\"A\"*0x40)\n\ngdb.execute('file {}/{}'.format(BINDIR, BIN))\ngdb.execute('b *{}'.format(BREAK))\ngdb.execute('run < {}'.format(INPUT))\n\ngdb.execute('quit')gdb.execute() is the function that executes gdb commands from a Python script.
The basic usage is the same as operating gdb by command, but one slightly tricky point is that input values during execution must be predefined in a file.
\nSince this program requires input from standard input, we create a file called ./in.txt before execution and pre-write 0x40 bytes worth of string to it.
Running this automates the process of executing the program in gdb, entering 0x40 bytes of string, stopping at the breakpoint 0x5555555552ba, and then ending the debug session.
The call is made not from Python but using the gdb -x command, as follows:
gdb -x solver.pyFinally, let’s add the key retrieval process and obtain the Flag.
\nFrom here it’s simple.
\nWe automated the work of using the continue command to retrieve keys one character at a time, which we previously did manually.
\nThis is the solver script.
\n# gdb -x solver.py\nimport gdb\n\nBINDIR = \"~/Downloads\"\nBIN = \"revvy_chevy\"\nINPUT = \"./in.txt\"\nBREAK = \"0x5555555552ba\"\n\n# Byte sequence retrieved from Ghidra\ndata = [ 0x74, 0x1a, 0x95, 0x4e, 0xba, 0xdb, 0x47, 0x64, 0x09, 0x2d, 0xd1, 0xbf, 0x8a, 0x9d, 0xde, 0x5a, 0xd7, 0x5c, 0x93, 0x16, 0x09, 0x3b, 0x30, 0x6f, 0x97, 0x40, 0xd0, 0x7c, 0x57, 0xdb, 0xde, 0x0c, 0x09, 0xa0, 0x84, 0x9b, 0x8a, 0x76, 0x2f, 0xb1, 0x57, 0xa2, 0xe1, 0x4f, 0xb9, 0x6f, 0x81, 0xbf, 0xb9, 0xbf, 0xe1, 0xef, 0x79, 0xcf, 0x01, 0xdf, 0xf9, 0x9f, 0xe1, 0x8f, 0x39, 0x2f, 0x81, 0xff, 0x00 ]\nkey = []\n\nwith open(INPUT, \"w\") as f:\n f.write(\"A\"*0x40)\n\ngdb.execute('file {}/{}'.format(BINDIR, BIN))\ngdb.execute('b *{}'.format(BREAK))\ngdb.execute('run < {}'.format(INPUT))\n\n# Retrieve 0x40 characters' worth of keys and store in key\nfor i in range(0x40):\n # gdb.execute('p $al')\n r = gdb.parse_and_eval(\"$al\")\n key.append(int(r.format_string(), 16))\n gdb.execute('continue')\n\n# Decrypt the Flag using the retrieved keys\nflag = \"\"\nfor i in range(0x40):\n flag += chr(data[i] ^ key[i])\nif chr(data[i] ^ key[i]) == \"}\":\n break\n\nprint(flag)\ngdb.execute('quit')Running this will ultimately retrieve the Flag string.
\nFinally, let’s supplement some techniques that were not used in this particular problem.
\nFor the analysis, we’ll use a program compiled from the following source code.
\nThis is a program where the key-creation loop is only executed when is_vulun is 1.
#include <stdio.h>\n#define TEXT \"Enjoy debug!\\n\"\n\nchar key[10] = {};\n\nint main() {\nprintf(TEXT);\n int is_vulun = 0;\n if (is_vulun == 1)\n {\n for (int i = 0; i < 10; i++)\n {\n key[i] = (char)(0x41+i);\n }\n printf(\"Key %s\\n\", key);\n }\n printf(\"Finish!!\\n\");\nreturn 0;\n}First, save this source code as easy.c and create the executable with gcc easy.c -o easy.
However, when we ran the compiled program, the key generation loop did not execute because is_vulun = 0.
First, let’s look at the line that performs conditional branching based on the value of is_vuln.
Image from Intel Developer Manual
\nThe flags most frequently used for conditional branching are as follows:
\n| FLAG | \nPurpose | \nBit number | \n
|---|---|---|
| CF (Carry Flag) | \nSet when a carry occurs during addition that exceeds the register size | \n0 | \n
| ZF (Zero Flag) | \nSet when the result of an operation is zero (0) | \n6 | \n
| SF (Sign Flag) | \nSet when the result of an operation is negative | \n7 | \n
| OF (Overflow Flag) | \nSet when the result of a signed arithmetic operation is too large to fit in a register | \n11 | \n
When branching with a cmp instruction, the branch is decided based on whether the subtraction result is 0, or positive, or negative.
The actual branching decision based on flag register values is made by several jump instructions.
\n| Instruction | \nJump Condition | \nOpcode | \n
|---|---|---|
| JE | \nEqual (ZF = 1) | \n74 | \n
| JNE | \nNot equal (ZF = 0) | \n75 | \n
| JG | \nGreater than (ZF = 0 & SF = OF) | \n7F | \n
| JGE | \nGreater than or equal (SF = OF) | \n７D | \n
| JNG | \nNot greater than (ZF = 1 | SF ! OF) | \n７E | \n
| JL | \nLess than (SF ! OF) | \n７C | \n
Reference: インラインアセンブラで学ぶアセンブリ言語 第3回 (1/3)：CodeZine（コードジン）
\nKeeping the opcodes (right column) at hand is convenient when patching to forcibly alter conditional branches.
\nOpcodes can change depending on the operand, but in general searching the IDM below is a good approach.
\nReference: Intel x86 Assembler Instruction Set Opcode Table
\nRefer to the Jcc—Jump if Condition Is Met table.
Now that we’ve organized the flag register and jump instructions, let’s return to the main topic.
\nLet’s bypass the following conditional branch that checks whether the value of is_vulun is 1.
0x00001160 837df801 cmp dword [var_8h], 1\n0x00001164 7542 jne 0x11a8Since var_8h always holds 0, after the cmp instruction at 0x00001160 is executed, the flag register will have the [ CF PF AF SF IF ] flags set.
Don’t worry about each flag in detail for now; just focus on the fact that ZF, which needs to be set to prevent jne from skipping the processing, is not set.
The result of running in gdb is as follows:
\n$ b *0x555555555164\n$ p $eflags\n$5 = [ CF PF AF SF IF ]We’ve confirmed that ZF is indeed not set.
\nTo bypass the conditional branch here, we need to set ZF.
\nIn gdb, memory data can be tampered with using the set command.
As we confirmed earlier, ZF corresponds to bit 6 of the flag register.
\nIn other words, we can set ZF by forcibly writing 1 to bit 6 of the flag register.
\n# Set bit 6 of $eflags to 1 using OR operation\n$ set $eflags |= (1 << 6)\n$ p $eflags\n$7 = [ CF PF AF ZF SF IF ]As shown above, executing set $eflags |= (1 << 6) set the ZF flag.
With this state, advancing with the n command allowed us to proceed to 0x555555555166, which would not normally be executed.
Next, let’s try bypassing the conditional branch by reading a variable’s value from memory and then tampering with it, rather than by modifying the flag register.
\nLet’s look at the same process as before.
\n0x00001160 837df801 cmp dword [var_8h], 1\n0x00001164 7542 jne 0x11a8This time, let’s set a breakpoint at 0x00001160.
Running the run command stops execution at the cmp instruction call point.
$ b *0x555555555160\n$ run\n 0x555555555159 <main+20>: mov DWORD PTR [rbp-0x8],0x0\n=> 0x555555555160 <main+27>: cmp DWORD PTR [rbp-0x8],0x1\n 0x555555555164 <main+31>: jne 0x5555555551a8 <main+99>\n 0x555555555166 <main+33>: mov DWORD PTR [rbp-0x4],0x0Here, DWORD PTR [rbp-0x8] references the value of the local variable is_vulun.
The syntax DWORD PTR [memory address] is an instruction to retrieve the memory address defined inside [] as a DWORD (32-bit unsigned integer).
$rbp-0x8 is the address of the stack where the local variable is stored, but when we check it, it appears to indirectly reference a memory address that holds the actual variable value.
p $rbp-0x8\n$16 = (void *) 0x7fffffffdce8This means the actual value of is_vulun is stored inside 0x7fffffffdce8.
In gdb, you can view the contents of memory using the x/[format] <address> command.
Reference: GDB Command Reference - x command
\nLooking at the above documentation, you can see that specifying the format as x/w <address> retrieves the memory contents as a 32-bit unsigned integer.
Therefore, running the following command shows that the value at memory address 0x7fffffffdce8 (variable is_vulun) is 0.
$ x/w 0x7fffffffdce8\n0x7fffffffdce8: 0Let’s return to the conditional branch processing.
\nHere we can see that the value of dword [var_8h] is 0, and the cmp instruction is checking whether it equals 1.
0x00001160 837df801 cmp dword [var_8h], 1\n0x00001164 7542 jne 0x11a8Therefore, it appears we can bypass the conditional branch by tampering with the value of dword [var_8h] to 1.
Here, the set command can also be used to tamper with a value at a specific memory location.
When changing the value at a specific address, append {data type} as shown in the link below.
Reference: Assignment (Debugging with GDB)
\nWe were able to tamper with the memory data as follows:
\n$ x/w 0x7fffffffdce8\n0x7fffffffdce8: 0x00000000\n\n# Tamper the value\n$ set {int}0x7fffffffdce8 = 1\n\n$ x/w 0x7fffffffdce8\n0x7fffffffdce8: 0x00000001Advancing execution in this state means the cmp instruction comparison results in is_vuln == 1, and the conditional branch bypass succeeds.
We have now been able to reference and tamper with memory information using gdb.
\nIn this article, I summarized basic ELF binary analysis techniques for CTF beginners.
\nThis article was created for a workshop I personally host, so if you wish to reuse it in a workshop or similar setting, no special permission is required.
\nJust include the URL as a reference, and feel free to use it as you like.
\nIf you have any questions or points to raise about this article or other content, please DM me on Twitter: yuki_kashiwaba.
\nComments on this article are also welcome, but Twitter DMs get a faster response.
\nI hope this article is helpful for those who are starting out with CTF.
\nSince this article only covers introductory ELF analysis topics, I’ll list the following books and websites for those who want to learn in more depth.
\nAssembly Debugger Online\nYou can easily verify the behavior of Intel-syntax assembly from the web without running gdb locally.
\nIt is useful for checking whether your understanding of a certain behavior is correct.
\nReference information will be added someday when I feel like it. There is too much to write it all.
","fields":{"slug":"/ctf-elf-training-en","tagSlugs":["/tag/ctf-en/","/tag/elf-en/","/tag/reversing-en/","/tag/training-en/","/tag/english/"]},"frontmatter":{"date":"2021-12-12","description":"","tags":["CTF (en)","ELF (en)","Reversing (en)","Training (en)","English"],"title":"[CTF Beginner's Guide] Introduction to ELF Binary Reverse Engineering","socialImage":{"publicURL":"/static/334bd91f01f5d703919e643c6130dca6/ctf-elf-training.png"}}}},"pageContext":{"slug":"/ctf-elf-training-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}