First order of business is to acquire the original media in a format we can work with. There are a couple of options available here:
Other ways of “acquiring” old video games may have legal issues surronding them depending on your jurisdiction. Such issues will not be covered here.
That being said, let’s assume that we do have a complete set of ISOs for the various versions of the game. We could go straight for the reverse-engineering part, but where’s the fun in that?
To run Tenchu: Stealth Assassins in a controlled environment, I’ll use DuckStation, a modern PlayStation 1 emulator. The main reason is that I contributed a GDB stub a couple of years ago, which will be useful later on to introspect the game at runtime through a debugger.
Getting it to run on a Debian 11 system is a bit of a chore:
$ sudo apt-get install \
build-essential \
cmake \
ninja-build \
libsdl2-dev \
libcurl4-openssl-dev \
libqt6-base-dev \
qt6-base-dev \
qt6-tools-dev \
qt6-base-private-dev
It takes some amount of patching to manage to get it to build on this system:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 47d00879..6d5fe750 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -47,7 +47,7 @@ endif()
# Required libraries.
if(ENABLE_SDL2)
- find_package(SDL2 2.28.5 REQUIRED)
+ find_package(SDL2 2.0 REQUIRED)
endif()
if(NOT WIN32 AND NOT ANDROID)
find_package(CURL REQUIRED)
@@ -59,7 +59,7 @@ if(NOT WIN32 AND NOT ANDROID)
endif()
endif()
if(BUILD_QT_FRONTEND)
- find_package(Qt6 6.5.3 COMPONENTS Core Gui Widgets Network LinguistTools REQUIRED)
+ find_package(Qt6 6.4.0 COMPONENTS Core Gui Widgets Network LinguistTools REQUIRED)
endif()
diff --git a/src/duckstation-qt/logwindow.cpp b/src/duckstation-qt/logwindow.cpp
index 64b95616..7d4cdcbf 100644
--- a/src/duckstation-qt/logwindow.cpp
+++ b/src/duckstation-qt/logwindow.cpp
@@ -274,7 +274,7 @@ void LogWindow::logCallback(void* pUserParam, const char* channelName, const cha
QString qmessage;
qmessage.reserve(message.length() + 1);
- qmessage.append(QUtf8StringView(message.data(), message.length()));
+ qmessage.append(message.data());
qmessage.append(QChar('\n'));
const QLatin1StringView qchannel((level <= LOGLEVEL_PERF) ? functionName : channelName);
diff --git a/src/util/sdl_input_source.cpp b/src/util/sdl_input_source.cpp
index 4db534bb..a07a3209 100644
--- a/src/util/sdl_input_source.cpp
+++ b/src/util/sdl_input_source.cpp
@@ -255,7 +255,7 @@ void SDLInputSource::SetHints()
}
SDL_SetHint(SDL_HINT_JOYSTICK_HIDAPI_PS4_RUMBLE, m_controller_enhanced_mode ? "1" : "0");
- SDL_SetHint(SDL_HINT_JOYSTICK_HIDAPI_PS5_RUMBLE, m_controller_enhanced_mode ? "1" : "0");
+ //SDL_SetHint(SDL_HINT_JOYSTICK_HIDAPI_PS5_RUMBLE, m_controller_enhanced_mode ? "1" : "0");
// Enable Wii U Pro Controller support
// New as of SDL 2.26, so use string
SDL_SetHint("SDL_JOYSTICK_HIDAPI_WII", "1");
But after that, it builds and runs without too many issues:
$ cmake -B build/ -G Ninja .
$ ninja -C build/
$ ln -s ~/Documents/duckstation/build/bin/duckstation-qt ~/.local/bin/duckstation-qt
The main reason for this janky setup instead of using the official prebuilt artifacts is to enable local development of DuckStation. In particular, I anticipate that the bare-bones GDB stub I wrote several years ago will probably need some improvements to support this decompilation project.
So, we have an image of a video game and we even checked that it works. At the moment it’s just a big blob of bytes, but we can start tearing it apart with jPSXdec, a tool to extract and convert files from PlayStation titles, free for non-commercial uses.
After grabbing the latest release, we can run the tool on the first track of Rittai Ninja Katsugeki Tenchu: Shinobi Gaisen and extract the files:
We get a whole bunch of files, which we can quickly triage as follows:
SYSTEM.CNF: this text file contains instructions for the BIOS on how to launch the game ;SLPS_019.01: this is the PSX-EXE executable to launch as specified by SYSTEM.CNF ;TENCHU/*.EXE: these are executable files ;TENCHU/MOVIE/*: these are full motion videos ;TENCHU/XA/*: these are audio files used for music and cutscenes ;TENCHU/DATA.VOL: this seems to be an archive file in an unknown format, as jPSXdec detects over 880 images contained inside of it.Most, but not all versions of Tenchu: Stealth Assassins follow this naming pattern.
There is one file that jPSXdec can’t process: TENCHU/CD.CA.
This file is located inside the second track and therefore jPSXdec can’t extract it when opening the first track.
It also fails to recognize any file or data when we open the second track.
Hmmm… What does the cue file for this CD tells us?
$ cat 'Rittai Ninja Katsugeki - Tenchu - Shinobi Gaisen (Japan).cue'
FILE "Rittai Ninja Katsugeki - Tenchu - Shinobi Gaisen (Japan) (Track 1).bin" BINARY
TRACK 01 MODE2/2352
INDEX 01 00:00:00
FILE "Rittai Ninja Katsugeki - Tenchu - Shinobi Gaisen (Japan) (Track 2).bin" BINARY
TRACK 02 AUDIO
INDEX 00 00:00:00
INDEX 01 00:02:00
It’s most likely a CD audio track.
Assuming that the track file contains raw CD audio data, we can play it using the play tool from sox with the right parameters:
$ sudo apt-get install sox
$ play --type raw --channels 2 --rate 44100 --encoding signed --bits 16 --endian little 'Rittai Ninja Katsugeki - Tenchu - Shinobi Gaisen (Japan) (Track 2).bin'
play WARN alsa: can't encode 0-bit Unknown or not applicable
Rittai Ninja Katsugeki - Tenchu - Shinobi Gaisen (Japan) (Track 2).bin:
File Size: 7.81M Bit Rate: 1.41M
Encoding: Signed PCM
Channels: 2 @ 16-bit
Samplerate: 44100Hz
Replaygain: off
Duration: 00:00:44.29
In:100% 00:00:44.29 [00:00:00.00] Out:1.95M [ | ] Hd:0.1 Clip:0
Done.
Be very careful when playing raw files as audio, especially when using headphones. A wrong guess can produce ear-shattering static noise.
It’s a voice recording of a conversation between Rikimaru, Ayame and Princess Kiku in Japanese. I do not speak this language and therefore can’t understand what is being said, but I can hear the words “game disc”, “PlayStation” and “CD player”. This is most likely a message played when the disc is inserted in a CD player, telling the user to put it in a PlayStation system.
This was a common type of easter egg for CD-ROM video games in the 1990s. Some well-known examples are Skies of Arcadia for the Dreamcast or Lego Island for the PC.
We have the game, we have extracted its files and we have uncovered an audio easter egg when triaging them. Next time, we’ll set up a reverse-engineering environment with Ghidra so that we can start figuring out how this game actually runs.
]]>This is my own personal take on a topic I’ve never attempted before. It is not intended to be an autoritative document on the subject but rather a brain-dump on how I approached this problem.
Let’s take this diagram from part 2 of my series of articles about reverse-engineering:
When a developer built a program, the original source code of the program went through a number of steps (compiler, assembler, linker…) before the artifact we’re interested in was produced. Each step is lossy, with less and less information retained at is goes down the chain, leaving us with just the end result.
Decompilation is the act of taking a binary artifact (on the right) and creating some sort of source code out of it (on the left). Depending on the goal and effort spent, it can go from a loosely inspired reimplementation using the original artifact as a reference, all the way to a source tree and build procedure that can reproduce byte-for-byte the original artifact.
I’m also including reimplementation (clean-room or otherwise) as an option alongside decompilation interchangeably in this article. While technically different from a pure decompilation effort, the end result is essentially the same for the end-user.
Even perfect decompilation can’t recover things like comments or (if debugging symbols are missing) variables names, due to the lossy nature of toolchains. It’s a recreation of one possible source tree, not a recovery of the original source code.
At this point, it’s time to start asking questions and gather as much intel as possible.
Performing acts of reverse-engineering or decompilation may have legal issues surrounding them depending on your jurisdiction. Such issues will not be covered here.
Reverse-engineering in general use skills that are uncommonly used during everyday software development work, which itself is a prerequisite in my opinion (it’s hard to pick apart a program if you don’t know how they are made in the first place). That being said, there are plenty of resources online like videos, write-ups or other decompilation projects that show the ropes.
But like any skill it also takes practice to learn. You might want to start with smaller projects or case studies if you lack experience before taking on a big project. Additionally, prior knowledge of things like the instruction set architecture or technical details about the target platform will be very helpful, as programs do not execute in a vaccum.
Ultimately, there is only one way to find out if you can indeed decompile: give it a try. At least you’re bound to learn something on the way, regardless of the outcome.
Before jumping head first into the thick of it, have a look around:
Looking around might help uncover important artifacts or helpful knowledge that you might miss otherwise. Needless to say, it is also necessary to acquire artifacts before one can start reverse-engineering or decompiling them.
Here, we have four main releases, not distinguishing between various revisions and demos:
As mentioned before, the game is a PlayStation exclusive, a well-documented video game console with lots of resources online about it. It also uses PSY-Q, the official PlayStation SDK used back in the day to make commercial games. I did not find any debugging symbols or map files, but there are lots of GameShark codes, RetroAchievements and an extensive debug menu.
Unless you enjoy staring at raw hexadecimal dumps, you probably want to use tools to help the reverse-engineering and decompilation project. There are lots and lots of tools out there for various purposes (disassembler, decompiler, asset extractors, level editors, …), to the point where it would be futile to try and make a list here.
Be on the lookout for anything that could be useful in case someone already covered that use-case. Check out other similar decompilation projects for inspiration and guidance. You might also need to write some tools yourself at some point.
I will introduce tools as they are used, but most of the reverse-engineering work will likely be done with Ghidra, an open-source software reverse engineering framework.
Simply put, what is the end goal?
For this project, I’m aiming for something roughly similar in spirit to REDRIVER2. Most of the effort is expected to be centered around Rittai Ninja Katsugeki Tenchu: Shinobi Gaisen, which is the latest release of this game. However, I’ll also take a look at other editions as I see fit, like looting the title screen from Tenchu: Stealth Assassin for example.
We went through most of the interrogative words regarding this project and came up with some answers. Next time, we’ll actually start reverse-engineering activities by extracting assets from artifacts.
]]>I could go on a poetic throwback to my childhood and describe in details a nostalgia feeling for a 25 years old entertainment product, displayed on a 1980s CRT televisions and rhythmed by the noises of a PlayStation optical drive (something that emulators fail to recreate), but I’ll spare you the brunt of it.
What I will say is that this is inspired by video game decompilations projects of the past few years, like Super Mario 64 and Driver 2. However, I do not have it in me to make a perfect, byte-for-byte decompilation like the Super Mario 64 one. Neither do I want to stare at a Ghidra window for an eternity, trying to blindly reimplement a source tree for a game held together with glue and duct tape.
These considerations led me on a lengthy side-quest to try and find a solution to this conundrum… But now, after spending nearly two years prototyping tools and writing case studies, I think I have found the edge I’ve been looking for.
My objective is to create a port of this game by delinking it back into object files and then crafting a working Linux MIPS executable out of the pieces. From there, I intend to rewrite each object file Ship of Theseus-style until I have a complete and portable source code tree.
As far as I can tell this is unlike any other decompilation project out there, so this is completely uncharted territory. Hopefully, this approach will allow me to divide-and-conquer this effort into manageable chunks and make iterative progress possible, in order to keep myself motivated.
Lord Gohda expects much of you. The enemy will be skillful and ruthless. You must be prepared, physically and spiritually. You must focus, you must train hard and train well.
aln, a statically-linked Linux a.out program, into a dynamically-linked Linux ELF program with the power of delinking.
In this part, we’ll make a native port of aln to Windows, despite not having access to its source code.
This blog post demonstrates a complete disregard towards ABIs, computer engineering conventions and common sense in the name of science. Its contents may be dangerous to junior programmers, academics or the faint of the heart.
As such, this is your one and only warning to look away before I start butcherin’.
Normally, porting software requires access to its source code in order to build it for a new platform.
Here, we do not have such luxuries and must make do with just a binary executable artifact for Linux.
From the previous parts we have created aln.o, a “normal” Linux ELF object file of a complete program created with the power of delinking from the carcass of aln, an actual Linux program.
Here comes our first problem: how do we get from an ELF object file for Linux to a Windows executable?
Traditionally, Windows toolchains use the COFF file format for objects. My Ghidra extension currently only has an object file exporter for the ELF file format. In theory, I would have to implement a full-blown COFF object file exporter in order to produce an object file that Windows toolchains can grok, but that’s a lot of work.
Fortunately for me, I’ve forsaken tradition in this series of articles and there is one toolchain targeting Windows out there that can ingest ELF object files: MinGW-w64.
$ sudo apt-get install mingw-w64
Don’t worry, the final artifact will be a bona fide PE executable for Windows, but I’ll take whatever shortcuts I can in order to finish this in a reasonable amount of time.
This is also why I’ll run aln.exe with WINE on Linux at first: I’m not going to bother dealing with Windows until I have to.
Now, we’ll take aln.o and the couple of stubs from the last part and just let’er rip:
$ i686-w64-mingw32-gcc -g -no-pie -fno-pic -o aln.exe aln.o ctype.o FUN_0000fba0.c DAT_0001de20.c
/usr/bin/i686-w64-mingw32-ld: aln.o: in function `FUN_00001584':
aln.o:(.text+0x51f): undefined reference to `IO_printf'
/usr/bin/i686-w64-mingw32-ld: aln.o:(.text+0x529): undefined reference to `puts'
/usr/bin/i686-w64-mingw32-ld: aln.o:(.text+0x533): undefined reference to `puts'
/usr/bin/i686-w64-mingw32-ld: aln.o:(.text+0x53d): undefined reference to `puts'
/usr/bin/i686-w64-mingw32-ld: aln.o:(.text+0x547): undefined reference to `puts'
/usr/bin/i686-w64-mingw32-ld: aln.o:(.text+0x551): undefined reference to `puts'
/usr/bin/i686-w64-mingw32-ld: aln.o:aln.o:(.text+0x55b): more undefined references to `puts' follow
...
/usr/bin/i686-w64-mingw32-ld: aln.o: in function `FUN_0000fa3c':
aln.o:(.text+0xe9b3): undefined reference to `malloc'
/usr/bin/i686-w64-mingw32-ld: /usr/lib/gcc/i686-w64-mingw32/10-win32/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o): in function `main':
./build/i686-w64-mingw32-i686-w64-mingw32-crt/./mingw-w64-crt/crt/crt0_c.c:18: undefined reference to `WinMain@16'
Well, basically none of the undefined symbols inside aln.o matched anything inside MinGW-w64 and no, it’s not just because I’m using a Linux object file on a Windows toolchain.
When I originally exported aln.o, I actually stripped the leading underscore from all symbols.
That’s useful when going from glibc 1.xx to glibc 2.xx since modern Linux toolchains don’t use an underscore prefix for C symbol names.
Unfortunately, that’s not the case for MinGW-w64, which does prefix C symbols with an underscore.
Rather than re-exporting aln.o with the original symbol names left intact, I’ll just use objcopy to remove the leading underscore from all undefined symbols.
Since I’ll have to make adjustments anyways, I might as well be lazy about it.
In theory, I’m trying to mix two different things that aren’t ABI compatible.
In practice, the calling convention happens to be the same and aln uses a subset of POSIX that MinGW-w64 does provide, so I’ll start by aliasing equivalent symbols together and hope for the best.
Remember, the goal of this series is to trick aln into linking a sample program successfully on new environments.
Anything goes as long as it works, no matter how wrong it is.
We’ll skip anything that’s just an underscore prefix away and go through the remaining troublemakers.
The linker doesn’t seem to find the stubs from the previous parts, despite the fact that I do provide these source files on the command line.
I’m not sure why, possibly a side-effect of mixing ELF and COFF object files, but I don’t care: I just want to smash the bits together. Let’s just cheese it by prefixing these symbols with an underscore:
| Old symbol name | New name (MinGW-w64) |
|---|---|
DAT_0001de20 |
_DAT_0001de20 |
FUN_0000fba0 |
_FUN_0000fba0 |
MinGW-w64 doesn’t appear to provide these two functions:
char *index(const char *s, int c);
char *rindex(const char *s, int c);
These functions search for a character in an ASCIIZ string and come from 4.3BSD.
They were marked legacy in POSIX.1-2001 and removed in POSIX.1-2008, with a recommendation to migrate to strchr() and strrchr() respectively:
char *strchr(const char *s, int c);
char *strrchr(const char *s, int c);
Luckily for us, these are drop-in compatible substitutions and MinGW-w64 provides these replacements. Let’s rename the symbols accordingly:
| Old symbol name | New name (MinGW-w64) |
|---|---|
index |
_strchr |
rindex |
_strrchr |
How does the C standard I/O functions work under MinGW-w64? I could go spelunking the source code to find out, but I can just ask the toolchain directly by compiling a sample program and analyzing the artifact:
#include <stdio.h>
int main(int argc, char **argv) {
fprintf(stdout, "Hello, world!\n");
return 0;
}
Let’s build it with MinGW-w64 and disassemble the object file with objdump:
$ i686-w64-mingw32-gcc hello-world.c -c -o hello-world.o
$ i686-w64-mingw32-objdump --reloc --disassemble hello-world.o
hello-world.o: file format pe-i386
Disassembly of section .text:
00000000 <_fprintf>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 28 sub $0x28,%esp
6: 8d 45 10 lea 0x10(%ebp),%eax
9: 89 45 f0 mov %eax,-0x10(%ebp)
c: 8b 45 f0 mov -0x10(%ebp),%eax
f: 89 44 24 08 mov %eax,0x8(%esp)
13: 8b 45 0c mov 0xc(%ebp),%eax
16: 89 44 24 04 mov %eax,0x4(%esp)
1a: 8b 45 08 mov 0x8(%ebp),%eax
1d: 89 04 24 mov %eax,(%esp)
20: e8 00 00 00 00 call 25 <_fprintf+0x25>
21: DISP32 ___mingw_vfprintf
25: 89 45 f4 mov %eax,-0xc(%ebp)
28: 8b 45 f4 mov -0xc(%ebp),%eax
2b: c9 leave
2c: c3 ret
0000002d <_main>:
2d: 55 push %ebp
2e: 89 e5 mov %esp,%ebp
30: 83 e4 f0 and $0xfffffff0,%esp
33: 83 ec 10 sub $0x10,%esp
36: e8 00 00 00 00 call 3b <_main+0xe>
37: DISP32 ___main
3b: c7 04 24 01 00 00 00 movl $0x1,(%esp)
42: a1 00 00 00 00 mov 0x0,%eax
43: dir32 __imp____acrt_iob_func
47: ff d0 call *%eax
49: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp)
50: 00
4d: dir32 .rdata
51: 89 04 24 mov %eax,(%esp)
54: e8 a7 ff ff ff call 0 <_fprintf>
59: b8 00 00 00 00 mov $0x0,%eax
5e: c9 leave
5f: c3 ret
In MinGW-w64 land, stdout appears to be a macro that expands to __imp____acrt_iob_func(1).
The standard output stream is retrieved through a function call, unlike with glibc where it is a direct data reference.
Well, that’s not how glibc does things at all. No mere symbol renaming can get us out of this mess, this means it’s time to shim:
#include <fcntl.h>
#include <stdio.h>
#include <stdarg.h>
#include <sys/stat.h>
#include <unistd.h>
void* stdin_placeholder;
void* stdout_placeholder;
void* stderr_placeholder;
static FILE* normalize_file(FILE* fp)
{
if ((void*)fp == &stdin_placeholder) {
fp = stdin;
} else if ((void*)fp == &stdout_placeholder) {
fp = stdout;
} else if ((void*)fp == &stderr_placeholder) {
fp = stderr;
}
return fp;
}
int fprintf_shim(FILE* fp, const char* fmt, ...)
{
va_list argptr;
va_start(argptr, fmt);
int ret = vfprintf(normalize_file(fp), fmt, argptr);
va_end(argptr);
return ret;
}
int fflush_shim(FILE* fp)
{
return fflush(normalize_file(fp));
}
Instead of aliasing a symbol directly to a native MinGW-w64 one, we’ll redirect them to ad hoc implementations. With functions in particular, this allows up to bridge the gap between two incompatible ABIs, for example by replacing placeholder values with the real ones before forwarding to the underlying implementation:
| Old symbol name | New name (MinGW-w64) |
|---|---|
stdin |
_stdin_placeholder |
stdout |
_stdout_placeholder |
stderr |
_stderr_placeholder |
_IO_fflush |
_fflush_shim |
_IO_fprintf |
_fprintf_shim |
At this point, the MinGW-w64 toolchain manages to link a Windows program:
$ file aln.o
aln.o: ELF 32-bit LSB relocatable, Intel 80386, invalid version (SYSV), not stripped
$ i686-linux-gnu-objcopy --redefine-syms=glibc-1xx-to-mingw32.syms aln.o aln.mingw32.o
$ i686-w64-mingw32-gcc -g -no-pie -fno-pic -o aln.exe aln.mingw32.o ctype.o FUN_0000fba0.c DAT_0001de20.c mingw32-shims.c
$ file aln.exe
aln.exe: PE32 executable (console) Intel 80386, for MS Windows
However, aln.exe can’t actually link the sample program from the Atari Jaguar community SDK:
$ rm -f jaghello.cof && make LINK="wine aln.exe" V=1
wine aln.exe -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
File read error on startup.o
Link aborted.
make: *** [Makefile:12: jaghello.cof] Error 1
After digging a bit, this is a triple case of subtle incompatibilities:
O_BINARY flag for open() to specify that we want to open a file in binary mode and aln doesn’t set it.
On Linux there is no difference between text mode and binary mode, but that’s not the case on Windows (the file isn’t read correctly).open() are different on Linux and MinGW-w64, leading to further problems down the road.
POSIX mandates the behavior of these constants, but does not actually mandate their values.Therefore, even though the function signatures of open() happen to be compatible between the two platforms, we still need to shim it to deal with these mismatches:
int open_shim(const char *filename, int oflag, int pmode)
{
int realoflag = (oflag & 00000003) | O_BINARY;
if (oflag & 00000100) {
realoflag = O_CREAT;
}
if (oflag & 00001000) {
realoflag = O_TRUNC;
}
if (oflag & 00002000) {
realoflag = O_APPEND;
}
return open(filename, realoflag, S_IREAD | S_IWRITE);
}
| Old symbol name | New name (MinGW-w64) |
|---|---|
open |
_open_shim |
Besides converting the bitflags, we’ll also fix the first issue by forcing O_BINARY in our shim.
Technically this is a bug in aln and this should be fixed at the source (or rather binary patched at the artifact in this case), but I’m not going to bother touching aln.o unless I have to.
After the last round of mutilations, we finally have our chimera up and running:
$ rm -f jaghello.cof && make LINK="wine aln.exe" V=1
wine aln.exe -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
Sizes: Text Data Bss Syms
(hex) 3C0 410 FA54 1C00
Link complete.
$ sha256sum jaghello.cof
f9c8269cdc998de01c0ac7a3e815c16b7ced106e25f10f92a7078c722a220dbb jaghello.cof
Who needs source code to make software ports anyways? Just throw the bits at the virtual address space and apply glue until everything sticks.
Yes, it does work on Windows too:
The files for this case study can be found here: case-study.tar.gz
We have ported aln from a Linux a.out executable to a native Windows PE executable.
This concludes this series of articles about how to leverage the delinking technique to make software ports without having access to the original source code.
Together with my series of series of articles on reverse-engineering, by now hopefully I have demonstrated that delinking is a powerful and practical technique for reverse-engineering. What was an obscure ritual mastered by few is now within reach of the everyday reverse-engineer, thanks to my Ghidra extension which automates the process of crafting object files from bits of programs down to a couple of mouse clicks.
]]>aln as a whole from a Linux a.out executable to a modern Linux ELF executable, aln.elf.
However, that executable still contains the old, glibc 1.xx C standard library aln was originally built with.
If we are to make more ambitious ports of aln, we need to get rid of it.
This time, rather than just basically repackaging aln from the a.out file format to ELF, we’ll swap out the C standard library aln was statically linked with a contemporary glibc 2.xx one.
To do so, instead of exporting the whole of aln as an object file (aln.whole.o) like we did previously, we’ll export aln without its C standard library bits (aln.o) instead, then link it as if it was a normal, everyday object file.
We’ll separate the different components of aln inside of a new program tree.
After creating folders and memory fragments, then triaging the program bits by dragging and dropping selections of the program into memory fragments, we end up with the following pieces:
Slicing up aln in that manner makes it easy to export each piece by right-clicking on a piece and selecting Select Addresses, then exporting the selection as an object file with my Ghidra extension, like in the previous part.
After exporting aln.o, we can inspect the undefined symbols for this object file with nm:
$ i686-linux-gnu-nm --undefined-only aln.o
U calloc
U close
U _ctype_b
U _ctype_tolower
U _ctype_toupper
U DAT_0001de20
U exit
U free
U FUN_0000fba0
U getenv
U index
U _IO_fflush
U _IO_fprintf
U _IO_gets
U _IO_printf
U longjmp
U lseek
U malloc
U memmove
U memset
U open
U puts
U read
U realloc
U rindex
U scanf
U _setjmp
U sprintf
U stderr
U stdout
U strcat
U strcmp
U strcpy
U strncmp
U strncpy
U write
If we can provide compatible replacements for every undefined symbol in this file, then aln.o will link successfully and should run, regardless of the provenance of these replacements.
For starters, let’s link aln.o statically as if this was a normal, everyday object file:
$ i686-linux-gnu-gcc -static -o aln.static.elf aln.o
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o: in function `FUN_00002824':
aln.o:(.text+0x1867): undefined reference to `_ctype_toupper'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o:(.text+0x1a42): undefined reference to `_ctype_toupper'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o:(.text+0x1b22): undefined reference to `_ctype_toupper'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o:(.text+0x1c02): undefined reference to `_ctype_toupper'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o:(.text+0x2194): undefined reference to `_ctype_toupper'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o:aln.o:(.text+0x2572): more undefined references to `_ctype_toupper' follow
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o: in function `main':
aln.o:(.text+0x3123): undefined reference to `FUN_0000fba0'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o: in function `FUN_00004bc4':
aln.o:(.text+0x3bce): undefined reference to `_ctype_b'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o: in function `FUN_00004c74':
aln.o:(.text+0x3c61): undefined reference to `_ctype_tolower'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.o:(.text+0x3c7e): undefined reference to `_ctype_b'
collect2: error: ld returned 1 exit status
make: *** [Makefile:11: aln.static.elf] Error 1
Well, it wouldn’t be worthy of a blog article if it was that simple…
We have several undefined references to fix:
_ctype_toupper, _ctype_tolower and _ctype_b are global variables, part of glibc’s 1.xx implementation of ctype.h ;FUN_0000fba0 is as far as I can tell an internal initialization function of the C standard library that is called from main for some reason.The first issue occurs because we’re trying to use glibc 2.xx from the host Linux system, yet aln was originally built with glibc 1.xx ; what we see here are the first signs of ABI mismatches, where the expectations of the original program don’t line up with its new environment.
Instead of fixing this at the source (which we don’t have), we’ll cheese it by stubbing out FUN_0000fba0 and borrowing the reconstructed ctype.o from aln into aln.elf:
$ cat FUN_0000fba0.c
void FUN_0000fba0() {
}
$ i686-linux-gnu-gcc -static -o aln.static.elf aln.o ctype.o FUN_0000fba0.c
$ file aln.static.elf
aln.static.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, BuildID[sha1]=004086f9962fe01ffdf12dab5f3c264773cf922b, for GNU/Linux 3.2.0, with debug_info, not stripped
We have a successful link!
We’re not aiming for purity here but rather pragmatism: as long as aln can be tricked into running successfully, anything goes.
Now that we have an aln.static.elf file, let’s try something simple like printing out the help message with debug mode on:
$ ./aln.static.elf -z -?
Option `?'
Segmentation fault (core dumped)
Hmm… It managed to write out some output, but it crashed fairly quickly.
Let’s see what’s happening with GDB:
$ gdb-multiarch --args ./aln.static.elf -z -?
...
Reading symbols from ./aln.static.elf...
(gdb) run
Starting program: /home/boricj/Documents/atari-sdk-elf/aln.static.elf -z -\?
Option `?'
Program received signal SIGSEGV, Segmentation fault.
0x0806d6e8 in fflush ()
(gdb) backtrace
#0 0x0806d6e8 in fflush ()
#1 0x0804b6b6 in ?? ()
#2 0x0804d005 in ?? ()
#3 0x08059528 in __libc_start_main ()
#4 0x08049ce2 in _start ()
(gdb)
GDB isn’t telling much, but we have a thread to pull on, fflush():
(gdb) break fflush
Breakpoint 1 at 0x806d674
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/boricj/Documents/atari-sdk-elf/aln.static.elf -z -\?
Option `?'
Breakpoint 1, 0x0806d674 in fflush ()
(gdb) x/4wx $ebp
0xffffd188: 0xffffd1d0 0x0804b6b6 0x08118bb0 0xffffd314
(gdb) info symbol 0x08118bb0
stdout in section .data of /home/boricj/Documents/atari-sdk-elf/aln.static.elf
(gdb) x/wx &stdout
0x8118bb0 <stdout>: 0x08118940
(gdb) x/wx (void*)stdout
0x8118940 <_IO_2_1_stdout_>: 0xfbad2a84
GDB isn’t providing much information, but we can recover what we need by hand.
With the standard calling convention on i386, the arguments to a function are passed on the stack.
They can be inspected using the frame pointer register, starting at $ebp+8.
fflush() takes a single FILE* argument and we can deduce that its raw value here is 0x08118bb0, a pointer to stdout.
Looking inside glibc’s source code, we can see that the opaque FILE structure from the C standard library is a typedef for the _IO_FILE structure private to glibc.
This structure begins with the magic number 0xFBAD.
The 32-bit word at 0x8118940 <_IO_2_1_stdout_> contains it, but the 32-bit word at 0x8118bb0 <stdout> is a pointer to the former.
Somehow, things got mixed up where a FILE** value was passed to fflush() instead of a FILE* as expected, which led to the segmentation fault.
To fix this, we need to rename the symbol stdout to _IO_2_1_stdout_ so that fflush() gets called with the correct value.
Rather than adjusting it inside the Ghidra database (whose contents are supposedly correct for an executable with glibc 1.xx), we’ll rename it after the fact with objcopy:
$ cat glibc-1xx-to-glibc-2xx.syms
stdin _IO_2_1_stdin_
stdout _IO_2_1_stdout_
stderr _IO_2_1_stderr_
$ i686-linux-gnu-objcopy --redefine-syms=glibc-1xx-to-glibc-2xx.syms aln.o aln.glibc20.o
$ i686-linux-gnu-gcc -g -static -no-pie -fno-pic -o aln.static.elf aln.glibc20.o ctype.o FUN_0000fba0.c
glibc-1xx-to-glibc-2xx.syms is a text file containing all symbols to redefine, one per line:
| Old symbol name | New name (glibc 2.xx) |
|---|---|
stdin |
_IO_2_1_stdin_ |
stdout |
_IO_2_1_stdout_ |
stderr |
_IO_2_1_stderr_ |
We’re trying to mend ABIs together that aren’t supposed to be compatible with one another. As noted above, anything goes as long as it runs, no matter how dubious the hacks are.
With that out of the way, let’s see if it made a difference:
$ ./aln.static.elf -z -?
Option `?'
Usage: ./aln.static.elf [-options] <files|-x file|-i[i] <fname> <label>>
Where options are:
?: print this
a <text> <data> <bss>: output absolute file
hex value: segment address
r: relocatable segment
x: contiguous segment
b: don't remove multiply defined local labels
d: wait for key after link
...
No object files to link.
Good, it’s no longer crashing. What about our nominal test case, linking the “Hello, world!” sample from the Atari Jaguar community SDK?
$ rm -f jaghello.cof && make LINK=aln.static.elf V=1
aln.static.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
make: *** [Makefile:12: jaghello.cof] Segmentation fault (core dumped)
Sigh.
It’s never that simple, is it?
Let’s run aln with the debug mode on to see what’s going on:
$ aln.static.elf -z -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
...
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
...
bsddoobj(startup.o,0x854f240,<none>)
bsdaddsyms for file startup.o
add_global(gSetOLP,startup.o,80,a200,GLOBAL)
...
add_global(_vidmem,startup.o,50,a100,GLOBAL)
add_unresolved(___main,startup.o)
bsddoobj(jag.o,0x8552420,<none>)
AlignSect: off=0X20, size=0X14C, align=0X10, padd=0x4
AlignSect: off=0X170, size=0X40C, align=0X10, padd=0x4
bsdaddsyms for file jag.o
add_global(_textfont,jag.o,0,a400,GLOBAL)
...
add_global(___main,jag.o,100,a200,GLOBAL)
Initialize symbols
add_local(_TEXT_E,(null))
...
add_global(_BSS_E,(null),0,a100,GLOBAL)
find_global(___main) => global in BSD object jag.o
DOUNRESOLVED
DOCOMMON
add_local(_jagscreen,(null))
DOSYM(startup.o)
add_local(DRAM,(null))
...
add_local(VC,(null))
Segmentation fault (core dumped)
It’s crashing in the middle of the linking process. What can GDB tell us?
$ gdb-multiarch --args aln.static.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
...
Reading symbols from aln.static.elf...
(gdb) r
Starting program: /home/boricj/Documents/atari-sdk-elf/aln.static.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
Program received signal SIGSEGV, Segmentation fault.
0x0804d801 in FUN_00004a04 ()
(gdb) bt
#0 0x0804d801 in FUN_00004a04 ()
#1 0x0805760f in ?? ()
#2 0x08057922 in ?? ()
#3 0x08057c7a in ?? ()
#4 0x0804d179 in LAB_00004388 ()
#5 0x08118000 in ?? ()
#6 0x08059528 in __libc_start_main ()
#7 0x08049ce2 in _start ()
(gdb)
Oh no.
It’s not crashing inside glibc, it’s crashing deep inside aln.
That means I have no obvious threads to pull on to figure this one out…
I’ll admit, this one’s got me stumped for quite a long time, chasing dead-ends one after another. I’ll skip ahead to the resolution.
FUN_00004a04() seems to be part of a hash table implementation and its decompilation contains the following line:
iVar1 = *(int *)(&DAT_0001de20 + (uVar2 & 0xff) * 4);
From this, we can assume that DAT_0001de20 is an array of 256 elements, each 4 bytes wide, for a total of 1024 bytes.
Say, what does that array contain?
(gdb) info address DAT_0001de20
Symbol "DAT_0001de20" is at 0x8065e20 in a file compiled without debugging.
(gdb) x/256wx 0x8065e20
0x8065e20 <DAT_0001de20>: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065e30: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065e40: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065e50: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065e60: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065e70: 0x00000000 0x08078ee0 0x00000000 0x00000000
0x8065e80: 0x00000000 0x00000000 0x00000000 0x08078e20
0x8065e90: 0x00000000 0x08078da0 0x00000000 0x08078f40
0x8065ea0: 0x00000000 0x00000000 0x08078ea0 0x00000000
0x8065eb0: 0x08078ec0 0x00000000 0x00000000 0x00000000
0x8065ec0: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065ed0: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065ee0: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065ef0: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065f00: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065f10: 0x00000000 0x00000000 0x08078d20 0x00000000
0x8065f20: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065f30: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065f40: 0x08078de0 0x00000000 0x00000000 0x00000000
0x8065f50: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065f60: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065f70: 0x00000000 0x00000000 0x00000000 0x08078e00
0x8065f80: 0x00000000 0x08078fa0 0x00000000 0x00000000
0x8065f90: 0x00000000 0x00000000 0x00000000 0x08078e80
0x8065fa0: 0x00000000 0x00000000 0x08078d40 0x08078fe0
0x8065fb0: 0x08078e60 0x00000000 0x08078000 0x00000000
0x8065fc0: 0x00000000 0x00000000 0x00000000 0x00000000
0x8065fd0: 0x00000000 0x00000000 0x00000000 0x08078f00
0x8065fe0: 0x08078dc0 0x00000000 0x00000000 0x00000000
0x8065ff0: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066000: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066010: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066020: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066030: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066040: 0x00000000 0x00000000 0x00000000 0x08078f20
0x8066050: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066060: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066070: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066080: 0x00000000 0x08078fc0 0x00000000 0x00000000
0x8066090: 0x00000000 0x00000000 0x00000000 0x00000000
0x80660a0: 0x00000000 0x00000000 0x00000000 0x00000000
0x80660b0: 0x00000000 0x00000000 0x00000000 0x00000000
0x80660c0: 0x08078e40 0x00000000 0x00000000 0x00000000
0x80660d0: 0x00000000 0x00000000 0x00000000 0x00000000
0x80660e0: 0x00000000 0x00000000 0x00000000 0x00000000
0x80660f0: 0x00000000 0x00000000 0x00000000 0x08078f60
0x8066100: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066110: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066120: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066130: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066140: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066150: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066160: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066170: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066180: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066190: 0x00000000 0x00000000 0x00000000 0x00000000
0x80661a0: 0x00000000 0x00000000 0x00000000 0x00000000
0x80661b0: 0x00000000 0x00000000 0x00000000 0x00000000
0x80661c0: 0x00000000 0x00000000 0x00000000 0x08078d60
0x80661d0: 0x00000000 0x00000000 0x00000000 0x00000000
0x80661e0: 0x00000000 0x00000000 0x00000000 0x00000000
0x80661f0: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066200: 0x00000000 0x00000000 0x00000000 0x00000000
0x8066210: 0x00000000 0x00000000 0x00000000 0x00000000
(gdb) info address DAT_0001de20
Symbol "DAT_0001de20" is at 0x8118600 in a file compiled without debugging.
(gdb) x/256wx 0x8118600
0x8118600 <DAT_0001de20>: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118610: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118620: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118630: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118640: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118650: 0x00000000 0x08124060 0x00000000 0x00000000
0x8118660: 0x00000000 0x00000000 0x00000000 0x08124040
0x8118670: 0x00000000 0x081245b0 0x00000000 0x08124590
0x8118680: 0x00000000 0x00000000 0x08124140 0x00000000
0x8118690: 0x08124120 0x00000000 0x00000000 0x00000000
0x81186a0: 0x00000000 0x00000000 0x00000000 0x00000000
0x81186b0: 0x00000000 0x00000000 0x00000000 0x00000000
0x81186c0: 0x00000000 0x00000000 0x00000000 0x00000000
0x81186d0: 0x00000000 0x00000000 0x00000000 0x00000000
0x81186e0: 0x00000000 0x00000000 0x00000000 0x00000000
0x81186f0: 0x00000000 0x00000000 0x08124080 0x00000000
0x8118700: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118710: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118720: 0x08124570 0x00000000 0x00000000 0x00000000
0x8118730: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118740: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118750: 0x00000000 0x00000000 0x00000000 0x08123fa0
0x8118760: 0x00000000 0x081245d0 0x00000000 0x00000000
0x8118770: 0x00000000 0x00000000 0x00000000 0x081241a0
0x8118780: 0x00000000 0x00000000 0x08124000 0x08124610
0x8118790: 0x08123f60 0x00000000 0x08123fc0 0x00000000
0x81187a0: 0x00000000 0x00000000 0x00000000 0x00000000
0x81187b0: 0x00000000 0x00000000 0x00000000 0x08124180
0x81187c0: 0x08123fe0 0x00000000 0x00000000 0x00000000
0x81187d0: 0x00000000 0x00000000 0x00000000 0x00000000
0x81187e0 <_ctype_b>: 0x080588e2 0x08058ae3 0x08058be4 0x080e32bc
0x81187f0 <__exit_funcs>: 0x0811a8e0 0x080e1b40 0x08118800 0x00000000
0x8118800 <_IO_2_1_stderr_>: 0xfbad2086 0x00000000 0x00000000 0x00000000
0x8118810 <_IO_2_1_stderr_+16>: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118820 <_IO_2_1_stderr_+32>: 0x00000000 0x00000000 0x00000000 0x08123f40
0x8118830 <_IO_2_1_stderr_+48>: 0x00000000 0x08118940 0x00000002 0x00000000
0x8118840 <_IO_2_1_stderr_+64>: 0xffffffff 0x00000000 0x0811ab04 0xffffffff
0x8118850 <_IO_2_1_stderr_+80>: 0xffffffff 0x00000000 0x081188a0 0x00000000
0x8118860 <_IO_2_1_stderr_+96>: 0x00000000 0x081241c0 0x00000000 0x00000000
0x8118870 <_IO_2_1_stderr_+112>: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118880 <_IO_2_1_stderr_+128>: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118890 <_IO_2_1_stderr_+144>: 0x00000000 0x08119980 0x00000000 0x00000000
0x81188a0 <_IO_wide_data_2>: 0x08124020 0x00000000 0x00000000 0x00000000
0x81188b0 <_IO_wide_data_2+16>: 0x00000000 0x00000000 0x00000000 0x00000000
0x81188c0 <_IO_wide_data_2+32>: 0x00000000 0x00000000 0x00000000 0x00000000
0x81188d0 <_IO_wide_data_2+48>: 0x00000000 0x00000000 0x00000000 0x08124160
0x81188e0 <_IO_wide_data_2+64>: 0x00000000 0x00000000 0x00000000 0x00000000
0x81188f0 <_IO_wide_data_2+80>: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118900 <_IO_wide_data_2+96>: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118910 <_IO_wide_data_2+112>: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118920 <_IO_wide_data_2+128>: 0x00000000 0x00000000 0x08119860 0x00000000
0x8118930: 0x00000000 0x00000000 0x00000000 0x00000000
0x8118940 <_IO_2_1_stdout_>: 0xfbad2a84 0x0811cdb0 0x0811cdb0 0x0811cdb0
0x8118950 <_IO_2_1_stdout_+16>: 0x0811cdb0 0x0811cdb0 0x0811cdb0 0x0811cdb0
0x8118960 <_IO_2_1_stdout_+32>: 0x0811d1b0 0x00000000 0x00000000 0x00000000
0x8118970 <_IO_2_1_stdout_+48>: 0x00000000 0x08118a80 0x00000001 0x00000000
0x8118980 <_IO_2_1_stdout_+64>: 0xffffffff 0x00000000 0x0811ab10 0xffffffff
0x8118990 <_IO_2_1_stdout_+80>: 0xffffffff 0x00000000 0x081189e0 0x00000000
0x81189a0 <_IO_2_1_stdout_+96>: 0x00000000 0x00000000 0xffffffff 0x081245f0
0x81189b0 <_IO_2_1_stdout_+112>: 0x00000000 0x00000000 0x00000000 0x00000000
0x81189c0 <_IO_2_1_stdout_+128>: 0x00000000 0x00000000 0x00000000 0x00000000
0x81189d0 <_IO_2_1_stdout_+144>: 0x00000000 0x08119980 0x00000000 0x00000000
0x81189e0 <_IO_wide_data_1>: 0x00000000 0x00000000 0x00000000 0x00000000
0x81189f0 <_IO_wide_data_1+16>: 0x00000000 0x00000000 0x00000000 0x00000000
Whereas aln.elf seems in good order, inside aln.static.elf this array appears to be truncated at 480 bytes, with unrelated variables following it.
However, aln’s code still assumed it was 1024 bytes long, so these variables were overwritten until that memory corruption led to a segmentation fault.
How come DAT_0001de20 was truncated in aln.static.elf and not in aln.elf?
That array was originally located inside aln from 0x1de20 to 0x1e21f.
However, the .data segment stops at 0x1dfff and the .bss segment begins at 0x1e000.
As far as I can tell, that variable is laid across two sections.
I might not give a damn about computer engineering conventions in this series of articles, but so did toolchains in the 90’s apparently.
(╯°□°)╯︵ ┻━┻
When the aln.o object file got exported, these two sections became untethered.
Later on, the linker didn’t place these bits next to each other, splitting that variable in two, effectively truncating it down to 480 bytes.
That was a fun one to track down.
So, let’s excise that problematic array from aln.o and substitute it with a clean stub:
$ cat DAT_0001de20.c
int DAT_0001de20[256];
$ i686-linux-gnu-gcc -g -static -no-pie -fno-pic -o aln.static.elf aln.glibc20.o ctype.o FUN_0000fba0.c DAT_0001de20.c
We don’t care about the type of DAT_0001de20, we only want it to be at least 1024 bytes long.
Unlike a compiler, a traditional linker only processes symbol names and doesn’t care about typing information.
Please work this time…
$ rm -f jaghello.cof && aln.static.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
Sizes: Text Data Bss Syms
(hex) 3C0 410 FA54 1C00
Link complete.
$ sha256sum jaghello.cof
f9c8269cdc998de01c0ac7a3e815c16b7ced106e25f10f92a7078c722a220dbb jaghello.cof
Finally, aln lives on with a transplanted C standard library from the 21st century and it only took the better part of my sanity.
Despite all this nonsense, it wasn’t as bad as it could be.
In particular, aln doesn’t use errno, which was a static variable in the old days and is a thread-local one nowadays.
These two storage schemes are mutually incompatible.
There are ways to work around this problem, but thankfully I didn’t have to deal with this nonsense here.
We’ve swapped a C standard library with another, how about removing it altogether from the executable? We can do so by dynamically linking it:
$ i686-linux-gnu-gcc -g -no-pie -fno-pic -o aln.dynamic.elf aln.glibc20.o ctype.o FUN_0000fba0.c DAT_0001de20.c
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: aln.glibc20.o: warning: relocation against `_IO_2_1_stderr_@@GLIBC_2.1' in read-only section `.text'
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: warning: creating DT_TEXTREL in a PIE
$ file aln.dynamic.elf
aln.dynamic.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=d6aabe004514845f6530384228f12741aa87dbc1, for GNU/Linux 3.2.0, with debug_info, not stripped
The linker isn’t very happy about it, but it did spat out an executable. Let’s try it out:
$ rm -f jaghello.cof && aln.dynamic.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
Sizes: Text Data Bss Syms
(hex) 3C0 410 FA54 1C00
Link complete.
$ sha256sum jaghello.cof
f9c8269cdc998de01c0ac7a3e815c16b7ced106e25f10f92a7078c722a220dbb jaghello.cof
It worked out of the box? Well, after dealing with all these shenanigans previously it better be!
The files for this case study can be found here: case-study.tar.gz
We have delinked aln back into a standard object file without its C standard library, then produced both statically and dynamically linked versions of aln using contemporary versions of glibc.
Next time, we’ll attempt our most ambitious port yet: turning aln from a Linux program into a native Windows executable.
aln with a closely matching C static library from Slackware 2.3.
In this article, we will start making software ports of aln, despite not having the source code for it.
Currently, aln is a statically-linked Linux a.out executable for Linux.
For our first port, we’ll aim for something small: a statically-linked Linux ELF executable for Linux.
Since I want this part to be meaningful and not just stick an ELF header and call it a day, I’ll place another restriction: it must work as-is on modern Linux systems.
Recall in part one that to run aln nowadays we must sysctl -w vm.mmap_min_addr=4096 to get it to run.
This is because modern Linux systems have a minimum virtual address for user processes configured by default to 0x10000, whereas aln is based at the lower address 0x1000.
To fulfill the stated restriction for the ELF port, it must be based at a higher address than aln currently is.
Simply moving the bits of aln around in the address space will end in disaster: references to absolute addresses embedded within aln would not shift around with the bits, leading to incorrect memory accesses and most likely crashes.
To work around the problem of absolute references, we’ll use a technique described in my previous series of articles on reverse-engineering: delinking aln back into an object file so that we can then relink it however we want.
This solves the issue because references to absolute addresses will be converted to relocations as part of this process and the linker is going to stitch everything back together, as if nothing happened.
Continuing from the previous part, we have a partially analyzed artifact. After some further work on it (annotating things, fixing up incorrectly identified references…), we are ready for our first attempt at delinking it with the help of my Ghidra extension.
Select the address ranges 0x1020 to 0x1e993 (the entire aln program without the a.out header), then click on Analysis > One shot > Relocation Table Analyzer.
Click on Window > Relocation Table (synthesized) to view the reconstructed relocations:
We have all the data we need to make an object file out of aln.
Click on File > Export Program... (or hit the O key), and fill in the wizard as follows:
ELF relocatable object ;aln.whole.o ;Furthermore, click on Options... and ensure that Include dynamic symbols and Strip leading underscore are checked:
Click on OK and the object file will be written to disk.
We can inspect that object file using our toolchain:
$ readelf --wide --file-header aln.whole.o
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Intel 80386
Version: 0x0
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 52 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 9
Section header string table index: 8
$ readelf --wide --section-headers aln.whole.o
There are 9 section headers, starting at offset 0x34:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .strtab STRTAB 00000000 00019c 00e9cd 00 0 0 1
[ 2] .symtab SYMTAB 00000000 00eb6c 00eeb0 10 1 155 4
[ 3] .text PROGBITS 00000000 01da20 01bfe0 00 WAX 0 0 16
[ 4] .data PROGBITS 00000000 039a00 001000 00 WA 0 0 16
[ 5] .bss NOBITS 00000000 000000 000994 00 WA 0 0 16
[ 6] .rel.text REL 00000000 03aa00 005c10 08 I 2 3 4
[ 7] .rel.data REL 00000000 040610 000268 08 I 2 4 4
[ 8] .shstrtab STRTAB 00000000 040878 000040 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
p (processor specific)
$ readelf --wide --symbols aln.whole.o
Symbol table '.symtab' contains 3819 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS aln.whole.o
2: 00000000 0 SECTION LOCAL DEFAULT 3
3: 00000000 0 SECTION LOCAL DEFAULT 4
4: 00000000 0 SECTION LOCAL DEFAULT 5
5: 000018cf 7 OBJECT LOCAL DEFAULT 3 switchD_000028ef::switchD
6: 000018e4 4 OBJECT LOCAL DEFAULT 3 switchD_000028ef::switchdataD_00002904
7: 00001984 3 OBJECT LOCAL DEFAULT 3 switchD_000028ef::caseD_3f
8: 000019a4 3 OBJECT LOCAL DEFAULT 3 switchD_000028ef::caseD_5a
9: 000019d4 3 OBJECT LOCAL DEFAULT 3 switchD_000028ef::caseD_41
10: 00001cf4 3 OBJECT LOCAL DEFAULT 3 switchD_000028ef::caseD_42
...
3808: 000008d8 1 OBJECT GLOBAL DEFAULT 5 DAT_0001e8d8
3809: 000008e0 1 OBJECT GLOBAL DEFAULT 5 __malloc_initialized
3810: 000008e4 1 OBJECT GLOBAL DEFAULT 5 DAT_0001e8e4
3811: 000008e8 4 OBJECT GLOBAL DEFAULT 5 DAT_0001e8e8
3812: 000008f0 1 OBJECT GLOBAL DEFAULT 5 DAT_0001e8f0
3813: 00000920 96 OBJECT GLOBAL DEFAULT 5 _fraghead
3814: 00000928 4 OBJECT GLOBAL DEFAULT 5 _fraghead[1].next
3815: 00000980 4 OBJECT GLOBAL DEFAULT 5 __malloc_hook
3816: 00000984 4 OBJECT GLOBAL DEFAULT 5 DAT_0001e984
3817: 00000988 4 OBJECT GLOBAL DEFAULT 5 DAT_0001e988
3818: 00000990 4 OBJECT GLOBAL DEFAULT 5 DAT_0001e990
$ readelf --wide --relocs aln.whole.o
Relocation section '.rel.text' at offset 0x3aa00 contains 2946 entries:
Offset Info Type Sym. Value Symbol's Name
00000012 000e3401 R_386_32 00000064 DAT_0001d064
0000001b 000e3501 R_386_32 00000068 DAT_0001d068
00000022 000e3601 R_386_32 0000006c DAT_0001d06c
00000568 000e1e01 R_386_32 00000004 PTR_s_aln_0001d004
0000056e 00009f01 R_386_32 0000005b s_Usage:_%s_[-options]_<files|-x_f_0000107b
00000578 0000a001 R_386_32 00000097 s_Where_options_are:_000010b7
00000582 0000a101 R_386_32 000000aa s_?:_print_this_000010ca
...
It has sections, symbols and relocations, like any other object file produced through more conventional means.
Let’s try making an executable out of aln.whole.o.
Since this object file is a whole program, we need to build it statically with no extra libraries whatsoever:
$ i686-linux-gnu-gcc -nostdlib -nostartfiles -e_entry -static -o aln.elf aln.whole.o
Again, we can inspect the executable with the toolchain:
$ readelf --wide --file-header aln.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x8049000
Start of program headers: 52 (bytes into file)
Start of section headers: 243928 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 4
Size of section headers: 40 (bytes)
Number of section headers: 8
Section header string table index: 7
$ readelf --wide --section-headers aln.elf
There are 8 section headers, starting at offset 0x3b8d8:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .note.gnu.build-id NOTE 080480b4 0000b4 000024 00 A 0 0 4
[ 2] .text PROGBITS 08049000 001000 01bfe0 00 AX 0 0 16
[ 3] .data PROGBITS 08065000 01d000 001000 00 WA 0 0 16
[ 4] .bss NOBITS 08066000 01e000 000994 00 WA 0 0 16
[ 5] .symtab SYMTAB 00000000 01e000 00eef0 10 6 156 4
[ 6] .strtab STRTAB 00000000 02cef0 00e9a6 00 0 0 1
[ 7] .shstrtab STRTAB 00000000 03b896 00003f 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
p (processor specific)
$ readelf --wide --symbols aln.elf | head -n 20
Symbol table '.symtab' contains 3823 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 080480b4 0 SECTION LOCAL DEFAULT 1
2: 08049000 0 SECTION LOCAL DEFAULT 2
3: 08065000 0 SECTION LOCAL DEFAULT 3
4: 08066000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 FILE LOCAL DEFAULT ABS aln.whole.o
6: 0804a8cf 7 OBJECT LOCAL DEFAULT 2 switchD_000028ef::switchD
7: 0804a8e4 4 OBJECT LOCAL DEFAULT 2 switchD_000028ef::switchdataD_00002904
8: 0804a984 3 OBJECT LOCAL DEFAULT 2 switchD_000028ef::caseD_3f
9: 0804a9a4 3 OBJECT LOCAL DEFAULT 2 switchD_000028ef::caseD_5a
10: 0804a9d4 3 OBJECT LOCAL DEFAULT 2 switchD_000028ef::caseD_41
...
3812: 080518d8 10 OBJECT GLOBAL DEFAULT 2 LAB_000098f8
3813: 08052808 3 OBJECT GLOBAL DEFAULT 2 LAB_0000a828
3814: 0804d330 3 OBJECT GLOBAL DEFAULT 2 LAB_00005350
3815: 080642e4 1 OBJECT GLOBAL DEFAULT 2 LAB_0001c304
3816: 0806400c 3 OBJECT GLOBAL DEFAULT 2 LAB_0001c02c
3817: 08063a0a 7 OBJECT GLOBAL DEFAULT 2 LAB_0001ba2a
3818: 080566ee 2 OBJECT GLOBAL DEFAULT 2 LAB_0000e70e
3819: 0805c375 2 OBJECT GLOBAL DEFAULT 2 LAB_00014395
3820: 08055b2c 179 FUNC GLOBAL DEFAULT 2 FUN_0000db4c
3821: 080593a7 3 OBJECT GLOBAL DEFAULT 2 LAB_000113c7
3822: 08055e98 1 OBJECT GLOBAL DEFAULT 2 LAB_0000deb8
$ readelf --wide --relocs aln.elf
There are no relocations in this file.
We can observe that its base address (automatically set by the toolchain) is now 0x0x8049000, fulfilling our minimum virtual address space requirement of 0x10000 or higher.
We can also see that the symbols, whose names include the original addresses from the a.out layout, are shifted from their initial locations.
Let’s take aln.elf for a spin:
$ rm -f jaghello.cof && make LINK=aln.elf V=1
aln.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
make: *** [Makefile:12: jaghello.cof] Segmentation fault (core dumped)
… and it crashed immediately.
Let’s run aln.elf under GDB:
$ gdb --args aln.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from aln.elf...
(No debugging symbols found in aln.elf)
(gdb) r
Starting program: /home/boricj/Documents/atari-sdk-elf/aln.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
Program received signal SIGSEGV, Segmentation fault.
0x08058f6b in strncmp ()
(gdb) bt
#0 0x08058f6b in strncmp ()
#1 0x08058db2 in getenv ()
#2 0x0804c199 in main ()
(gdb)
The program crashed while doing some sort of processing with environment variables. The fun part of getting this port to run begins now.
Linux initializes the process differently between an a.out and an ELF executable: the latter is set up per the ELF i386 psABI specification. The relevant part is the differences in stack layout: for a.out executables, the Linux kernel used to set it up as-if the entrypoint is a C function with this signature that was just called:
[[noreturn]] void _start(int argc, char** argv, char** environ);
Needless to say, the ELF i386 psABI specification mandates something completely different, which is why aln.elf is crashing due to the ABI mismatch.
The ELF entrypoint therefore needs to shuffle things around before it can jump into the a.out entrypoint.
The following assembly snippet is one way to implement it:
.text
.global _start
_start:
xor %ebp, %ebp # Terminate the call stack chain.
mov %esp, %eax # Save the old stack pointer for later.
and $-16, %esp # Align the stack to 16 bytes 'cause we can.
mov (%eax), %ebx # Get argc from the old stack.
lea 4(%eax), %esi # Get argv from the old stack.
lea 8(%eax, %ebx, 4), %edi # Get environ from the old stack.
push %edi # Push arguments in reverse order,
push %esi # per the System-V i386 calling
push %ebx # convention.
jmp _entry # Jump into the a.out entrypoint.
Now, let’s fast-forward a bit the process of fixing aln.elf crashes until aln.elf doesn’t crash anymore:
$ i686-linux-gnu-gcc -nostdlib -nostartfiles -e_start -static -o aln.elf aln.whole.o crt0.S
$ rm -f jaghello.cof && make LINK=aln.elf V=1
aln.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
/home/boricj/Documents/jaguar-sdk/jaguar/examples/jaghello/startup.s(1): Unresolved reference: in BSD object startup.o, symbol ___main
(@T+0X106): Unresolved reference: in BSD object jag.o, symbol _vidmem
Sizes: Text Data Bss Syms
(hex) 3C0 410 FA50 1C0E
Link complete.
$ file jaghello.cof
jaghello.cof: mc68k COFF object not stripped
$ sha256sum jaghello.cof
dfe2d010a3b526bc3d9e573016b614d0bfd0b382bca004a4a42f7e8a89a22c29 jaghello.cof
This time aln.elf didn’t crash, but it has a different observable behavior than the original one and the SHA-256 hash of jaghello.cof doesn’t match the one from part 1…
Since aln didn’t crash, we don’t have an obvious spot to analyze with a debugger.
Fortunately, we do have the original aln we can run and cross-check our port with.
All we need to do is to compare two different programs as they execute and find out where they start behaving differently and why.
One little-known feature of GDB is the ability to do time travel debugging, in another words to step backwards. To do so, GDB records the side-effects of instructions as they execute: stepping backwards can then be achieved by unapplying those side-effects in reverse. We’re not interested in time-travelling debugging here, but rather in multi-dimentional diffing.
We’ll use GDB to make and save the recordings.
For this to work, we need to replicate the same conditions between the two runs as close as possible, like command lines, environment variables…
The recordings are also started in both cases from _entry onwards, the original entrypoint from the a.out executable:
$ rm -f jaghello.cof && gdb-multiarch --args aout-loader aln -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from aout-loader...
(No debugging symbols found in aout-loader)
(gdb) starti
Starting program: /home/boricj/Documents/jaguar-sdk/tools/bin/aout-loader aln -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
Program stopped.
0xf7fe4490 in ?? () from /lib/ld-linux.so.2
(gdb) hb *0x1020
Hardware assisted breakpoint 1 at 0x1020
(gdb) c
Continuing.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, 0x00001020 in ?? ()
(gdb) set record full insn-max-instructions unlimited
Undefined set record full command: "insn-max-instructions unlimited". Try "help set record full".
(gdb) set record full insn-number-max unlimited
(gdb) record full
(gdb) c
Continuing.
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
Sizes: Text Data Bss Syms
(hex) 3C0 410 FA54 1C00
Link complete.
The next instruction is syscall exit. It will make the program exit. Do you want to stop the program?([y] or n) y
Process record: inferior program stopped.
Program stopped.
0x00011e64 in ?? ()
(gdb) record save aln.record
warning: target file /proc/11340/cmdline contained unexpected null characters
Saved core file aln.record with execution log.
$ rm -f jaghello.cof && gdb-multiarch --args aln.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from aln.elf...
(No debugging symbols found in aln.elf)
(gdb) b _entry
Breakpoint 1 at 0x8049000
(gdb) r
Starting program: /home/boricj/Documents/jaguar-sdk/jaguar/bin/linux/aln.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
Breakpoint 1, 0x08049000 in _entry ()
(gdb) set record full insn-number-max unlimited
(gdb) record full
(gdb) c
Continuing.
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
/home/boricj/Documents/jaguar-sdk/jaguar/examples/jaghello/startup.s(1): Unresolved reference: in BSD object startup.o, symbol ___main
(@T+0X106): Unresolved reference: in BSD object jag.o, symbol _vidmem
Sizes: Text Data Bss Syms
(hex) 3C0 410 FA50 1C0E
Link complete.
The next instruction is syscall exit. It will make the program exit. Do you want to stop the program?([y] or n) y
Process record: inferior program stopped.
Program stopped.
0x08059e44 in _exit ()
(gdb) record save aln.elf.record
warning: target file /proc/17807/cmdline contained unexpected null characters
Saved core file aln.elf.record with execution log.
We have two recordings (weighing over 30 MiB each), but we don’t have a tool to compare them. It is time to improvise: we’ll hack support for the precord format produced by GDB into pyelftools, a Python package for manipulating ELF files, then write a script to make the comparison:
diff --git a/elftools/elf/elffile.py b/elftools/elf/elffile.py
index 446d970..5074cb1 100644
--- a/elftools/elf/elffile.py
+++ b/elftools/elf/elffile.py
@@ -30,7 +30,8 @@ from .structs import ELFStructs
from .sections import (
Section, StringTableSection, SymbolTableSection,
SymbolTableIndexSection, SUNWSyminfoTableSection, NullSection,
- NoteSection, StabSection, ARMAttributesSection, RISCVAttributesSection)
+ NoteSection, StabSection, ARMAttributesSection, RISCVAttributesSection,
+ PrecordSection)
from .dynamic import DynamicSection, DynamicSegment
from .relocation import (RelocationSection, RelocationHandler,
RelrRelocationSection)
@@ -661,6 +662,8 @@ class ELFFile(object):
return NoteSection(section_header, name, self)
elif sectype == 'SHT_PROGBITS' and name == '.stab':
return StabSection(section_header, name, self)
+ elif sectype == 'SHT_PROGBITS' and name == 'precord':
+ return PrecordSection(section_header, name, self)
elif sectype == 'SHT_ARM_ATTRIBUTES':
return ARMAttributesSection(section_header, name, self)
elif sectype == 'SHT_RISCV_ATTRIBUTES':
diff --git a/elftools/elf/sections.py b/elftools/elf/sections.py
index 3805962..16ac706 100644
--- a/elftools/elf/sections.py
+++ b/elftools/elf/sections.py
@@ -6,12 +6,13 @@
# Eli Bendersky (eliben@gmail.com)
# This code is in the public domain
#-------------------------------------------------------------------------------
-from ..common.exceptions import ELFCompressionError
+from ..common.exceptions import ELFCompressionError, ELFParseError
from ..common.utils import struct_parse, elf_assert, parse_cstring_from_stream
from collections import defaultdict
from .constants import SH_FLAGS
from .notes import iter_notes
+import struct
import zlib
@@ -278,6 +279,79 @@ class NoteSection(Section):
"""
return iter_notes(self.elffile, self['sh_offset'], self['sh_size'])
+class PrecordEnd(object):
+ """ PrecordEnd object - representing the end of a precord list.
+ """
+ def __init__(self, signal, count):
+ self.signal = signal
+ self.count = count
+
+ def __repr__(self):
+ s = '<%s: signal=0x%08x count=%d>' % \
+ (self.__class__.__name__, self.signal, self.count)
+ return s
+
+class PrecordReg(object):
+ """ PrecordReg object - representing a register inside a precord list.
+ """
+ def __init__(self, number, name, value, length):
+ self.number = number
+ self.name = name
+ self.value = value
+ self.length = length
+
+ def __repr__(self):
+ s = '<%s (%s): 0x%s>' % \
+ (self.__class__.__name__, self.name, hex(self.value)[2:].zfill(self.length * 2))
+ return s
+
+
+class PrecordMem(object):
+ """ PrecordMem object - representing a memory write a precord list.
+ """
+ def __init__(self, memlen, memaddr, memval):
+ self.memlen = memlen
+ self.memaddr = memaddr
+ self.memval = memval
+
+ def __repr__(self):
+ s = '<%s (%016x, %d): 0x%s>' % \
+ (self.__class__.__name__, self.memaddr, self.memlen, hex(self.memval)[2:].zfill(self.memlen * 2))
+ return s
+
+class PrecordSection(Section):
+ """ GDB program record section.
+ """
+ def iter_precords(self, parse_reg, byteorder):
+ """ Yield all precord entries. Result types are precord objects.
+ """
+ offset = self['sh_offset']
+ size = self['sh_size']
+ end = offset + size
+
+ self.stream.seek(offset)
+ magic = struct.unpack('!I', self.stream.read(4))[0]
+
+ if magic != 0x20091016:
+ raise ELFParseError("Unknown precord magic %08x" % magic)
+
+ while self.stream.tell() < end:
+ record_type = struct.unpack('!B', self.stream.read(1))[0]
+
+ if record_type == 0x00:
+ signal, count = struct.unpack('!II', self.stream.read(8))
+ yield PrecordEnd(signal, count)
+ elif record_type == 0x01:
+ regnum = struct.unpack('!I', self.stream.read(4))[0]
+ regname, regval, reglength = parse_reg(regnum, self.stream)
+ yield PrecordReg(regnum, regname, int.from_bytes(regval, byteorder), reglength)
+ elif record_type == 0x02:
+ memlen, memaddr = struct.unpack('!IQ', self.stream.read(12))
+ memval = self.stream.read(memlen)
+ yield PrecordMem(memlen, memaddr, int.from_bytes(memval, byteorder))
+ else:
+ raise ELFParseError("Unknown precord type %02x" % record_type)
+
class StabSection(Section):
""" ELF stab section.
#!/usr/bin/env python
import argparse
from elftools.elf.elffile import ELFFile
from elftools.elf.sections import PrecordReg, PrecordEnd
PRECORD_NAME = 'precord'
def parse_reg_i386(regnum, stream):
# Taken from binutils-gdb/gdb/features/i386/32bit-core.xml
regnames=[
"eax", "ecx", "edx", "ebx",
"esp", "ebp", "esi", "edi",
"eip", "eflags", "cs", "ss",
"ds", "es", "fs", "gs",
"st0", "st1", "st2", "st3",
"st4", "st5", "st6", "st7",
"fctrl", "fstat", "ftag", "fiseg",
"fioff", "foseg", "fooff", "fop"
]
regsizes=[
4, 4, 4, 4,
4, 4, 4, 4,
4, 4, 4, 4,
4, 4, 4, 4,
10, 10, 10, 10,
10, 10, 10, 10,
4, 4, 4, 4,
4, 4, 4, 4
]
return regnames[regnum], stream.read(regsizes[regnum]), regsizes[regnum]
class AddressMapping:
def __init__(self, spec):
parts = spec.split(':')
self.source = int(parts[0], 16)
self.destination = int(parts[1], 16)
self.length = int(parts[2], 16)
def map_address(addr, mappings):
for mapping in mappings:
if addr >= mapping.source and addr < (mapping.source + mapping.length):
return addr - mapping.source + mapping.destination
return addr
def main():
argparser = argparse.ArgumentParser()
argparser.add_argument('precord', nargs=2, default=None, help='Record files to compare')
argparser.add_argument('-m', '--mapping', nargs='*', type=AddressMapping, dest='mappings', default=[])
argparser.add_argument('-r', '--check-register-mappings', nargs='*', type=str, dest='registers_mappings', default=[])
args = argparser.parse_args()
with open(args.precord[0], 'rb') as file1:
with open(args.precord[1], 'rb') as file2:
elffile1 = ELFFile(file1)
elffile2 = ELFFile(file2)
section1 = elffile1.get_section_by_name(PRECORD_NAME)
iter_precords1 = section1.iter_precords(parse_reg_i386, 'little')
section2 = elffile2.get_section_by_name(PRECORD_NAME)
iter_precords2 = section2.iter_precords(parse_reg_i386, 'little')
registers1 = dict()
registers2 = dict()
for record1, record2 in zip(iter_precords1, iter_precords2):
print("%-79s %s" % (record1, record2))
if type(record1) != type(record2):
print("Record type divergence")
break
elif type(record1) == PrecordEnd:
if record1.count != record2.count:
print("End record count divergence")
break
elif type(record1) == PrecordReg:
if record1.name != record2.name:
print("Register name divergence")
break
registers1[record1.name] = record1.value
registers2[record2.name] = record2.value
if record1.name in args.registers_mappings:
mapped_value = map_address(record1.value, args.mappings)
if mapped_value != record2.value:
print("Register value divergence (0x%016x -> 0x%016x != 0x%016x)" % (record1.value, mapped_value, record2.value))
break
if __name__ == '__main__':
main()
Maybe there are easier, off-the-shelf ways to do this kind of behavioral difference analysis between dissimilar programs, but I don’t know of one.
Let’s try it out:
$ PYTHONPATH=${HOME}/Documents/pyelftools python3 ./precordcompare.py ${JAGHELLO}/aln.record ${JAGHELLO}/aln.elf.record --check-register-mappings eip
<PrecordReg (esp): 0xf7d8bf24> <PrecordReg (esp): 0xffffce90>
<PrecordMem (00000000f7d8bf24, 4): 0x00001025> <PrecordMem (00000000ffffce90, 4): 0x08049005>
<PrecordReg (eip): 0x0000fd4c> <PrecordReg (eip): 0x08057d2c>
Register value divergence (0x000000000000fd4c -> 0x000000000000fd4c != 0x0000000008057d2c)
…and it diverged immediately.
Another tricky point is that we’re trying to compare two execution traces across two different programs, who don’t have the same memory layout.
aln was delinked and relinked as a whole, so the meat of it is essentially the same but moved at a different virtual address.
We’ll account for this by adding mappings from one address space to another:
$ PYTHONPATH=${HOME}/Documents/pyelftools python3 ./recordcompare.py ${JAGHELLO}/aln.record ${JAGHELLO}/aln.elf.record --mapping 0x1020:0x08049000:0x01e973 --check-register-mappings eip
<PrecordReg (esp): 0xf7d8bf24> <PrecordReg (esp): 0xffffce90>
<PrecordMem (00000000f7d8bf24, 4): 0x00001025> <PrecordMem (00000000ffffce90, 4): 0x08049005>
<PrecordReg (eip): 0x0000fd4c> <PrecordReg (eip): 0x08057d2c>
<PrecordEnd: signal=0x00000000 count=1> <PrecordEnd: signal=0x00000000 count=1>
<PrecordReg (esp): 0xf7d8bf20> <PrecordReg (esp): 0xffffce8c>
<PrecordMem (00000000f7d8bf20, 4): 0xffffcdd8> <PrecordMem (00000000ffffce8c, 4): 0x00000000>
<PrecordReg (eip): 0x0000fd4d> <PrecordReg (eip): 0x08057d2d>
<PrecordEnd: signal=0x00000000 count=2> <PrecordEnd: signal=0x00000000 count=2>
...
<PrecordReg (esp): 0xf7d8be0c> <PrecordReg (esp): 0xffffcd78>
<PrecordReg (eflags): 0x00000286> <PrecordReg (eflags): 0x00000286>
<PrecordReg (eip): 0x00009da3> <PrecordReg (eip): 0x08051d83>
<PrecordEnd: signal=0x00000000 count=215180> <PrecordEnd: signal=0x00000000 count=215180>
<PrecordReg (eax): 0x5656a200> <PrecordReg (eax): 0x0807a200>
<PrecordReg (eip): 0x00009da7> <PrecordReg (eip): 0x08051d87>
<PrecordEnd: signal=0x00000000 count=215181> <PrecordEnd: signal=0x00000000 count=215181>
<PrecordReg (eax): 0x56562000> <PrecordReg (eax): 0x08070000>
<PrecordReg (eflags): 0x00000206> <PrecordReg (eflags): 0x00000246>
<PrecordReg (eip): 0x00009dab> <PrecordReg (eip): 0x08051d8b>
<PrecordEnd: signal=0x00000000 count=215182> <PrecordEnd: signal=0x00000000 count=215182>
<PrecordReg (eflags): 0x00000246> <PrecordReg (eflags): 0x00000287>
<PrecordReg (eip): 0x00009daf> <PrecordReg (eip): 0x08051d8f>
<PrecordEnd: signal=0x00000000 count=215183> <PrecordEnd: signal=0x00000000 count=215183>
<PrecordReg (eip): 0x00009e28> <PrecordReg (eip): 0x08051d91>
Register value divergence (0x0000000000009e28 -> 0x0000000008051e08 != 0x0000000008051d91)
Aha!
We have an instruction pointer divergence.
Looking backwards at the previous instruction pointer values (0x9e28, 0x9daf, 0x9dab, 0x9da7), we stumble upon the smoking gun, a bad reference:
Finally, by cross-referencing the raw disassembly of the artifacts at hand we can piece together what happened in detail:
$ i686-linux-gnu-objdump -D -b binary -m i386 --adjust-vma=0x1000 aln
...
9da0: 83 c4 10 add $0x10,%esp
9da3: 66 8b 45 fe mov -0x2(%ebp),%ax
9da7: 66 25 00 28 and $0x2800,%ax
9dab: 66 3d 00 20 cmp $0x2000,%ax
9daf: 74 77 je 0x9e28
...
$ i686-linux-gnu-objdump -Dr aln.whole.o
...
8d80: 83 c4 10 add $0x10,%esp
8d83: 66 8b 45 fe mov -0x2(%ebp),%ax
8d87: 66 25 06 00 and $0x6,%ax
8d89: R_386_NONE s_-x:_not_enough_arguments_000027fa
8d8b: 66 3d 00 20 cmp $0x2000,%ax
8d8f: 74 77 je 8e08 <LAB_00009e28>
...
$ i686-linux-gnu-objdump -D aln.elf
...
8051d80: 83 c4 10 add $0x10,%esp
8051d83: 66 8b 45 fe mov -0x2(%ebp),%ax
8051d87: 66 25 06 00 and $0x6,%ax
8051d8b: 66 3d 00 20 cmp $0x2000,%ax
8051d8f: 74 77 je 8051e08 <LAB_00009e28>
...
0x2800 of the instruction and ax, 0x2800 was misidentified as an address during Ghidra’s static analysis ;s_t_enough_arguments_000027fa at this location in the Ghidra database ;aln.whole.o and the linkage of aln.elf ;aln.elf.Whew!
That was quite the journey to track this down.
The fix here is to remove the bogus references by clicking on it and hitting the Delete key (or right-cliking it and selecting Delete Memory References), so that it doesn’t end up corrupting the exported object file.
After another round of debugging aln.elf, we finally end up with the following:
$ rm -f jaghello.cof && make LINK=aln.elf V=1
aln.elf -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
Sizes: Text Data Bss Syms
(hex) 3C0 410 FA54 1C00
Link complete.
$ file jaghello.cof
jaghello.cof: mc68k COFF object not stripped
$ sha256sum jaghello.cof
f9c8269cdc998de01c0ac7a3e815c16b7ced106e25f10f92a7078c722a220dbb jaghello.cof
We have reproduced jaghello.cof identically with out newly-minted aln.elf port, as per the requirements laid out in part 1.
The files for this case study can be found here: case-study.tar.gz
We have successfully ported the whole of aln from a Linux a.out executable to a modern Linux ELF executable.
Next time, we’ll rip out the old C standard library embedded within aln and twist it further away from its roots.
aln, an executable artifact in the traditional Unix a.out format, despite Ghidra not offering support for this particular file format.
In this article, we will start reverse-engineering aln with the intent to port it to new environments.
In order to make software ports of aln, we will need some level of understanding on how it is put together.
The aln executable itself is about 116 KiB in size, which is a large program to reverse-engineer.
Unlike our past case study we will not attempt a thorough or detailed analysis of aln, since that would simply take way too long.
Instead, we’ll cheat and exploit every trick or leverage that we can to cut down on the amount of work required.
One such leverage is the fact that aln is a statically-linked program.
It is self-sufficient and doesn’t require external libraries to run: any library the program needs is embedded within it.
In particular, we can expect it to contain parts of a C runtime library somewhere in there.
Given its age and context, aln can reasonably be expected to contain a glibc 1.x static library from a Linux distribution of this era.
Unfortunately, getting a hold of derelict Linux userlands can be challenging and getting them to run even more so.
After trying a bunch of distributions and much gnashing of teeth, Slackware 2.3’s libc.a happens to be a near-perfect match.
Static libraries are an archive of object files, but we’re going to use Ghidra’s Version Tracking tool, which can only work on one source/destination program pair at a time.
We need to extract the static archive (ar x libc.a) and then combine all those object files into one (ld -r *.o -o libc.o) so that the tool can work with it.
The upside is that after combining libc.a into libc.o we have one object file which contains every symbol from the various .o files that libc.a is made up of.
The downside is that libc.a doesn’t carry any debugging symbols, but we can cross-reference the original glibc source code if we need to make up for it.
Now that we have one file to work with, we need to actually load it.
As of Ghidra 10.4 the a.out file format isn’t supported, but there is a pull request that implements it. Since libc.o contains a lot of metadata like symbols we want to use, unlike last time we will not try to load this object file by hand.
Instead, after building this modified version of Ghidra we can load libc.o using the UNIX A.out loader format:
Now that we have both our source program (libc.o) and our destination program (aln), we can finally start Ghidra’s Version Tracking tool by clicking on the footprints icon in the project window:
Since we directly launched this tool, it started without a session opened.
Start a new session by clicking on the footstep icon (or File > New Session...):
After running the precondition checks and finishing the new session wizard, Ghidra will open two CodeBrowser windows, one for the source program and one for the destination program.
From there, to leverage the source file we need to start matching it to the destination file.
To get matches, we need to run correlators by clicking on the green plus icon (or File > Add to session) and selecting which correlation algorithms to use:
Since we have a source artifact that is a very close match and a destination artifact that has no symbols, we’ll wing it with just the exact match correlation algorithms with the default settings for now.
After running the correlation algorithms, over 300 potential matches appeared in the version tracking window:
We can see the details of a particular match by selecting it, such as the exact function mnemonics match for _brk:
The bottom part of the version tracking tool shows how the two pieces of both programs correlates. From there, we have three options:
We’ll accept this match by clicking on the green flag (or by right-cliking it and selecting Accept):
Both matches for _brk have been accepted and the FUN_0000fe78 function in the destination program has been renamed _brk.
Furthermore, two new implied data matches for ____brk_addr and _errno appeared with red highlights, since both references inside the _brk function are identical between the two programs.
We can retire accepted matches by clicking on the green checkmark icon (or right-clicking them and selection Apply Markup), which will make them disappear from the matches list to unclutter it.
Using the version tracking tool effectively requires triaging matches. This in turn may generate further implied matches, transferring more and more of the markups from the source program to the destination program.
After processing every match, the destination program (aln) is fully marked up with all the information from the source program (libc.o):
That’s a lot of information inside aln we didn’t need to reverse-engineer by hand.
The files for this case study can be found here: case-study.tar.gz
We have learned how to use Ghidra’s version tracking tool to transfer markings from one program to another and used it to annotate parts of aln with a closely matching C static library.
Next time, we’ll start our porting journey by converting this a.out executable into a modern ELF executable.
aln, the Atari linker for the Atari Jaguar ; specifically, its original Linux port in the a.out executable file format for the 32-bit x86 architecture.
Before trying to reverse-engineer the artifact head-on, let’s run it first as-is on a modern x86_64 Linux system.
After downloading the aln artifact, we’ll use Kees Cook’s a.out loader to execute it.
Let’s download and build it:
$ wget https://raw.githubusercontent.com/kees/kernel-tools/trunk/a.out/aout.c
$ i686-linux-gnu-gcc aout.c -o aout -static
Then, we can use the loader to run aln:
$ ./aout ./aln -v
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
No object files to link.
Link aborted.
a.out QMAGIC executables are based very low in the virtual address space (4096), which is likely below the minimum mmap() address configured on a modern Linux system.
Either lower that minimum address with sysctl -w vm.mmap_min_addr=4096 or use QEMU’s user-mode emulation to run aout.
There is a packaging of a complete Jaguar SDK by cubanismo, ready to use on modern systems.
It offers the choice between running the original tools and modern replacements, if any.
After setting it up, we can build the sample included with the original aln executable like so:
$ make LINK=aln V=1
rmac -fb -g2 -rd -v +o0 +o1 +o2 startup.s
startup.s 81: Warning: RISC code generated with no origin defined
[Writing object file: startup.o]
TEXT segment: 624 bytes
DATA segment: 0 bytes
BSS segment: 64080 bytes
Total : 64704 bytes
TextRel size: 248 bytes
DataRel size: 0 bytes
m68k-aout-gcc -DJAGUAR -I/home/boricj/Documents/jaguar-sdk/jaguar/include -O2 -c -o jag.o jag.c
aln -e -l -g2 -rd -a 4000 x x -v -o jaghello.cof startup.o jag.o
***********************************
* ATARI LINKER (Mar 17 1995) *
* Adds from Atari version 1.11 *
* and PC/DOS&Linux ports *
* Copyright 1993-95 Brainstorm. *
** Copyright 1987-95 Atari Corp. **
***********************************
Output file is jaghello.cof
Sizes: Text Data Bss Syms
(hex) 3C0 410 FA54 1C00
Link complete.
$ file jaghello.cof
jaghello.cof: mc68k COFF object not stripped
$ sha256sum jaghello.cof
f9c8269cdc998de01c0ac7a3e815c16b7ced106e25f10f92a7078c722a220dbb jaghello.cof
We’ll assume that our future ports of aln to be successful if they can replicate jaghello.cof.
It doesn’t completely prove that the ports are fit for purpose as this is hardly an exhaustive stress testing of the linker, but it will demonstrate at least some basic level of functionality.
The Linux port of aln is a statically-linked QMAGIC a.out executable.
At the time of writing this article, vanilla Ghidra doesn’t have an a.out file loader.
There is a pull request that aims to implement it, but we’ll demonstrate how to manually load aln into Ghidra by hand.
For now, we’ll keep things simple and assume the a.out file format is composed of just four parts:
.text segment ;.data segment ;.bss segment.The header has the following structure:
struct aout_header
{
uint32_t a_info; /* machine type, magic, etc */
uint32_t a_text; /* text size */
uint32_t a_data; /* data size */
uint32_t a_bss; /* desired bss size */
uint32_t a_syms; /* symbol table size */
uint32_t a_entry; /* entry address */
uint32_t a_trsize; /* text relocation size */
uint32_t a_drsize; /* data relocation size */
};
When running an a.out QMAGIC executable, the Linux kernel will load it as following:
.text segment are mapped read-execute at offset 4096 ;.data segment is mapped read-write-execute immediately after the .text segment ;.bss segment is mapped read-write immediately after the .data segment.First, let’s analyze the header:
$ hexdump -C aln | head -n 2
00000000 cc 00 64 00 00 c0 01 00 00 10 00 00 94 09 00 00 |..d.............|
00000010 00 00 00 00 20 10 00 00 00 00 00 00 00 00 00 00 |.... ...........|
Using the data structure above (and remembering that the executable is in little-endian order), we can read the following interesting values:
| Field | Offset | Value |
|---|---|---|
a_text |
4 |
0x0001c000 |
a_data |
8 |
0x00001000 |
a_bss |
12 |
0x00000994 |
a_entry |
20 |
0x00001020 |
Now that we have all the information needed from the header, we’ll import this executable inside Ghidra as a raw file and use the following settings:
x86:LE:32:default:gcc ;.text ;0x00001000 ;0x0001d000.Open the file and skip auto-analysis for now.
Click on Window > Memory Map to display the memory map:
Ghidra has loaded the whole of aln as one .text section (as instructed), but this isn’t how this a.out file is actually structured.
We need to fix up by hand the sections so that the memory map of Ghidra matches up with the memory map of the a.out file.
First, we’ll split off .data from .text.
Select the .text section and click on the orange “🟰” button on the top-right corner with the tooltip Split a block.
Fill in the dialog box as follows:
.data ;0x00001000.The rest of the fields will automatically adjust.
Click on OK to split the memory block.
Every initialized section is now correctly set up, but we still have .bss missing, which is an uninitialized section (meaning these bytes aren’t actually stored inside the a.out file).
Click on the green “➕” button on the top-right corner with the tooltip Add a new block to memory.
Fill in the dialog box as follows:
.bss ;ram:0x0001e000 ;0x00000994 ;Click on OK to add the memory block.
The memory map should now look like this:
The artifact is now properly loaded, but there is one last piece of information from the header that we can apply: the entrypoint.
Select the address 0x00001020 in the listing view and hit F (or right-click and select Create Function).
Then, hit the L key, rename the function to _start and mark it as an entry point.
The files for this case study can be found here: case-study.tar.gz
We have loaded the aln executable artifact into Ghidra by hand.
Next time, we’ll start reverse-engineering this artifact in order to start porting aln to new environments.
Over time, the homebrew community has developed modern reimplementations for some of these tools, but there are still extent use-cases for running the original ones. Keeping these ancient tools running as-is on modern systems is proving to be increasingly difficult as time goes on and requires an ever-increasing number of workarounds to pull off:
mmap() minimum address has been bumped to 65536, which is too low for a.out executables ; fixing this requires lowering vm.mmap_min_addr, a privileged operation.In this series of articles, we’ll explore an application of the delinking reverse-engineering technique previously explained here: to make software ports of programs without having access to the original source code.
The files for this case study can be found here: case-study.tar.gz
Since one decompiles an artifact to get source code and one disassembles an artifact to get assembly code, it would be logical that one delinks an artifact to get object files ; yet I had been calling that operation unlinking until recently.
D’oh!
I’ve corrected all instances of this verb in this blog and renamed my Ghidra extension accordingly. I’m sorry in advance if that made a mess of the RSS feed ; hopefully I didn’t also make a mess of the terminology too since there are scant few resources online about it.
]]>