Reverse Engineering with Ghidra Class 4

Class 4 Outline

0:00 - Intro 
3:14 - Ghidra: Loading External Libraries
10:31 - Ghidra: Patch Diffing and Analysis
19:30 - Ghidra: Checksum Tool 
21:38 - Ghidra: Memory Manager 
25:39 - Ghidra Internals: PCODE and SLEIGH 
39:00 - Ghidra Extensions 
45:00 - Ghidra Scripting Overview and Examples

Questions can be sent to superconference@hackaday.io

Class 3 Q&A

• How are we using docker for this class?
• Docker is used to run the exercises in, you can also use an Ubuntu 18.04 virtual machine if you prefer
• What is a (the most?) common example of being able to pull in a header file? Doesn't most of RE activities assume you don't have the source?
• If you are aware of an open source library that the program may be using, you can import header files from that. Or perhaps if you are reverse engineering a custom kernel module, a lot of the structs in use are likely from the mainline kernel
• Can you touch on using tools like Ghidra to remove calls to say a dongle attached to the system?
• This would be entirely system dependent and more context would be needed. Are you trying to functions? What is the end goal? etc
• How do you do expressions in Ghidra? e.g. the last exercise which did a complicated shift and arithmetic---I ended up using Octave to calculate it, but Ghidra must have it as well but I couldn't find it.
• Aside from PCODE emulation, I am not aware of a way to directly evaluate the resulting decompilation. This would require using an external emulator of some sorts. 
• Could you give a couple of examples of what is IDA good at that nobody else has, and vice versa Ghidra and R2
• IDA: Good at c++ demangling, windows PDB parsing, strong decompiler
• R2: Extensible, can easily be expanded upon with plugins, community support, open source
• Ghidra: Decompiler support for every processor, open source, actively developed
• Is it possible to demo running Ghidra alongside a debugger? I know the ret-sync plugin exists but I've had trouble with it
• Right now the built in debugger in in alpha testing and hopefully they will be releasing it with the next official release
• Could you use Ghidra to reverse engineer itself?
• Ghidra is Java based, and open source so there would be little reason to reverse engineer it specifically when the source code is hosted up on github
• Should all struct members take up the same amount of space?
• No, it depends on multiple factors - the architecture of the target system, the compiler optimization settings and of course the members of the struct itself!
• Does running a syscall, by definition, execute instructions defined in the kernel? How does that carry over to an embedded context?
• The syscall instruction does a number of things, but most importantly it puts the value of IA32_LSTAR MSR into PC, this will jump to valid code that will handle the syscall properly, think of it as similar to an interrupt vector table on an embedded processor. 
• I was surprised there wasn’t any Ghidra feature for syscall analysis.
• As of right now I am not aware of any plugins that do this, but it would make for a great side project!
• A question I've been having is why I often see extra (typically repeated) arguments in the decompiled output.  For example, in many of the examples the functions that add two parameters are known to only take two parameters, but Ghidra shows them as having 3 or 4 being provided.  What does it mean/why does it happen?  How do I fix it in Ghidra?
• This happens because the decompiler makes a lot of assumptions and often times these assumptions are simply incorrect. You can fix this up by changing the types of variables on the stack such that they are the proper size. 
• are there any special considerations needed to reverse a proprietary kernel module?
• Nope! They are just ELF files, this is a good example of when one might want to import header files from the kernel source depending on the driver and what other subsystems it uses, for example if your driver uses USB URB objects / structs you could import those in order to make it simpler. 

Reverse Engineering with Ghidra Class 3

Class 3 Outline

0:00 Intro 
2:36 - SRE Tool Landscape 
8:03 - Structs: ASM, Identificaion and Ghidra Analysis 
20:19 - Pointers: ASM, Identificaion and Ghidra Analysis  
35:30 - Enums: ASM, Identificaion and Ghidra Analysis
40:00 - x86_64 System Calls
45:40 - File Operations
51:02 - Ghidra Tips: Patching, Bookmarks, Searching, Comments

Questions can be sent to superconference@hackaday.io

• Where do we get the exercises? The only info I've gotten is on the Eventbrite.
• The exercises are stored on the github page, located here: https://github.com/wrongbaud/hackaday-u
• I tried Gidra on two firmware images I had: an esp32 and STM32 dev board. Since it's a binary blob, it did not provide the ELF info on architecture, so I had to fill it out by hand, and there are many ARM options. I chose ARM Cortex, but it didn't seem to work that well. How do you pick arch from the many ARM options? What would be the right one for this firmware?
• In order to determine the proper CPU architecture, you should start with any applicable datasheets. A lot of the MCUs in those series’ that were mentioned use Cortex cores, but analysis will fall short if you do not properly define the appropriate memory regions, which can be acquired from the relevant datasheet. 
• Why arent functions like main() for c++ automatically set to the right parameters?
  • The decompiler tries not to make too many assumptions for these function prototypes and uses the context that is provided by the instructions in use - this allows things to be more generic and causes fewer failures, but also means that users have to sometimes identify and add the appropriate types. In short - you don't want to assume too much such that it breaks other use cases. 
• Can you take thins like [rbp+8] and give them symbolic names for local variables?
• Yes, if you right click the label that is being used, you can rename the variable to something different.
• Also for the exercises, should we use docker on windows or do WSL and git clone the repo?
• They have been tested within the docker container, and in an Ubuntu 18.04 VM, so I would recommend sticking with one of those two. If you have issues with docker, reach out and we’ll try to help you.

Reverse Engineering with Ghidra Class 2

Class 2 outline

Intro: 0:0
Assembly Language / Applying Function Signatures: 3:08
Imports and Exports: 8:49
Control Flow Statements in Assembly Language: 10:23
Switch Statements in Assembly Language: 18:10
Loops in Assembly Language: 24:34
Variables in Assembly Language: 32:42
Functions in Assembly Language: 39:46
Heap Memory: 48:08
Array Accesses in Assembly Language: 50:11

Office Hour Notes from 6/25/20

Questions:

• When is code obfuscation executed?
• There are various levels of code obfuscation, sometimes the source code itself is obfuscated, and other times it’s applied to the machine code. 
• What do you consider .NET stuff?  Is it a binary file or something else?
• It is technically a binary - but when reversing things build on the .NET framework one would want to start with the dotpeek tool: http://www.jetbrains.com/decompiler/
• Do people obfuscate by handwriting assembly or are there obfuscating compilers?
• Obfuscation can be performed in a number of ways. For example, there are obfuscating assemblers, and various compiler tricks that can be done to aid in obfuscation.
• How often is obfuscation in play?
• It depends on your target, you’ll find it often in games and other things that require some sort of DRM, but it’s less common when looking at embedded firmware images for example.
• It would be great if you can give some pointer on how to identify packed or encrypted code using Ghidra
• There is a plugin here: https://github.com/d3v1l401/FindCrypt-Ghidra that can be used.
• Identifying packed or encrypted code can also be done by performing entropy analysis on the code segment.  Binwalk can do this with the -E option.
• Any binary can be reversed?
• Yes, technically speaking anything that contains machine code that can eventually be run by the CPU can be reverse engineered.
• Do you have any resources for extracting binaries from a platform/uC?
• Yes! Below are some examples that I have done on my website: https://wrongbaud.github.io
• JTAG
• SWD
• SPI Flash
• Parallel Flash
• On embedded systems do you often see heap being used? Or is deterministic memory (stack) more common?
• This depends entirely on what the system is used for - if it’s running an RTOS or a Linux based OS, then you’re going to see heap usage. Smaller microcontrollers may not have space/resources to implement a memory allocator and will rely on statically sized buffers in SRAM. 
• Is the memory for AH / AX / EAX / etc. shared? i.e. can you access 8 bits of AX by accessing AH?
• Yes, the various representations of these registers can be used to access those specific size ranges. 
• Is there a universal reference to the instruction set for x86_64?
• Yes, the Intel instruction set architecture reference is linked on the course page. 
• x86-64 has a flat 64bit memory model so RAM, as well as PCIe peripherals, can end up in memory space, correct?
• Technically this is correct, however there are memory protections in place to try to prevent these regions from being accessed. The operating system / mmu will protect these regions of memory, as well as the drivers utilizing them from being accessed. 
• What are 'high level' differences between Ghidra and Ida Pro? [understand it may just be OpenSource vs not]
• There are many differences between the two, and we will go over these during the second class session!
• Will we be touching on what to do if Ghidra can’t find cross-references because the pointers are some +value off from the virtual addresses in this course? (trying to reverse some firmware blob)
• When looking at firmware blobs, properly creating a memory map is very important, and may be the reason why you’re having issues with XRefs.. This can be done from within ghidra by clicking on the memory viewer, or by writing a loader / script to perform this for you. It is important to also create relevant RAM regions when working with firmware images as these are often where the XRefs will be located. 
• Thank you for the amazing tour of the tools, but what is the "goal" - what can we expect to do with all this? :) 
• The goal of this course is to familiarize students with the concepts behind reverse engineering software, and provide a base understanding of how to use Ghidra to solve binary puzzles and challenges. 
• By the end of this course, students will be comfortable loading x86_64 ELF files into Ghidra and be able to analyze them. 
• I thought EABI was for embedded - why is this present in x86 code?
• ABI = Application Binary Interface, this is what is used to determine things like calling conventions, object file formats and executable formats. When looking at embedded platforms you’ll often see EABI or Embedded ABI’s in place. 
• Why there is EAX if its a 64-bit file? e.g TEST EAX, EAX, shouldn't it be TEST RAX, RAX?
• This is likely a compiler optimization, writing a 32 bit register implicitly zero-extends in x86_64.
• Can Ghidra inject new assembly, or modify the assembly and store to another elf?
• Yes, using the patching feature assembly code can be modified and added, we will be going over how to do this in the third session.
• Will the docker container be used for future classes? I'm new to docker and not sure how to open a GUI from the docker CLI/Bash/Command Prompt
• The docker container is just for running the test applications, if you are uncomfortable with Docker you can use an Ubuntu 18.04 virtual machine instead!
• How can you find the base address of a firmware image:
• This tool can be used, also oftentimes the load address is located within the image header: https://github.com/sgayou/rbasefind

Reverse Engineering with Ghidra Class 1

Class 1 outline

0:00 - Presentation Outline
2:50 - What is Software Reverse Engineering?
4:12 - Software Engineering Review
24:54 - x86_64 Architecture Review
45:10 - Ghidra Overview and Basic Usage

Questions can be sent to superconference@hackaday.io