JAMESSTEVENSON.
ME
REVERSE ENGINEERING CHEAT SHEET
PRACTICAL Specifications and Libraries, imports,
More...
STARTING POINTS complex functions and strings
TYPES OF Documentation Hardware Analysis
Review and Attack and Communication
SOFTWARE AND Surface Mapping Security
More...
PRODUCT REVIEW
Formulating a
RESEARCH THEORY Making observations
hypothesis
More...
OTHER RESOURCES Articles Books Courses
JAMESSTEVENSON.ME
The below lists a summary of practical starting points that can be applied to
Practical
any reverse engineering engagement:
Starting Points Specifications Complex Functions
Review the products specifications Identify large or complex functions
Sometimes it’s hard to know where to start when for entry points (e.g., where a in the source code. Also review
facing a completely new or unknown technology. Here message/ data is received). libraries and imports.
are some generic and high level approaches that can
be used to get the ball rolling on almost any
engagement.
Permissions Strings
If on an operating system (OS) with Use strings and log statements to
a strong sandboxing, look at what identify functionality. Also Look at
permissions are available. function and variable names if not
obfuscated.
Comms Emulation
Look at how comms (i.e. network If running on proprietary
traffic) are performed and if data hardware, look at approaches for
can be intercepted. emulation.
JAMESSTEVENSON.ME
Types Of Software and Product There are many places to start regarding reverse engineering, many types of products to
review, and a myriad of different approaches that fall into the reverse engineering or product
Review security review umbrella. Some of these are listed below:
Documentation Review Attack Surface Mapping Hardware Analysis
When reviewing published software or hardware, a Another initial phase of reverse engineering and During this phase (only applicable to physical devices),
common initial phase is to identify and review vulnerability research is to identify the attack surface it’s important to identify and assess all physical
available documentation – this could include high-level of the software or product being reviewed. This interfaces (i.e., JTAG, RS232, etc.). During this phase, it
design documentation, how-to guides, architecture involves identifying all communication vectors and is also pertinent to identify any tamper detection
diagrams, source code, and more. interfaces for the system and how a threat actor could mechanisms in place and to identify their
utilise them to gain access to the system. effectiveness. It may also be pertinent to extract the
firmware from the target device.
Reverse Engineering Communication Security Fuzzing
This phase involves taking any black-box software As part of the attack surface phase, the As part of an in-depth review of a system, it may be
components or firmware that you have access to and communication interfaces used by the device or pertinent to develop or use a fuzzer to trigger complex
identifying key components (commonly via software should have been mapped. During this phase, bugs in the system. Fuzzer’s use unexpected and
disassembling them). This phase may also involve it’s important to examine any security mechanisms in random data provided as input with the goal of
emulating key software components to understand place on top of those communication channels – attempting to cause a crash and identify a
programme flow. including encryption and certificate pinning. vulnerability.
Vulnerability Identification Remediation Identification
Depending on the type of research being performed, it Once a vulnerability has been identified, it is critical to
may be pertinent to review the system for potential focus on it and identify how the vulnerability can be
vulnerabilities. If this is the case, outcomes of the remediated and fixed.
above phases can be used to identify vulnerabilities in
the system.
JAMESSTEVENSON.ME
Make observations
I.e. What do you see in the
source code?
Think of an interesting
Develop general
question
theories
i.e. how is that specific
function reached?
Refine, alter, RESEARCH
expand, or reject Theory Formulate hypothesis
hypothesis i.e. if the function receives x
data y will happen
Gather data to test Develop testable
predictions predictions
i.e. specifications, source i.e. if this function is
code, firmware, etc reachable then a,b,c will
occur
JAMESSTEVENSON.ME
Android Software Learn Reverse
Internals Quick Engineering Through
Reference Android Games
https://www.JamesStevenson.me/androidbook/ www.Udemy.com/course/learn-reverse-engineering-
through-android-games/?
referralCode=CBA24934A92B1E58B76C
www.JamesStevenson.me/Articles
J JAMESSTEVENSON.ME
