Introduction

The goal of this project is to introduce people to reverse engineering by getting to know the basic functionality of Ghidra, decompilers, and disassemblers. Two exercises are also included for those who wish to apply the knowledge gleaned from this website by exploring the limits of decompilers and solving a simple CrackMe.

It is recommended that the reader have a basic knowledge in C and the memory hierarchy before reading this resource. These topics are covered in depth in Olin’s Software Systems class.

What is Reverse Engineering?

Reverse engineering is a technique used to analyze software in order to identify and understand the parts it is composed of [1]. This often means taking an executable file and attempting to recreate its source code [1].

People use tools such as decompilers or disassemblers to recreate an executable file’s source code. In this resource, we will cover how decompilers work, how disassemblers work, how to use Ghidra (a popular reverse engineering tool), and how to solve a simple CrackMe.

What is a Disassembler?

A disassembler is a program that converts machine language instructions into assembly language instructions [2]. It is a commonly used tool in reverse engineering because of its effectiveness. As you can infer from the name, a disassembler performs operations that are inverse to the operations performed by an assembler [2].

Disassemblers should not be confused with decompilers, which attempt to recreate the source code in a higher-level computer language such as C. Disassemblers are kind of like the 'middle-man' in this scenario, as the assembly instructions it generates can be used by the decompiler to remake the source code in C, C++, or another language.

In the next section, we'll walk through how disassemblers work.

How do Disassemblers work?

There are two options that one can use to implement a disassembler: a Linear Sweep algorithm or a Recursive Traversal algorithm [3].

Both of these options require some basic information, such as where the program code starts and what architecture is being used (e.g. x86 Assembly, MIPS, etc—these have different instructions!). We need to know these two things because we need to know where we can start disassembling the program, and we also need to know the instruction sets being used (which vary depending on the architecture) [3].

The Linear Sweep Algorithm

A Linear Sweep algorithm will start by reading the first N-bytes of the machine language (can be adjusted) until the disassembler gets a correct opcode [4]. Then it disassembles the next opcode until it encounters an invalid opcode. When the algorithm gets an invalid opcode, it can either skip it and resume or break gracefully and tell the user where it stopped. This makes the algorithm very simple, but also susceptible to any mistakes intentionally left in the code to derail the linear sweep algorithm from its path [4].

The most common linear sweep disassemblers are objdump, WinDbg and SoftICE.

The Recursive Traversal Algorithm

The recursive traversal algorithm is fairly similar to the linear sweep algorithm, except for a few key differences. The algorithm will start by reading the first N-bytes until the disassembler gets a correct opcode. However, instead of disassembling the next opcode until it encounters an invalid opcode, it will disassemble the next opcode until it encounters any sort of jump statement [4]. From there, it will store its current position and follow the jump statement. Then, once it hits an invalid opcode, it can resume at its previously stored position.

This technique is far less susceptible to mistakes than the linear sweep algorithm because the code isn’t disassembled in a linear way [4]. By following the jump instructions, we are able to avoid some of the most common ways a linear sweep disassembler can break.

What is a Decompiler?

A decompiler is a computer program that takes an executable file as input and attempts to create a high-level source file which can be recompiled [5]. It converts the binary code via reverse engineering into source code. This process is much more complicated than disassembling.

Most decompilers create the high-level source file in C because C is relatively close to the machine language instructions in comparison to even higher-level languages like Python or C++ (Python is written in C!). There are some decompilers that will create a source file in Python, C++, or other languages, but they’re few and far between. Fortunately, this is not an issue if you have prior experience with C.

How do decompilers work?

One might think that since we can easily compile code in C, it must not be that hard to just undo whatever the compiler did… right? Wrong!

Decompilers are a lot more complicated than we think they are. We can break down the process of decompiling code into four main stages: the expression decompiler stage, the local variable conversion stage, the control flow reconstruction stage, and the prettifying (aka making code look nice) stage [6].

The Expression Decompiler Stage

The primary purpose in this stage is to convert all stack-based instructions to abstract expressions operating on constants and variables. By the end of this stage, we will end up with an abstract expression syntax tree [6].

To successfully convert our stack-based instructions, we must perform the following steps:

Keep track of the stack state at each instruction
Create an abstract expression stack and pop/push abstract expressions to it

Here is an example of what an abstract expression syntax tree looks like at the end of this stage:

Figure 1: Abstract Syntax Tree Example [7]

This is a generated abstract syntax tree from Euclidean Distance code.

The structure and design of an abstract syntax tree should follow the design of a compiler. Generally, abstract syntax trees require the following:

Each variable declaration should be preserved
The order of executable statements should be explicitly defined
All components of binary operations should be stored

All of these components are used to create the abstract syntax tree!

The Local Variable Conversion Stage

In this stage, we will take the abstract expression syntax tree and successfully replace it with local variables. This is the most complicated stage out of the four.

There are multiple ways to convert stack-based instructions to local variables. We will explore one way which uses single static assignment (SSA). The idea behind single static assignment is that we can convert our data in the stack to local variables because all variables must be initialized before they are used [6]. Since we know that these variables are initialized and assigned values at some point, all we need to do is find out where they were initialized.

However, this concept becomes a little more complicated when we introduce control flow into our code. For example, in x86 Assembly there might not be a local variable x, as values can be pushed onto the stack directly and popped at y. We can introduce Phi functions to address any control flow problems we might come across [6]. Figure 2, an example control flow graph, further highlights this concept:

Figure 2: Converting Stack Values to Local Variables using Single Static Assignment and Phi Functions [8]

Phi functions allow us to generate a new definition of y3 by choosing between either y1or y2 depending on the control flow in the past. This flexibility allows us to obtain the correct value either way [8].

If you’re interested in learning more about Phi functions and single static assignment, you can read more about it here.

Inferring local variable types

Another common difficulty is the process of inferring the type of the local variables. There are a few problems with variable type inference:

Local variable type information is missing from machine code/assembly
Local variables can be assigned to other variables or method arguments, creating dependencies/constraints between their possible types

In simple code, this usually is not a setback. As more functions with various dependencies are added, however, guessing variable types can get quite complicated. For this reason, the solution for variable inference is NP-Hard [6]. A Gagnon, Hendren, or Marceau Three-Stage Algorithm can be used to infer variable types[6], but we won’t get into those algorithms in this project.

A vital piece of information to take away from this process is that it can take a long time for the decompiler to infer variable types. Please remain patient with your decompiler the next time you run it!

The Control Flow Reconstruction Stage

In this stage, the decompiler remakes the if-else statements, for loops, switch statements, etc. The first step that the decompiler makes is creating a control flow graph to represent all possible control flows of the program [6].

The nodes in the control flow graph are blocks of sequential machine code instructions. Note that instructions are chosen in such a way such that if at runtime execution enters a block, all instructions in the block must be executed (i.e. there are no conditionals in a block).

Each edge in the control flow graph represents a flow from one block to the next. In other words, an edge from A to B means at runtime instructions in B are executed directly after executing instructions in A. Note that each edge is also directed, meaning that B->A is distinct from A->B.

Here is an example of what the control flow graph might look like with Java source code. Java source code is compiled into bytecode, which is similar to assembly.

Figure 3: Control Flow Graph with Java Source Code [6]

If statement reconstruction

If statement reconstruction is arguably the simplest of the control flow statements. Ideally, we want the least amount of nested if, else, statements as possible. We also want to have proper if/else statements, not if -> jump to this new line (rather than if -> continue)!

One way we can do both of these things is by using an if reconstruction algorithm [6]. Generally, an if statement is a fork node in a control flow graph. Here is an example of what an if-else statement looks like in a control flow graph:

Figure 4: If-Else Control Flow Graph Example [9]

The starting node is the condition of the if statement (i.e. what it will branch on). Decompilers are generally very good at recognizing if statements with this algorithm. However, a downside of this algorithm is that it can produce nested if/else statements [6]. The decompiler tries to clean this up in the "Prettifying Code" stage.

Loop reconstruction

Loops are the second easiest control flow statements to recreate. Generally, a loop allows for a single entry but multiple exits. Here is an example of what reconstructing a while loop looks like:

Figure 5: While Loop Control Flow Graph Example [9]

A do-while loop has a slightly different construction. Instead of the starting node formally exiting the loop when its condition is met, the loop is repeated until a condition is hit in the loop, causing the loop to exit [9]. Here is an example of what a do-while loop looks like in a control flow graph:

Figure 6: Do-while loop Control Flow Graph Example [9]

Technically, it is possible to express any control flow sequence using if and loop statements. However, this will not look exactly like the original source code. We can convert this intermediate expression of if statements/while loops into a language with for each, elif, switch statements, etc. That comes in the next step!

The "Prettifying" Code Stage

In this stage, the decompiler makes some code readability improvements. Some of the things that the decompiler will try to replace are the following:

Nesting if statements
- The decompiler will try to remove nested if statements and replace them with elif or else statements [6].
Ternary expressions vs. ifs
Variable inlining

Also, some language features (like assembly, Java bytecode, etc.) aren’t directly supported by the machine code. The compiler generates boilerplate code behind the scenes to implement the language features [6]. In Java, some examples of this include switch statements or for each statements. Here is an example of what the compiler generates when it encounters a switch statement (in Java):

Figure 7: Example of a Compiler-Generated Switch Statement in Java [6]

It’s important to note that decompilers have a hard time converting if/while statements into switch/for each/elif statements! Sometimes they are able to do so, but sometimes they can’t. You can always look for these kinds of patterns in your decompiled code and try to make it look nicer for yourself.

Now that we have a basic understanding of decompilers, we can learn more about other common tools that reverse engineers use.

What is Ghidra?

Ghidra is a powerful open source software reverse engineering tool developed by the National Security Administration Research Directorate [10]. Even though it was only released a few years ago, it is one of the most widely used software reverse engineering tools because of its numerous capabilities. Ghidra comes with the following tools pre-installed:

Decompiler
Clean code browser
Server for collaborative work
Program diff-ing tools

We will walk through how to install and use Ghidra in the next section.

Using Ghidra

Installing Ghidra

Linux

Download Ghidra from here: https://ghidra-sre.org/
Open it with your choice of decompression software (likely Archive Manager, unless you’re wildly picky)
Navigate to the directory via terminal (it should be named something like ghidra_9.2.3_PUBLIC) and cd into it
Type . ghidraRun to run Ghidra
Once you do this, you should see a window called Ghidra User Agreement (if you don’t and run into an error saying that you need to install a Java runtime, follow the instructions here, then try to run Ghidra again)
You should see a startup dialogue and then a Terms and Conditions window prompting you to either Agree or Disagree; blindly click “Agree,” as is the custom (if there were anything problematic in the terms and conditions some lawyer probably would’ve made a fuss about it by now, right?)
After forking your soul and privacy rights over to the NSA (just kidding… unless?), you should see a “Ghidra: NO ACTIVE PROJECT” window overlaid with a “Tip of the Day” window or a window called “Ghidra Help”; close everything but the “Ghidra: NO ACTIVE PROJECT” window

You've installed Ghidra!

MacOS

Download Ghidra from here: https://ghidra-sre.org/
Unzip it with your choice of decompression software (likely Archive Utility)
Navigate to the unzipped folder in finder (it should be called something like ghidra_9.2.2_PUBLIC)
Double click on it (it will say that it cannot be opened), then hit “Ok” when your system prevents you from opening it (chuckle knowingly - they can’t control you)
Navigate to System Preferences > Security & Privacy > General and click the little lock at the bottom right

Figure 8: Click the lock and enter your credentials to make changes

Enter your credentials to make changes when prompted.
Then, on the bottom portion of the page just above the lock, you should see a blurb that says ghidraRun was blocked; click the button next to it that says “Open Anyway” (I promise Ghidra is safe - after all, it was created by the NSA, and they would never hurt anyone)

Figure 9: Click the "Open Anyway" button

A terminal should open automatically (if it does not, open terminal and the process should be running) and a system dialogue message that will say one of two things: that you are opening a program from an unverified developer, or that you need to install a Java runtime (If the latter is the case, go here and follow these instructions, then open ghidraRun again)
You should see a startup dialogue and then a terms and conditions window prompting you to either Agree or Disagree; blindly click “Agree” as is custom (if there were anything problematic in the terms and conditions some lawyer probably would’ve made a fuss about it by now, right?)
After forking your soul and all rights to privacy over to the NSA, you should see a window titled “Ghidra: NO ACTIVE PROJECT” overlaid with an irritating “Tip of the Day” window - shake your head in annoyance at the “Tip of the Day” window and close it

You've installed Ghidra!

Windows :(

Note that Ghidra for Windows is only compatible with Windows 7 or Windows 10. If you’re running an older version of Windows, consider the choices you’ve made in your life that got you to this point and give yourself a pat on the back for somehow making it this far.

Download Ghidra from the official installation site (long link: https://ghidra-sre.org/)
Right-click on the zip file and click Extract All

Note that this will take approximately 1 minute.

Install a supported version of the Java Runtime and Development Kit (JDK). You can download the .msi or .zip files.
- This link has some sources for where you can download it for free (Link: https://ghidra-sre.org/InstallationGuide.html#Platforms)
- I downloaded JDK 11 from here (Link: https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot)
- If you downloaded the .zip file, extract the file to your desired location (make sure it's easy to find so the next step is easy for you)
- If you downloaded the .msi file, open the file and go through the Terms of Agreement to successfully install it.

Go into your directory where you installed Ghidra, then launch ghidraRun.bat
- You will see a pop-up like this:

Figure 10: Windows Pop-Up From ghidraRun.bat

It will ask you for the location of your recently downloaded JDK file. You could have manually added it to your path before it asked you to, but Ghidra is smart and has a helper function that can do it for you. Press the Enter key to open the GUI helper.
Make sure that you point Ghidra to the file with the bin file. Depending on what version you installed and where you installed it, it could be nested in a folder or two. My path was C:\\Program Files (x86)\\AdoptOpenJDK\\jdk-11.0.10.9-hotspot (I had to go down two folders to find the location of the bin, conf, and lib files).

Figure 11: Directory of bin, conf, and lib files for JDK

If you installed your JDK file using an .msi file, your file will likely be stored under your Program Files (x86) folder in your local disk. The location of the bin, conf, and lib files will also likely be nested under a file or two.

You should now be done with installing Ghidra! Have fun exploring Ghidra on Windows!

Loading an Executable

Open ghidraRun
Click File > New Project
Select Non-Shared Project
Change the home directory and set the project name accordingly
File > Import
Navigate to the file you’d like to open in Ghidra and select it
Choose the executable format
- Executable and Linking Format (ELF) covers .o, .axf, .bin, .elf, .prx, .puff, .ko, .mod and .so object file extensions. Usually, this is the format that you’ll want.
- Common Object File Format (COFF) is another common executable format that is also Unix-like. It covers the .obj and .lib file extensions.
- There are other executable formats that Ghidra supports. If you’d like to learn more about them, we suggest this Wikipedia article.
Adjust the language to use the whichever decompiler you prefer; I use gcc, which is the default
- Ghidra will usually detect which assembly language you’ll need. If it messes this up, though, feel free to adjust it! For all our examples (including our example exercises), we will use x86 (64 bits).
Edit the Destination Folder and Program Name fields as you see fit
Click “Ok”

Figure 12: Ghidra Pop-Up Window to Analyze an Executable FIle

A window like the one below should appear afterward.

Figure 13: Second Pop-Up Window to Analyze an Executable File (in Ghidra)

Click “Ok”
Double click on the file you loaded in during the steps above, which should have appeared below the project directory
- SInce the Destination Folder was “crackmetest” and the Program Name was “first-evercrackme”, I double-clicked on “first-evercrackme.”

Figure 14: Ghidra Window to Open the Project Directory

Click “Yes” on the Analyze window that has popped up

Figure 15: Ghidra CodeBrowser with Analyze Pop-Up Window

On the Analysis Options window that opens next, you will see many different analysis tools - I usually check all boxes to include all tools that are not prototypes (in red text)
- There are some analyzers that you might not need, but for smaller files it won’t take too much time to include them anyways (for larger files, it can significantly increase the runtime)

Figure 16: The "Analysis Options" window

Click “Analyze”

Welcome to the Code Browser!

Notes on Ghidra's Decompiler

When you load a file into Ghidra, it first performs an auto analysis that identifies the machine language instructions and converts them into assembly code. Then, the decompiler will attempt to compile the assembly code to C code [11].

Here are some tricky things to watch out for when using Ghidra’s decompiler, as it’s more advanced than other decompilers but still bad at making some decisions:

The decompiler will expose optimizations that could make the code more confusing to understand/read
The decompiler has no idea what the function arguments are, but it makes educated guesses as to what they could be; you can't trust it completely!
The decompiler doesn't know most variable/function names, so it will call things param1, param2, FUN_<address>, etc. (you can edit these to make the code more legible and Ghidra will update it for you)
Ghidra is very good at capturing strings, so if you know the string it outputs on an error message, for example, you can find exactly how that error is being handled by looking for the message in the Defined Strings section (explained in Fundamental Tools) [11]

What Does Ghidra Need to Decompile the Code?

When we download Ghidra, Ghidra gathers most of the processor information it needs. This is the following information that Ghidra looks for before decompiling the code:

We need to tell Ghidra the 'binary language' it expects
- We’ve indicated this by selecting the format and language in the first pop-up window (Figure 12)
Ghidra also needs to know little or big endian code format (if the processor supports both)
Ghidra needs to know the starting address if you are loading a raw binary

Fundamental Tools

This section provides a brief guide to basic Ghidra tools, which will be useful in solving the CrackMe in the exercise. The descriptions and usage examples of the tools detailed below are by no means comprehensive - Ghidra has many more advanced (and interesting!) that will not be covered in the scope of this guide. If you care to dive deeper into Ghidra’s functionality, open Ghidra, go to the CodeBrowser (on any file), and in the top menu bar click Help > Contents. There you can click on the Ghidra Functionality folder to access in-depth documentation on all of Ghidra’s tools.

Symbol Tree

The Symbol Tree window organizes different elements of code by type. The most useful aspect of the Symbol Tree is the "Functions" folder, which allows you to see all the different functions within the script. If you click on a function, it will appear in the Listing window along with the compiled assembly. [12]

Figure 17: The Symbol Tree window

Listing Window

The Listing window allows you to browse addresses, assembly instructions, instructions in bytes, XRefs, and more. It is typically most useful for browsing functions and examining their decompilations in detail in order to further understand function behavior.

Figure 18: The Listing window

The image below breaks the listing window down into its components. [13]

Figure 19: An overview of the Listing window by section

If you hover over items in the preliminary decompilation section of the Listing window (referred to as item J in Figure 17), a pop-up window that gives further insight into the decompilation process will appear. To disable these hover pop-ups, click the mouse icon at the top right of the Listing window as shown below. [14]

Figure 20: Click on the arrow icon outlined in red to disable popups

Cross-Reference (XREF)

The XREF tool (shown in TODO fig # as item E) allows you to view other places in the program that reference a certain piece of decompiled code. By double-clicking on the “XREF[#]” text next to a piece of code, you can open an XRefs table that lists other places that reference the code in the program. Clicking on an item in the table displays the reference to the code at that location in the CodeBrowser.

Figure 21: XRefs popup showing different uses of items throughout the code

Decompiler

The Decompiler window can be used by clicking on a function in the Listing window. When the function is clicked, the function’s generated C code is shown in the decompiler.

Figure 22: The Decompiler window

Changing function signatures

Changing function signatures is important because it allows you to correct return and argument types. It also allows you to rename functions. Ghidra seldom gets types correct so correction is often necessary.

Right click on the function name in the decompiler window
Click “Edit Function Signature”

Figure 23: Right click on a function, then click "Edit Function Signature"

Change the type and arguments as desired - for example, since I know the main function returns an int, I will change the type from undefined8 to int

Figure 24: Edit the type, name, and arguments of the function

It is worth noting that you can change the function names from this window as well, as the names that Ghidra comes up with are not very useful to understanding what a function is doing. [14]

Adding comments

Commenting helps keep track of what functions do, call, take, and return, much like in any code. [14]

Right click where you want to insert a comment in the Decompiler
Click on the type of comment you would like to add

Figure 25: Add comments in the Decompiler window

Renaming variables

Much like renaming functions, renaming variables allows you to better understand what a variable represents. [14]

Right click on the variable within the Decompiler window
Click “Rename Variable”

Figure 26: Rename variables

Data Type Manager

As you may have surmised, the Data Type Manager helps you manage data types. You can see built-in data types (things like bytes, chars, floats, ints, etc.) as well as data types specific to the program and data types supplied by different C libraries (there are a bunch of errno data types, for example). [12]

Figure 27: Data Type Manager window

Defined Strings

To open the Defined Strings window, go to Window > Defined Strings. The Defined Strings window shows all of the different strings defined throughout the program, their locations, and their types. Clicking on a string in the Defined Strings window will cause it to appear in the Listing window to the left.

Figure 28: Defined Strings window

Function Call Graph

The Function Call Graph is a surefire way to find which functions call other functions. To see an overview of all the functions, click on the main function in the Symbol Tree, then click Window > Function Call Graph. Shown below is a screenshot of the Function Call Graph I used on my demonstration executable, “first-evercrackme.”

Figure 29: Function Call Graph window

Bytes

The Bytes window allows you to view things in byte form (be that in hex, decimal, binary, etc.). To open the bytes window, navigate to Window > Bytes: <program name>.

Figure 30: Bytes window

Enabling binary, ASCII, hexadecimal, etc.

By default, the bytes window displays addresses in hexadecimal. Sometimes it is helpful to see the contents of these addresses as binary, ASCII characters, or integers. [14]

Click the wrench at the top right corner of the Bytes window
Select the desired formats and click “Ok”

Figure 31: Customize the Bytes window

Exercise: Exploring the Limits of Ghidra

This exercise will introduce you to some of the most essential features of Ghidra. We will also explore the limits of decompilers. See exercise1.md on Github for the instructions/code for this exercise!

Exercise: Solving a Simple CrackMe

CrackMe exercises are common software reverse engineering exercises where one finds a password or a 'flag' from the executable file.

You might ask yourself, "how will I know when I've found the flag?" In our example, the flag will be the password that the program is looking for (in other words, it is the string that the user can input which will move past the 'Enter Password' dialogue).

See exercise_crackme on Github to access the exercise!

Directions

Our directions are posted on README in the exercise_crackme folder, but we will put them here for your convenience.

Go to the exercise_crackme folder in the SoftSysGhidra repository (using cd .. && cd exercise_crackme)
Run gcc crackme.c -o crackme to get the executable file (optionally, you can use the executable files in the exercise_crackme folder and skip this step)
Open Ghidra, and using either a new project or an existing project, go to 'File' and import the executable file (should be named crackme)
When you think you've found the flag, try running the executable file and see if it's what the program is looking for; if the password is correct, congrats! If it doesn't work, you can always try again!

Works Cited

[1] itskawal2000. “Software Engineering: Reverse Engineering.” GeeksforGeeks, GeeksforGeeks, 26 Feb. 2021, www.geeksforgeeks.org/software-engineering-reverse-engineering/.

[2] Beginner's Start. “098 What Is the Difference between Disassembler and Decompilers.” YouTube, YouTube, 20 Dec. 2018, www.youtube.com/watch?v=aw-xzxb7Bqw.

[3] Duke Nukem, et al. “How Does a Disassembler Really Work?” Reverse Engineering Stack Exchange, Stack Exchange Inc., 6 Dec. 2015, reverseengineering.stackexchange.com/questions/11466/how-does-disassembler-really-work.

[4] Lukan, Dejan. “Linear Sweep vs Recursive Disassembling Algorithm.” Infosec, Infosec Resources, 18 Feb. 2013, resources.infosecinstitute.com/topic/linear-sweep-vs-recursive-disassembling-algorithm/.

[5] Shabeer Sher. “What Is a Compiler and a Decompiler?” YouTube, YouTube, 29 Jan. 2019, www.youtube.com/watch?v=YakeUg_Gcno.

[6] Yovtchev, Tsviatko. “How to Build A Decompiler.” YouTube, YouTube, 7 Nov. 2019, www.youtube.com/watch?v=uYZZbteb8Gc.

[7] “Abstract Syntax Tree.” Wikipedia, Wikimedia Foundation, 8 Apr. 2021, en.wikipedia.org/wiki/Abstract_syntax_tree.

[8] “Static Single Assignment Form.” Wikipedia, Wikimedia Foundation, 20 Apr. 2021, en.wikipedia.org/wiki/Static_single_assignment_form.

[9] pp_pankaj. “Software Engineering: Control Flow Graph (CFG).” GeeksforGeeks, GeeksforGeeks, 15 May 2019, www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/.

[10] Rider, Chris. “What Is Ghidra?” YouTube, YouTube, 29 Apr. 2019, www.youtube.com/watch?v=z57WM9jr82Y

[11] Flynn, Colin. “ECED4406 - 0x407 Introducing Ghidra.” YouTube, YouTube, 9 Nov. 2020, www.youtube.com/watch?v=H1sff4Dpo8c.

[12] Patterson, Steven. “Here Be Dragons: Reverse Engineering with Ghidra - Part 0 [Main Windows & CrackMe].” Shogun Lab, Shogun Lab, 12 Apr. 2019, https://www.shogunlab.com/blog/2019/04/12/here-be-dragons-ghidra-0.html.

[13] Darwish, Omar. “What're you telling me, Ghidra?” Byte.how, Byte.how, https://byte.how/posts/what-are-you-telling-me-ghidra/.

[14] stacksmashing. “Ghidra quickstart & tutorial: Solving a simple crackme.” Youtube, Youtube, 8 Mar. 2019, https://www.youtube.com/watch?v=fTGTnrgjuGA.

Page updated

Google Sites

Report abuse