mirror of
https://github.com/NationalSecurityAgency/ghidra
synced 2024-09-14 06:08:54 +00:00
1177 lines
53 KiB
TeX
Executable file
1177 lines
53 KiB
TeX
Executable file
\documentclass{beamer}
|
|
\usepackage{amsmath}
|
|
%\usepackage{alltt}
|
|
%\usepackage{textcomp}
|
|
\usepackage{hyperref}
|
|
|
|
%TODO: x64 cspec double pairs in xmm0, xmm1
|
|
%multi-dimensional array notation?
|
|
|
|
\mode<presentation>
|
|
{
|
|
\usetheme{Montpellier}
|
|
}
|
|
|
|
%turn off navigation symbols
|
|
%\setbeamertemplate{navigation symbols}{
|
|
% \usebeamerfont{footline}
|
|
% \usebeamercolor[fg]{footline}
|
|
%\hspace{1em}
|
|
% \insertframenumber/\inserttotalframenumber
|
|
%}
|
|
|
|
\addtobeamertemplate{navigation symbols}{}{ \hspace{1em} \usebeamerfont{footline} \insertframenumber / \inserttotalframenumber }
|
|
|
|
\defbeamertemplate{itemize item}{image}{\small\includegraphics[height=3ex]{ghidraRight.png}}
|
|
\setbeamertemplate{itemize item}[image]
|
|
|
|
|
|
\defbeamertemplate{section page}{mysectionpage}[1][]{%
|
|
\hyperlinksectionstart{}
|
|
\begin{centering}
|
|
{\usebeamerfont{section name}\usebeamercolor[fg]{section name}#1}
|
|
\vskip1em\par
|
|
\begin{beamercolorbox}[sep=12pt, center]{part title}
|
|
\usebeamerfont{section title}\insertsection\par
|
|
\end{beamercolorbox}
|
|
\end{centering}
|
|
}
|
|
|
|
\setbeamertemplate{section page}[mysectionpage]
|
|
%\setbeamertemplate{section page}{}
|
|
|
|
\defbeamertemplate{subsection page}{mysubsectionpage}[1][]{%
|
|
\begin{centering}
|
|
{\usebeamerfont{subsection name}\usebeamercolor[fg]{subsection name}#1}
|
|
\vskip1em\par
|
|
\begin{beamercolorbox}[sep=8pt, center]{part title}
|
|
\usebeamerfont{subsection title}\insertsubsection\par
|
|
\end{beamercolorbox}
|
|
\end{centering}
|
|
}
|
|
|
|
\setbeamertemplate{subsection page}[mysubsectionpage]
|
|
%\setbeamertemplate{subsection page}{}
|
|
|
|
\AtBeginSection[]
|
|
{
|
|
\begin{frame}<beamer>{Contents}
|
|
\hyperlinksectionstart{}
|
|
\tableofcontents[currentsection,hideothersections,hideothersubsections,sectionstyle=show/hide]
|
|
\end{frame}
|
|
}
|
|
|
|
|
|
|
|
\title[] % (optional, use only with long paper titles)
|
|
{Improving Disassembly and Decompilation}
|
|
\subtitle[]
|
|
{or \\ Moderately Advanced Ghidra Usage \\ \vspace{.2in}\includegraphics[scale=0.5]{GHIDRA_1.png}}
|
|
|
|
|
|
%\titlegraphic{\includegraphics[scale=0.4]{GHIDRA_1.png}}
|
|
\date{}
|
|
|
|
|
|
\begin{document}
|
|
|
|
\begin{frame}
|
|
\titlepage
|
|
\end{frame}
|
|
|
|
\author{}
|
|
\title{}
|
|
|
|
\begin{frame}
|
|
\frametitle{Table of Contents}
|
|
\tableofcontents[sections={1-5},hideallsubsections]
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Table of Contents}
|
|
\tableofcontents[sections={6-},hideallsubsections]
|
|
\end{frame}
|
|
|
|
\section{Intro and Setup}
|
|
|
|
\subsection{Introduction}
|
|
\begin{frame}
|
|
\begin{block}{Intro}
|
|
\begin{itemize}
|
|
\item Like any SRE tool, Ghidra makes assumptions which sometimes need to be adjusted by reverse engineers.
|
|
\item These slides describe techniques for recognizing problematic situations and steps you can take to improve Ghidra's analysis.
|
|
\item These slides assume basic familiarity with Ghidra.
|
|
\item Note: the materials for the ``Beginner'' and ``Intermediate'' Ghidra classes are included with the Ghidra distribution.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Setup}
|
|
\begin{frame}
|
|
\begin{block}{Setup}
|
|
\begin{itemize}
|
|
\item First, create a new project for the example files used by these slides.
|
|
\item Next, import the files. They are located in \small \textbf{$\langle$ghidra\_dir$\rangle$/docs/GhidraClass/ExerciseFiles/Advanced} \normalsize
|
|
\item The easiest way to do this is to use the Batch Importer
|
|
\item[](\textbf{File} $\rightarrow$ \textbf{Batch Import...} from the Project Window).
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\section{Improving Disassembly}
|
|
|
|
\subsection{Evaluating Analysis: The Entropy and Overview Windows}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Evaluation}
|
|
\begin{itemize}
|
|
\item Use the entropy and overview sidebars to get a quick sense of how well a binary has been analyzed/disassembled.
|
|
\item For instance, the entropy sidebar can tell you whether your binary has regions which are likely encrypted or compressed.
|
|
\item To activate these sidebars, use the dropdown menu in the Listing (immediately to the right of the camera icon).
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Non-Returning Functions}
|
|
\begin{frame}
|
|
\begin{block}{Non-returning Functions}
|
|
\begin{itemize}
|
|
\item Some functions, like \textbf{exit} or \textbf{abort}, are \textbf{non-returning functions}. Such functions do not return to the caller after executing. Instead, they
|
|
do drastic things like halting the execution of the program.
|
|
\item Suppose \textbf{panic} is a function that does not return. The compiler is free to put whatever it wants (e.g., data) after calls to \textbf{panic}.
|
|
\item If Ghidra does not know that \textbf{panic} is non-returning, it will assume that bytes after calls to \textbf{panic} are instructions and attempt to disassemble them.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Non-returning Functions}
|
|
\begin{itemize}
|
|
\item The \textbf{Non-Returning Functions - Known} analyzer recognizes a number of standard non-returning functions by name and automatically handles them correctly.
|
|
\item The \textbf{Non-Returning Functions - Discovered} analyzer attempts to discover non-returning functions by gathering evidence during disassembly.
|
|
\item If a non-returning function manages to slip by these analyzers, it can wreak havoc on analysis. Fortunately, there are ways to recognize and fix this situation.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Non-returning Functions}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{noReturn}. Note: for all exercises, use the default analyzers unless otherwise specified.
|
|
\item Open the \textbf{Bookmarks} window and examine the \textbf{Error} bookmarks. There should be two errors.
|
|
\item These errors are due to one non-returning function that Ghidra doesn't know about. Identify this function and mark it as non-returning (right-click on the name of the function in
|
|
the decompiler, select \textbf{Edit Function Signature} and select the \textbf{No Return} box).
|
|
\item Verify that the errors are corrected after marking the function as non-returning.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Non-returning Functions}
|
|
\begin{itemize}
|
|
\item[] (advance for solutions)
|
|
\pause
|
|
\item The function \textbf{loopForever} is non-returning.
|
|
\item Note: You can configure how much evidence the \textbf{Non-Returning Functions - Discovered} analyzer requires before deciding that function is non-returning via
|
|
\textbf{Analysis} $\rightarrow$ \textbf{Auto Analyze ...} from the Code Browser. If you lower the evidence threshold, this analyzer will mark \textbf{loopForever} as
|
|
non-returning.
|
|
\item Also, the script \textbf{FixupNoReturnFunctions.java} will analyze a program and present a list of potentially non-returning functions.
|
|
It will also allow you to mark a function as non-returning and repair any damage.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
|
|
\subsection{Function Start Patterns}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Finding Functions}
|
|
\begin{itemize}
|
|
\item Ghidra uses many techniques to find bytes to disassemble and to group instructions together into function bodies.
|
|
\item One such technique is to search for \textbf{function start patterns}. These are patterns of bits (with wildcards allowed) that indicate that a particular address is likely the
|
|
start of a function.
|
|
\item These patterns are based on two facts:
|
|
\begin{enumerate}
|
|
\item Functions often start in similar ways (e.g., setting up the stack pointer, saving callee-saved registers)
|
|
\item Similar things occur immediately before a function start (return of previous function, padding bytes,...)
|
|
\end{enumerate}
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Finding Functions}
|
|
\begin{itemize}
|
|
\item Ghidra has an experimental plugin for exploring how functions already found in a program begin and using that information to find additional functions.
|
|
\item To enable it from the Code Browser: \textbf{File} $\rightarrow$ \textbf{Configure...}, click on the (upper right) plug icon, and select the
|
|
\textbf{Function Bit Patterns Explorer} plugin.
|
|
\item Then select \textbf{Tools} $\rightarrow$ \textbf{Explore Function Bit Patterns} from the Code Browser.
|
|
\item Hovering over something in the tool and pressing \textbf{F1} will bring up the Ghidra help (this works for most parts of Ghidra).
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\begin{block}{Finding Functions}
|
|
\begin{itemize}
|
|
\item The general strategy is to explore the instruction trees and byte sequences, select/combine/mine for interesting patterns, then send them to the \textbf{Pattern Clipboard} for
|
|
evaluation. See the help for details.
|
|
\item Another useful feature is the \textbf{Disassembled View} (accessed through the \textbf{Window} menu of the Code Browser). This allows you to see what the bytes at the current
|
|
address would disassemble to without actually disassembling them.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
|
|
\section{Improving Decompilation: Data Types}
|
|
|
|
\subsection{Defining Structures}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Defining Data Types}
|
|
\begin{itemize}
|
|
\item One of the best ways to clean up the decompiled code is to define data structures.
|
|
\item You can do this manually through the \textbf{Data Type Manager}.
|
|
\item You can also have Ghidra help you by right-clicking on a variable in the decompiler view and selecting
|
|
\begin{itemize}
|
|
\item \textbf{Auto Create (Class) Structure}, or
|
|
\item \textbf{Auto Fill in (Class) Structure}.
|
|
\end{itemize}
|
|
\item Note: If you happen to have a C header file, you can parse data types from it by selecting \textbf{File} $\rightarrow$ \textbf{Parse C Source...} from the Code Browser
|
|
(doesn't support C++ header files yet).
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\begin{block}{Exercise: Auto-creating Structures}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{createStructure}.
|
|
\item[] This file contains two functions of interest: \textbf{setFirstAndThird} and \textbf{setSecondAndFourth}.
|
|
\item[] The first parameter to each of these two function has type \textbf{exampleStruct *}, where \textbf{exampleStruct} is defined as follows:
|
|
\item[] \begin{verbatim}
|
|
typedef struct {
|
|
long a
|
|
int b
|
|
char *c;
|
|
short d
|
|
} exampleStruct;
|
|
\end{verbatim}
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Auto-creating Structures}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{1}
|
|
\item Navigate to \textbf{setFirstAndThird}.
|
|
\item In the decompiler view, change the type of the second parameter to \textbf{long} and the third parameter to \textbf{char *}
|
|
\item In the decompiler view, right-click on \textbf{param1} and select \textbf{Auto Create Structure}.
|
|
\item Right-click on the default structure name (\textbf{astruct}) in the decompiler and select \textbf{Edit Data Type...}
|
|
\item Change the name of the structure to \textbf{exampleStruct} and the names of the defined fields to \textbf{a} and \textbf{c}.
|
|
\item Note that this isn't all of the fields in the structure, just the ones that were used in this function.
|
|
\item[] (continued)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Auto-creating Structures}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{7}
|
|
\item Now navigate to \textbf{setSecondAndFourth}.
|
|
\item Change the type of the first parameter to \textbf{exampleStruct *}, the type of the second to \textbf{int}, and the type of the third to \textbf{short}.
|
|
\item Right-click on the first parameter and select \textbf{Auto Fill in Structure}.
|
|
\item Edit the structure again to add the names from the structure definition for the new fields (you can also select each field in the decompiler and press \textbf{L}).
|
|
\item Revel in how much better the decompilation of the two functions looks!
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Defining Classes}
|
|
\begin{frame}
|
|
\begin{block}{Defining Classes}
|
|
\begin{itemize}
|
|
\item If a variable is known to be a \textbf{this} parameter, right-clicking on it will yield a menu with the option \textbf{Auto Fill in Class Structure} instead
|
|
of \textbf{Auto Fill in Structure}.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Defining Classes}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{animals}.
|
|
\item In the Listing, press \textbf{G} (goto). In the resulting pop-up, enter \textbf{getAnimalAge}. \item This will bring up the \textbf{Go To...} dialog, where you can
|
|
select between the two functions with the name \textbf{getAnimalAge} (the functions are in different namespaces).
|
|
\item[] Note: There are other windows, such as the \textbf{Functions} window, in which there is no default namespace column. You can add a namespace column by right-clicking
|
|
on any column name and selecting \textbf{Add/Remove Columns...} You can also configure the display of certain columns by right-clicking on the column name.
|
|
\item[] (continued)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Defining Classes}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{3}
|
|
\item Select \textbf{Dog::getAnimalAge} in the pop-up. This will cause the Code Browser to navigate to \textbf{Dog::getAnimalAge()}.
|
|
\item[] Note: Alternatively, you can quickly navigate to the functions in a class using the \textbf{Classes} folder of the \textbf{Symbol Tree}.
|
|
\item Verify that in the decompiler view, right-clicking on the token \textbf{Dog} yields a menu with \textbf{Auto Fill in Class Structure} as an option.
|
|
Note that Ghidra has already created an empty structure named \textbf{Dog}.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Decompiling Virtual Function Calls}
|
|
|
|
\begin{frame}[fragile]
|
|
\begin{block}{Exercise: Virtual Function Tables}
|
|
\begin{enumerate}
|
|
\item Here is what the end of \textbf{main} looks like in the source code:
|
|
\label{snippet}
|
|
\item[]
|
|
\begin{verbatim}
|
|
Animal *a;
|
|
...
|
|
a->printInfo(); //non-virtual
|
|
a->printSound(); //virtual
|
|
a->printSpecificFact(); //virtual
|
|
int animalAge = a->getAnimalAge(); //virtual
|
|
delete(a);
|
|
return animalAge;
|
|
\end{verbatim}
|
|
\item[] Navigate to the function \textbf{main} and examine Ghidra's decompilation.
|
|
\item[] (continued)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Virtual Function Tables}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{1}
|
|
\item The task is to get the names of the virtual functions to show up in the decompiler. At a high level, the steps are:
|
|
\begin{itemize}
|
|
\item For each virtual function \textbf{foo} of the class \textbf{Animal}, create a function definition, which is a data type representing the signature of \textbf{foo}.
|
|
\item Create a data type for the vftable of \textbf{Animal}. This data type will be a structure whose fields are the function signature data types (in order).
|
|
\item Change the first field of the \textbf{Animal} data type to be a pointer to the vftable data type.
|
|
\end{itemize}
|
|
\item[] (continued)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Virtual Function Tables}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{2}
|
|
\item First, create a function definition for each of the virtual functions
|
|
\begin{itemize}
|
|
\item \textbf{void printSound(void)}
|
|
\item \textbf{void printSpecificFact(void)}
|
|
\item \textbf{int getAnimalAge(void)}
|
|
\end{itemize}
|
|
by right-clicking on \textbf{animals} in the \textbf{Data Type Manager} and selecting \textbf{New} $\rightarrow$ \textbf{Function Definition...}
|
|
\item[] For each function, enter the signature and select \textbf{\_thiscall} for the calling convention.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Virtual Function Tables}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{3}
|
|
\item Now, right-click on \textbf{animals} in the \textbf{Data Type Manager} and select \textbf{New} $\rightarrow$ \textbf{Structure...}
|
|
\item Give the new structure the name \textbf{Animal\_vftable}.
|
|
\item Fill in the structure with the data types corresponding to the virtual functions of the class \textbf{Animal}. You can do this by double-clicking in an entry in
|
|
the \textbf{DataType} column and entering a name of a virtual function.
|
|
\item[] Notes:
|
|
\begin{itemize}
|
|
\item The order of the functions in the vftable is the same as the order they are called in the source code snippet.
|
|
\item Be sure to give each field in the vftable structure a name (use the name of the corresponding virtual function).
|
|
\end{itemize}
|
|
\item[] (continued)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Virtual Function Tables}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{6}
|
|
\item Alternatively:
|
|
\begin{itemize}
|
|
\item Find the vftable for \textbf{Animal} (from the Code Browser, \textbf{Search}~$\rightarrow$~\textbf{For Address Tables...}) and look for the table consisting of calls to
|
|
\textbf{\_\_cxa\_pure\_virtual}.
|
|
\item Apply the three function definition data types to the pointers in the table in the appropriate order.
|
|
\item Select the table in the Listing, right-click, \textbf{Data}~$\rightarrow$~\textbf{Create Structure}
|
|
\end{itemize}
|
|
\item In main, re-type the variable passed to \textbf{printInfo} to have type \textbf{Animal *} and re-name it to \textbf{a}.
|
|
\item Right-click on \textbf{a} and select \textbf{Auto Fill in Structure} (note that this does not say \textbf{Auto Create Structure} since Ghidra automatically created a default empty
|
|
\textbf{Animal} structure).
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Virtual Function Tables}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{9}
|
|
\item Finally, edit the \textbf{Animal} structure itself so that the first field is an element of type \textbf{Animal\_vftable *} with name \textbf{Animal\_vftable}.
|
|
\item Verify that the virtual function names appear in the decompilation of \textbf{main}.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\section{Improving Decompilation: Function Calls}
|
|
|
|
\subsection{Introduction}
|
|
\begin{frame}
|
|
\begin{block}{Function Signatures and Calls}
|
|
\begin{itemize}
|
|
\item In this section, we focus on issues involving function signatures and function calls.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Function Signatures: Listing vs. Decompiler}
|
|
\begin{frame}
|
|
\begin{block}{Refresher on Function Signatures in Ghidra:}
|
|
\begin{itemize}
|
|
\item Sometimes the signature of a function shown in the Listing (or in the \textbf{Functions} window) will not match the signature shown in the decompiler.
|
|
\item This happens because the decompiler performs its own analysis to determine the function's signature.
|
|
\item The decompiler re-analyzes the function each time it is decompiled.
|
|
\item The signature shown in the Listing is created when the function is (re-)created. This is the signature that is stored in the Ghidra program database.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Refresher on Function Signatures in Ghidra:}
|
|
\begin{itemize}
|
|
\item To transfer the decompiler's signature to the Listing, right-click on the function in the decompiler and select \textbf{Commit Params/Return}. The transfered signature will be
|
|
saved to the program database.
|
|
\item The situation is the same for the local variables of a function: right-click on the function in the decompiler and select \textbf{Commit Locals}.
|
|
\item[] Note: Usually it's better not to commit locals and instead to let the decompiler assign types to them automatically. Committing locals can
|
|
interfere with type propagation.
|
|
\item Editing a function's signature manually, from either the Listing or the decompiler, commits the new signature to the program database.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{The Decompiler Parameter ID Analyzer}
|
|
\begin{frame}
|
|
\begin{block}{Decompiler Parameter ID}
|
|
\begin{itemize}
|
|
\item The \textbf{Decompiler Parameter ID Analyzer} (\textbf{Analysis} $\rightarrow$ \textbf{One Shot} $\rightarrow$ \textbf{Decompiler Parameter ID}) uses the decompiler and an
|
|
exploration of the call tree to determine parameter, return type, and calling convention information about functions in a program. This analyzer can be quite useful when
|
|
you have some rich type information, such as known types from library calls. However, if you run this analyzer too early or before fixing problems, you can end up propagating
|
|
bad information all over the program.
|
|
\item Note: this analyzer will commit the signature of each function.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Overriding a Signature at a Call Site}
|
|
\begin{frame}
|
|
\begin{block}{Overriding Signatures}
|
|
\begin{itemize}
|
|
\item It is possible to override a function's signature at a particular call site.
|
|
\item This is basically only ever needed for variadic functions (functions which take a variable number of arguments), or to adjust the arguments of indirect calls.
|
|
In other cases you should edit the signature of the called function directly.
|
|
\item To override a signature, right-click on the function call in the decompiler and select \textbf{Override Signature}.
|
|
\item To remove an override, right-click and select \textbf{Remove Signature Override}.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Aside: The System V AMD64 ABI}
|
|
\begin{itemize}
|
|
\item For reference when doing the exercises, here is the calling convention used by Linux on x86\_64:
|
|
\begin{itemize}
|
|
\item First 6 integer/pointer args are passed in \textbf{RDI}, \textbf{RSI}, \textbf{RDX}, \textbf{RCX}, \textbf{R8}, \textbf{R9}.
|
|
\item First 8 floating point args are passed in \textbf{XMM0}-\textbf{XMM7}.
|
|
\item Additional args are passed on the stack.
|
|
\item For variadic functions, the number of floating point args passed in the \textbf{XMM} registers is passed in \textbf{AL}.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Overriding Signatures}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{override.so}, then navigate to the function \textbf{overrideSignature}. Override the signature of the call to \textbf{printf},
|
|
if necessary, using the format string to determine number and types of the parameters to the call. Some of the parameters to \textbf{printf} are global variables; determine
|
|
and apply their types.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Overriding Signatures}
|
|
\begin{itemize}
|
|
\item[] (advance for solution)
|
|
\pause
|
|
\item Signature:
|
|
\item[] ~~~~\textbf{printf(char *,int,long,double,char *,int,int,int,int)}
|
|
\item Types:
|
|
\item[] ~~~~\textbf{a}: \textbf{int}
|
|
\item[] ~~~~\textbf{b}: \textbf{long}
|
|
\item[] ~~~~\textbf{c}: \textbf{double}
|
|
\item[] ~~~~\textbf{d}: \textbf{char *}
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Custom Calling Conventions}
|
|
\begin{frame}
|
|
\begin{block}{Custom Calling Conventions}
|
|
\begin{itemize}
|
|
\item Sometimes a function will use a non-standard calling convention.
|
|
\item In such a case, you can set the calling convention manually.
|
|
\item To do this, right-click on the function in the decompiler and select \textbf{Edit Function Signature}.
|
|
\item In the resulting window, select \textbf{Use Custom Storage} under \textbf{Function Attributes}.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Custom Calling Conventions}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{custom}, then navigate to the function \textbf{main}.
|
|
\item \textbf{main} calls the functions \textbf{sum} and \textbf{diff}, which have custom calling conventions.
|
|
\item Examine the bodies and call sites of \textbf{sum} and \textbf{diff} to determine their signatures and custom calling conventions.
|
|
\item Edit each of the two functions and select \textbf{Use Custom Storage}.
|
|
\item Type the correct signature into the text window and press enter.
|
|
\item[] (continued...)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Custom Calling Conventions}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{5}
|
|
\item Click on the entries in the \textbf{Storage} column to set the storage for each parameter/return value.
|
|
\item In the resulting \textbf{Storage Address Editor} window, click \textbf{Add} to add storage, then click on each
|
|
table entry to modify.
|
|
\item You might find it helpful to remove some of the variable references Ghidra adds in the Listing, particularly to stack variables. To do this, \textbf{Edit}
|
|
$\rightarrow$ \textbf{Tool Options} $\rightarrow$ \textbf{Listing Fields} $\rightarrow$ \textbf{Operands Field} from the Code Browser.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Custom Calling Conventions}
|
|
\begin{itemize}
|
|
\item[] (advance for solutions)
|
|
\pause
|
|
\item \textbf{long sum(long, long)}: return in \textbf{RAX}, args in \textbf{R14, R15}.
|
|
\item \textbf{long diff(long, long)}: return in \textbf{RBX}, args in \\ \textbf{[RSP + 0x8]}, \textbf{[RSP + 0x10]}
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Multiple Storage Locations}
|
|
\begin{frame}
|
|
\begin{block}{Multiple Storage Locations}
|
|
\begin{itemize}
|
|
\item You may have noticed that you can add multiple storage locations for one parameter when editing a function signature.
|
|
\item This is used (for example) for functions which return \textbf{register pairs}.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Multiple Storage Locations}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{ldiv}, then navigate to the function \textbf{main}.
|
|
\item In the decompiler, right-click on the call to \textbf{ldiv} and select \textbf{Edit Function Signature}. How does \textbf{ldiv} use multiple storage locations for a function variable?\item[] (advance for solution)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Multiple Storage Locations}
|
|
\begin{itemize}
|
|
\item The result of \textbf{ldiv} is returned in the register pair \textbf{RDX:RAX} (\textbf{RAX} contains the quotient, \textbf{RDX} contains the remainder).
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Inlining Functions}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Inlining Functions}
|
|
\begin{itemize}
|
|
\item Some special functions have side effects that the decompiler needs to know about for correct decompilation. You can handle this situation by marking them
|
|
as \textbf{inline}.
|
|
\item If \textbf{foo} is marked as inline, calls to \textbf{foo} will be replaced by the body of \textbf{foo} during decompilation.
|
|
\item To mark \textbf{foo} as inline, edit \textbf{foo}'s signature and check the \textbf{In~Line} function attribute.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Inlining Functions}
|
|
\begin{itemize}
|
|
\item Inlining a function is related to the notion of a \textbf{call fixup}, where calls to certain functions are replaced with snippets of Pcode.
|
|
\item These functions are recognized by name and have the call fixup applied automatically.
|
|
\item Examples include functions related to structured exception handling in Windows.
|
|
\item You can also select from pre-defined call fixups when editing a function signature.
|
|
\item Note: there are no fixups defined for x86\_64 binaries compiled with \textbf{gcc}, so the \textbf{Call Fixup} selector is greyed out for the exercise files.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Inlining Functions}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{inline}, then navigate to the function \textbf{main}.
|
|
\item When provided with the correct number of command line arguments, this function should parse \textbf{argv[1]} and \textbf{argv[2]} into unsigned long values and print their sum.
|
|
The task is to get the decompiler to show this.
|
|
\item First, ensure that \textbf{main} has the correct signature \\ (\textbf{int main(int argc, char **argv)}).
|
|
\item Next, override the signature of the call to \textbf{printf} if necessary, so that it agrees with the format string.
|
|
\item[] (continued)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Inlining Functions}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{4}
|
|
\item The decompilation will still be incorrect. Marking \textbf{adjustStack} and \textbf{restoreStack} as inline yields correct decompilation. Why?
|
|
\end{enumerate}
|
|
\pause
|
|
\begin{itemize}
|
|
\item \textbf{adjustStack} decreases the stack pointer by 16, which violates the calling convention. Since the default behavior of the decompiler is to assume that a function follows the
|
|
calling convention, it assumes that the call to \textbf{adjustStack} does not change the value of the stack pointer. This assumption leads to incorrect analysis. If you mark
|
|
\textbf{adjustStack} and \textbf{restoreStack} as inline, their bodies will be incorporated into \textbf{main} during decompilation and the changes to the stack pointer will be tracked.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{System Calls}
|
|
\begin{frame}
|
|
\begin{block}{System Calls}
|
|
\begin{itemize}
|
|
\item \textbf{System calls} are a way for a program to request a service from the operating system.
|
|
\item Examples include process control, file management, device management,\ldots
|
|
\item A typical implementation uses a special native instruction along with a designated register, which we'll call the
|
|
\textbf{system call register}.
|
|
\item When the special instruction is executed, the value in the system call register determines which function is called.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: System Calls}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{write}, then navigate to \textbf{main}.
|
|
\item[] Note: \textbf{main} prints \texttt{Hello World!} to the screen using the \textbf{write} system call.
|
|
\end{enumerate}
|
|
\begin{itemize}
|
|
\item Before going further, let's examine what we see.
|
|
\begin{itemize}
|
|
\item In the decompiler, you should see \textbf{syscall()}, which looks like a function call but isn't (try clicking on it).
|
|
\item This is an example of a \textbf{user-defined Pcode op}.
|
|
\item Such operations are used when implementing the Pcode for a particular instruction is too hard (or impossible).
|
|
\item These operations show up as \textbf{CALLOTHER} Pcode ops in the Pcode field in the Listing. They can have inputs and outputs, but otherwise are treated
|
|
as black boxes by the decompiler.
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: System Calls}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{1}
|
|
\item In the decompiler, why is the return value of \textbf{main} \texttt{undefined [16]}?
|
|
\end{enumerate}
|
|
\pause
|
|
\begin{itemize}
|
|
\item The \textbf{SYSCALL} instruction is translated to a single \textbf{CALLOTHER} Pcode op (named \textbf{syscall}). The decompiler does not consider this operation to have any
|
|
side effects, so when it tries to automatically determine the return type it sees a move to \textbf{RDX} and a move to \textbf{RAX} before the \textbf{RET} instruction.
|
|
These registers form a register pair for this architecture, so the decompiler thinks the return value is 16 bytes.
|
|
\item So how do we improve the decompilation?
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: System Calls}
|
|
\begin{itemize}
|
|
\item This system call is a call to \textbf{write} since \texttt{1} is written to the system call register (\textbf{RAX}) before the \textbf{syscall}
|
|
instruction is executed (search online for ``x64 Linux syscall table").
|
|
\item We'd like the call to \textbf{write} to appear with the correct name, signature, and calling convention.
|
|
\item We'd also like cross references, so that we can easily see all calls to \textbf{write}.
|
|
\item During execution, the code for the \textbf{write} function is somewhere in the kernel and not in the program's address space.
|
|
\item So what should the call target be in Ghidra?
|
|
\item Answer: use \textbf{overlay blocks} on the \textbf{OTHER} space.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: System Calls}
|
|
\begin{itemize}
|
|
\item Prior to Ghidra 9.1, the \textbf{OTHER} space was used to store data from a binary that does not get loaded into memory, such as the \texttt{.comment} section of an ELF file.
|
|
\item In 9.1, we've extended the ability to make references into the \textbf{OTHER} space.
|
|
\item You can't use this space directly, but you can create \textbf{overlay blocks} on the \textbf{OTHER} space.
|
|
\item Overlays are a (sort of old school) technique to allow different blocks to be swapped in and out at the same address.
|
|
\item For our purposes, they allow us to put things in an artificial memory space without the possibility of conflicting with other uses of that space.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: System Calls}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{2}
|
|
\item Create an overlay of the \textbf{OTHER} space as follows:
|
|
\begin{enumerate}[(i)]
|
|
\item Bring up the \textbf{Memory Map} by clicking on the ram chip icon in the tool bar of the Code Browser.
|
|
\item Click on the green plus to add a block.
|
|
\item Call the block \textbf{syscall\_block}. Have it start at address \texttt{0x0} of the \textbf{OTHER} space and have length \texttt{0x1000}.
|
|
For Block Type, select \textbf{Overlay} from the drop-down menu.
|
|
\end{enumerate}
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: System Calls}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{3}
|
|
\item Next, go to address \texttt{0x1} in \textbf{syscall\_block} and create a function (in the Listing, select both the address and the \texttt{??} and press \texttt{f}).
|
|
\item Edit this new function to give it the name \textbf{write} and the \textbf{syscall} calling convention.
|
|
\item If you happen to know the parameters and their types you can add them. Altervatively, select the new function \textbf{write} in the Code Browser, right-click on
|
|
\textbf{generic\_clib\_64} in the \textbf{Data Type Manager}, and select \textbf{Apply Function Data Types}
|
|
\item[] Note: the function we've created has no body. It's essentially an address to hang a function signature and to get cross-references.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: System Calls}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{6}
|
|
\item Now, navigate back to the \textbf{syscall} instruction in \textbf{main}.
|
|
\item Click on the instruction in the Listing, then press \texttt{r} to bring up the \textbf{Reference Manager}.
|
|
\item Click the green plus to add a reference. Enter \textbf{syscall\_block::1} for the ``To Address'' and \textbf{CALLOTHER\_CALL\_OVERRIDE} for the Ref-Type.
|
|
This reference type essentially transforms the \textbf{CALLOTHER} Pcode op to a \textbf{CALL} op before sending the Pcode to the decompiler. The call target is the ``To Address''
|
|
of the reference.
|
|
\item[] The decompilation should now look as expected.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{System Call Notes}
|
|
\begin{enumerate}
|
|
\item The script \texttt{ResolveX86orX64LinuxSyscallScript.java} will do all of this for you. You can run it on this file, but a better demonstration is to run it on a
|
|
libc shared object file.
|
|
\item The script uses the \textbf{Symbolic Propagator} to determine the value of a register at a particular location.
|
|
\item The script requires a mapping from system call numbers to system call names. The x86 and x64 ones come with Ghidra, you will need to supply others.
|
|
\item Also, the signatures of most Linux system calls are included with Ghidra (used in step 6 above). The script shows you how to apply function data types programmatically,
|
|
but you might have to supply your own data type archive.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
|
|
\section{Improving Decompilation: Control Flow}
|
|
|
|
\subsection{Fixing Switch Statements}
|
|
\begin{frame}
|
|
\begin{block}{Fixing Switch Statements}
|
|
\begin{itemize}
|
|
\item Sometimes you will see warnings in the decompiler view stating that there are too many branches to recover a jumptable.
|
|
\item One reason for this is that there actually is a jump table, but the decompiler can't determine bounds on the switch variable.
|
|
\item In such cases, you can add the jump targets manually and then run the script \textbf{SwitchOverride.java}.
|
|
\item Note: To find such locations in a program, run the script \textbf{FindUnrecoveredSwitchesScript.java}.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Fixing Switch Statements}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{switch}, then navigate to the function \textbf{main}. The decompiler view should contain a warning about an unrecovered jumptable.
|
|
\item The global variable \textbf{array} is the jumptable.
|
|
\item Navigate to \textbf{array} in the Listing and press \textbf{p} to define the first element to be a pointer. Note: this will clear any data type information that Ghidra assigned to
|
|
\textbf{array} automatically.
|
|
\item Now press \textbf{[} to define an array. Enter 10 for the number of elements.
|
|
\item This will trigger disassembly at each of the addresses in the jumptable, but these addresses are not yet part of the function \textbf{main}.
|
|
\item[] (continued...)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Fixing Switch Statements}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{5}
|
|
\item Navigate to the \textbf{JMP} instruction which jumps to \textbf{array} + an offset.
|
|
\item Press \textbf{R} to bring up the References Editor and click on the mnemonic (\textbf{JMP}).
|
|
\item You can use the green plus to add a \textbf{COMPUTED\_JUMP} reference to each address stored in the jumptable one at a time.
|
|
\item Alternatively:
|
|
\begin{itemize}
|
|
\item Select the \textbf{JMP} instruction
|
|
\item \textbf{Select} $\rightarrow$ \textbf{Forward Refs} from the Code Browser.
|
|
\item \textbf{Select} $\rightarrow$ \textbf{Forward Refs} again.
|
|
\item Drag the selection onto the References Editor Dialog.
|
|
\end{itemize}
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Fixing Switch Statements}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{9}
|
|
\item Right click on the label \textbf{main} in the Listing, then select \textbf{Function} $\rightarrow$ \textbf{Re-create Function}.
|
|
\item The jump targets are now part of \textbf{main}, which you can verify by examining the Function graph.
|
|
\item Finally, navigate back to the \textbf{JMP} instruction and use the Script Manager to run \textbf{SwitchOverride.java}.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Shared Returns}
|
|
\begin{frame}
|
|
\begin{block}{Shared Returns}
|
|
\begin{itemize}
|
|
\item If a \textbf{callerOne} ends with call to \textbf{callee}, compilers will sometimes perform an optimization which replaces that final call with a jump.
|
|
\item If \textbf{callerOne} and \textbf{callerTwo} both end with calls to \textbf{callee}, this optimization will result in \textbf{callerOne} and \textbf{callerTwo}
|
|
ending with jumps to \textbf{callee}.
|
|
\item The \textbf{Shared Return Analyzer} detects this situation and modifies the flow of the jump instruction to have type \textbf{CALL\_RETURN}. This will change how
|
|
the functions are displayed in the decompiler.
|
|
\item You can also do this manually, in case the analyzer missed something (for example, if only one of the functions sharing a final call/jump has been found and disassembled).
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Shared Returns}
|
|
\begin{enumerate}
|
|
\item Uncheck the \textbf{Shared Return Calls} analyzer before analyzing \textbf{sharedReturn}.
|
|
\item This file has been stripped of symbols. To find \textbf{main}, navigate to \textbf{entry} and look for the call to \textbf{\_\_libc\_start\_main}. The first argument to this
|
|
call corresponds to the \textbf{main} method in the source code.
|
|
\item \textbf{main} contains two calls to non-library functions. Each callee contains a \textbf{JMP} instruction corresponding to what was a function call in the source code.
|
|
\item Find these \textbf{JMP} instructions, right-click, select \textbf{Modify Instruction Flow...}, and change the flow to \textbf{CALL\_RETURN}. Verify that a new function call appears
|
|
in the decompilation.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Control Flow Oddities}
|
|
\begin{frame}
|
|
\begin{block}{Opaque Predicates}
|
|
\begin{itemize}
|
|
\item One anti-disassembly technique is to create an if-else statement with a condition that always evalutes to the same value, but complicated enough for this to be difficult to
|
|
determine statically.
|
|
\item This is an example of an \textbf{opaque predicate}.
|
|
\item The branch that is never taken can contain bytes sequences intended to thwart static analysis, such as sequences which disassemble to jumps to invalid targets.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Opaque Predicates}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{opaque}, then navigate to the function \textbf{main}.
|
|
\item \textbf{main} contains an opaque predicate. Find it and fix it by either:
|
|
\begin{enumerate}[(i)]
|
|
\item Changing a conditional jump to an unconditional jump using the instruction patcher. To patch an instruction, right-click on it in the Listing and select \textbf{Patch Instruction}.
|
|
\item Adding a (primary) reference with Ref-Type \textbf{JUMP\_OVERRIDE\_UNCONDITIONAL} on the appropriate conditional jump. The ``To Address'' of the reference should be the jump target.
|
|
To the decompiler, this will change the conditional jump to an unconditional jump.
|
|
\end{enumerate}
|
|
\item[] (hint on next slide)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Opaque Predicates}
|
|
\begin{itemize}
|
|
\item Hint: The opaque predicate is based on the fact that if you square an integer and reduce mod 4, you can only ever get 0 or 1. Look for a multiplication, modular reduction (optimized to a bitmask), and comparison in the assembly.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Jumps Within Instructions}
|
|
\begin{itemize}
|
|
\item The decompiler can repeatedly disassemble the same byte as part of different instructions as it follows flow.
|
|
\item The listing can't do this: each byte has to be assigned to one instruction.
|
|
\item One consequence is that the decompilation can be correct even if the listing shows a disassembly error.
|
|
\item This can happen when encountering certain anti-disassembly techniques.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Jumps Within Instructions}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{jumpWithinInstruction}, then navigate to the function \textbf{main}.
|
|
\item You should see an error in the disassemly but correct decompilation (with a warning). What's going on?
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Jumps Within Instructions}
|
|
\begin{itemize}
|
|
\item[] (advance for solutions)
|
|
\pause
|
|
\item \textbf{eb ff} is \textbf{JMP~.+1}. After this instruction executes, \textbf{ff~c0} are the bytes of the next instruction to execute. Clear the
|
|
instruction corresponding to \textbf{eb~ff} and then disassemble starting at \textbf{ff} to reveal the instructions that execute after \textbf{JMP~.+1}.
|
|
\item Note: After clearing and disassembling, right-click on the \textbf{SUB} instruction and select \textbf{Fallthrough} $\rightarrow$ \textbf{Auto Override}, which
|
|
will set the fallthrough address to be the address of the next instruction after \textbf{SUB} (skipping data). You should verify that setting this override makes
|
|
the function graph look better.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\section{Improving Decompilation: Data Mutability}
|
|
|
|
\subsection{Changing Data Mutability}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Data Mutability}
|
|
\begin{itemize}
|
|
\item \textbf{Data Mutability} refers to the assumptions Ghidra makes regarding whether a particular data element can change.
|
|
\item There are three data mutability settings:
|
|
\begin{enumerate}
|
|
\item normal
|
|
\item constant
|
|
\item volatile
|
|
\end{enumerate}
|
|
\item There are two ways to change data mutability:
|
|
\begin{enumerate}
|
|
\item Right-click on the (defined) data in the Listing and select \textbf{Settings...}
|
|
\item Set the mutability of an entire block of memory through the Memory Map (\textbf{Window} $\rightarrow$ \textbf{Memory Map} from the Code Browser).
|
|
\end{enumerate}
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Constant Data}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Constant Data}
|
|
\begin{itemize}
|
|
\item The decompiler will display the contents of a memory location if the contents are marked as constant.
|
|
\item Otherwise it will display a pointer to the location.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Constant Data}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{dataMutability}, then navigate to the function \textbf{main}.
|
|
\item Change the settings of the target of the pointer variable \textbf{writeable} to constant by right-clicking and selecting \textbf{Data} $\rightarrow$ \textbf{Settings...}
|
|
in the Listing. Verify that the changes are reflected in the decompiler.
|
|
\item Restore the data mutability and change it again by modifying the permissions of the appropriate block in the Memory Map.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Volatile Data}
|
|
\begin{frame}
|
|
\begin{block}{Volatile Data}
|
|
\begin{itemize}
|
|
\item Marking a data element as volatile tells the decompile to assume that the value of a variable could change at any time.
|
|
\item This can prevent certain simplifications.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Volatile Data}
|
|
\begin{enumerate}
|
|
\item Note that the decompiler prints warning comments at the top of \textbf{main} indicating that unreachable code blocks have been removed.
|
|
\item You can prevent this by selecting \textbf{Edit} $\rightarrow$ \textbf{Tool Options} $\rightarrow$ \textbf{Decompiler} $\rightarrow$ \textbf{Analysis} and unchecking
|
|
\textbf {Eliminate unreachable code}.
|
|
\item After doing this, you will see the global variable \textbf{status} appear in the decompilation. Note that it is set to zero and then tested. This is a hint that
|
|
\textbf{status} might be volatile.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Volatile Data}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{3}
|
|
\item Mark the data element labelled \textbf{status} as volatile and verify that additional code appears in the decompilation
|
|
of the function \textbf{main} (make sure to re-enable unreachable code elimination in the decompiler if you've disabled it).
|
|
\item Note: You might have to override the signature on the call to \textbf{printf} to get all of its arguments to appear in the decompilation.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\section{Improving Decompilation: Setting Register Values}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Setting Register Values}
|
|
\begin{itemize}
|
|
\item Setting a context register (for example, to select ARM or Thumb mode) is a common reason to set register values in Ghidra.
|
|
\item Additionally, if you set a register value at the beginning of a function, the value will be sent to the decompiler.
|
|
\item To set a register value, right-click on an address in the Listing and select \textbf{Set Register Values...}
|
|
\item This can be helpful if a register is used to store a global variable. Additionally, it can sometimes be helpful to set register values when trying to
|
|
understand a function. The decompiler will perform additional transformations, which may yield a simplified view of how the function behaves in restricted cases.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Global Variables}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{globalRegVars.so}, then navigate to the function \textbf{initRegisterPointerVar}.
|
|
\item This function stores the address of a global variable into a register. Determine the address and the register.
|
|
\item Set the value of the register to be the address at the beginning of the functions \textbf{setRegisterPointerVar} and \textbf{getRegisterPointerVar}. If you do it correctly,
|
|
\textbf{getRegisterPointerVar} should decompile to
|
|
\item[]\textbf{\{}
|
|
\item[]\textbf{~~~~return c;}
|
|
\item[]\textbf{\}}
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise: Simplifying Transformations}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{setRegister}, then navigate to the function \textbf{switchFunc}. Set the switch variable (in \textbf{RDI}) to a few different values and
|
|
observe the effect on the decompiled code.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
|
|
\section{Troubleshooting Decompilation}
|
|
|
|
\subsection{Identifying Problems in the Decompiled Code}
|
|
|
|
\begin{frame}
|
|
\begin{block}{\textbf{in\_}, \textbf{unaff\_}, and \textbf{extraout\_}}
|
|
\begin{itemize}
|
|
\item Occasionally, you may see variables in the decompiler view whose names begin with \textbf{in\_}, \textbf{unaff\_}, or \textbf{extraout\_}.
|
|
\item \textbf{in\_} or \textbf{unaff\_}: this typically indicates that a register is read before it is written (and it does not contain a parameter passed to the function).
|
|
\item Variables that begin with \textbf{extraout\_} can occur when the decompiler thinks that a value is being used that should have been killed by a call.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Pcode in the Decompiler View}
|
|
\begin{itemize}
|
|
\item Occasionally, you might see Pcode operations in the decompiler code.
|
|
\item Examples: \textbf{ZEXT, SEXT, SUB, CONCAT,...}
|
|
\item See the ``Decompiler'' section in the Ghidra help.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Potential Causes}
|
|
\begin{frame}
|
|
\begin{block}{Potential Causes}
|
|
\begin{enumerate}
|
|
\item The decompiler has a function signature wrong (either the signature of the function being decompiled or one of its callees).
|
|
\item A common situation is some kind of size mismatch, for example, the decompiler thinks that a call returns a 32-bit value but sees all of \textbf{RAX} being used.
|
|
But then where did the high 32 bits come from?
|
|
\item There's a register that actually contains a global parameter or is set as the side effect of a called function.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\subsection{Potential Fixes}
|
|
\begin{frame}
|
|
\begin{block}{Potential Fixes}
|
|
\begin{itemize}
|
|
\item To fix these issues, the first step is to try to determine if the decompiler is making an assumption that's false.
|
|
\item Oftentimes, you can correct such errors by:
|
|
\begin{itemize}
|
|
\item correcting function signatures
|
|
\item correcting sizes of data types
|
|
\item marking functions as inline
|
|
\end{itemize}
|
|
\item For example, if you see \textbf{in\_RAX} in the decompiled view, you should check if there's a call to a function whose return type is mistakenly marked as \textbf{void}.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Useful Tools}
|
|
\begin{itemize}
|
|
\item Script: \textbf{FindPotentialDecompilerProblems.java}: Decompiles all functions in a program, looks for problems, and displays them in a navigable table.
|
|
\item Script: \textbf{CompareFunctionSizesScript.java}: Decompiles all functions in a program and displays a table which contains the size of each function (in instructions) and
|
|
the size of each decompiled function (in Pcode operations). If a function has many instructions but the decompiled version is small, there could be an incorrect assumption regarding
|
|
the return value.
|
|
\item From the Code Browser, \textbf{Edit} $\rightarrow$ \textbf{Tool Options...} $\rightarrow$ \textbf{Decompiler} $\rightarrow$ \textbf{Analysis} $\rightarrow$ uncheck \textbf{Eliminate unreachable code}: might help diagnose issues.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
|
|
\subsection{Compiler vs. Decompiler}
|
|
\begin{frame}
|
|
\begin{block}{Compiler vs. Decompiler}
|
|
\begin{itemize}
|
|
\item Sometimes compilers can prove certain facts about special cases and use these facts to emit optimized code.
|
|
\item This can have consequences for the decompiled code.
|
|
\item This isn't an error, just something to keep in mind.
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Exercise}
|
|
\begin{enumerate}
|
|
\item Open and analyze the file \textbf{compilerVsDecompiler}.
|
|
\item The functions \textbf{calls\_memcmp} and \textbf{calls\_memcmp\_fixed\_len} implement \textbf{memcmp} using the \textbf{CMPSB.REPE} instruction.
|
|
\item Compare the decompiled view of these two functions. What differences do you see?
|
|
\item What accounts for these differences? (hint: examine the assembly code)
|
|
\item Note: To compare two functions side-by-side, bring up the \textbf{Functions} window (\textbf{Window} $\rightarrow$ \textbf{Functions} from the Code Browser), select
|
|
the two functions, right click and select \textbf{Compare Functions}. Use the tabs to switch between the Listing and Decompiler views.
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Solution}
|
|
\begin{enumerate}
|
|
\item[] (advance for solutions)
|
|
\pause
|
|
\item \textbf{calls\_memcmp\_fixed\_len} contains \textbf{in\_ZF} and \textbf{in\_CF} in the decompiled code, whereas \textbf{calls\_memcmp} does not.
|
|
\item In \textbf{calls\_memcmp\_fixed\_len}, the compiler knows that the loop will be executed at least once (\textbf{RCX} is set to 8).
|
|
\item However, in \textbf{calls\_memcmp}, the loop might be executed 0 times (\textbf{RCX} is set to \textbf{param3}).
|
|
\item This means that the compiler must initialize the flags \textbf{ZF} and \textbf{CF} in \textbf{calls\_memcmp}, but does not have to in \textbf{calls\_memcmp\_fixed\_len}, since
|
|
the loop is guaranteed to execute at least once and that comparison will set the flags.
|
|
\item[] (continued)
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{block}{Solutions}
|
|
\begin{enumerate}
|
|
\setcounter{enumi}{5}
|
|
\item This is the purpose of the \textbf{CMP RDX,RDX} instruction \textbf{calls\_memcmp} (which does not occur in \textbf{calls\_memcmp\_fixed\_len}).
|
|
\item The decompiler doesn't do the analysis to prove that a loop must execute at least once.
|
|
\item So in the decompiler's view, the values in \textbf{ZF} and \textbf{CF} at the beginning of \textbf{calls\_memcmp\_fixed\_len} might contribute to the return value (in the ``case''
|
|
when the loop body does not execute).
|
|
\end{enumerate}
|
|
\end{block}
|
|
\end{frame}
|
|
|
|
\end{document}
|
|
|