Software Reverse Engineering (SRE)securesw.dankook.ac.kr/ISS19-1/ISS_2019_07_SW_Reversing.pdf ·...
Transcript of Software Reverse Engineering (SRE)securesw.dankook.ac.kr/ISS19-1/ISS_2019_07_SW_Reversing.pdf ·...
Seong-je Cho
Spring 2019
Computer Security & Operating Systems Lab, DKU
Introduction to Software Security
Software Reverse Engineering (SRE)(Chapter 12)
- 2 -
Sources / References
Textbook
N. Vlajic, CSE 3482: Introduction to Computer Security, Yorku
Nicholas Weaver, Computer Science 161: Computer Security, Berkeley
Myrto Arapinis, Computer Security: INFRA10067, University of Edinburgh
Please do not duplicate and distribute
Computer Security & OS Lab, DKU
- 3 -
Contents
Software Reverse Engineering = Reversing
Disassemble / Decompile / Debugging
Static analysis vs. Dynamic analysis
Anti-Reverse Engineering
Anti-disassemble
Anti-debugging
Code Clone
Secure Software Development
Open vs. Closed Source
Computer Security & OS Lab, DKU
- 4 -
Software Reverse Engineering (SRE)
Software Reverse Engineering Also known as Reverse Code Engineering (RCE) Or simply “reversing”
Can be used for good... Understand malware Understand legacy code
…or not-so-good Remove usage restrictions from software Find and exploit flaws in software Cheat at games, etc.
In the textbook, author assume that
Reverse engineer is an attacker
Attacker only has exe (no source code)
Attacker might want to
Understand the software
Modify the software
SRE usually focused on Windows in the past So the author focuses on Windows in the textbook
Computer Security & OS Lab, DKU
- 5 -
Example of SRE Attacks in Android
Computer Security & OS Lab, DKU
State of Mobile App Security
Report reveals an increase in App hacks for top 100 mobile apps(Wed., 25th Feb. 2015)
Source: Arxan Technologie
https://www.arxan.com/wp-content/uploads/assets1/pdf/state-of-security-app-economy.pdf
- 6 -
Security threats: Mobile App Hack
Computer Security & OS Lab, DKU
State of Security in the App Economy: (Source: www.arxan.com)
“Mobile Apps Under Attack”
More than 90% of top paid mobile apps have been hacked: 92% of Top 100 paid apps for Apple iOS and 100% of Top 100 paid apps for Android were found to have been hacked.
“Anatomy of an App Hack” involves three steps: 1. Define the exploit and attack targets, 2. Reverse-engineerthe code, and 3. Tamper with the code; this process is made easy with widely available free or low-cost hacking tools.
• Program infected with virus, DLL injection, Modified Ret by BoF
- 7 -
SRE Tools – 1/4
Disassembler Converts exe to assembly as best it can Cannot always disassemble correctly Generally, it is not possible to assemble disassembly into working exe Static analysis tool
Debugger Must step thru code to completely understand it Labor intensive lack of automated tools Dynamic analysis tool
Hex Editor To “patch” (make changes to) exe file
Decompiler
Computer Security & OS Lab, DKU
- 8 -
SRE Tools for MS Windows – 2/4
IDA Pro is the top-rated disassembler/decompiler Cost is a few hundred dollars Converts binary to assembly or source (as best it can)
SoftICE is “alpha and omega” of debuggers Cost is in the $1000’s Kernel mode debugger Can debug anything, even the OS
OllyDbg is a high quality shareware debugger Includes a good disassembler
Hex editor to view/modify bits of exe UltraEdit is good freeware HIEW (short for Hacker’s view) useful for patching exe
Regmon, Filemon, VMware, etc. Regmon and Filemon are no longer available Process Monitor combines the features of Filemon nd Regmon, and adds an extensive list of
enhancements» Process Monitor is an advanced monitoring tool for Windows that shows real-time file
system, Registry and process/thread activity
Computer Security & OS Lab, DKU
- 9 -
SRE for Android – 3/4
Creating an APK
References
Malware and Vulnerability Analysis, Lecture3-2, Malware Analysis #3-2http://home.sogang.ac.kr/sites/gsinfotech/study/preClass/12345123/Lists/b6/Attachments/6/Sogang_Lecture3_2.pdf
Dalvik and ART, Jonathan Levin -- http://newandroidbook.com/files/Andevcon-DEX.pdf
Computer Security & OS Lab, DKU
- 10 -
SRE Tools for Android – 4/4
apktool (https://ibotpeaches.github.io/Apktool/)
A tool for reverse engineering binary Android apps.
Disassembling resources to nearly original form (including resources.arsc, classes.dex, 9.png.
and XMLs)
Transforms binary Dalvik bytecode (classes.dex) into Smali code
It can decode resources to nearly original form and rebuild them after making some modifications.
dex2jar (https://github.com/pxb1988/dex2jar)
Tools to work with android .dex and java .class files
Converts Dalvik bytecode (DEX) to java bytecode (JAR)
jadx (https://github.com/skylot/jadx)
Dex to Java decompiler
Computer Security & OS Lab, DKU
- 11 -
Why is a Debugger Needed?
Disassembler/Decompiler gives static results Good overview of program logic
But need to “mentally execute” program
Difficult to jump to specific place in the code
Debugger is dynamic Can set break points
Can treat complex code as “black box”
Not all code disassembles correctly
Disassembler and debugger both required for any serious SRE task
How can you analyze the packed or encrypted malware?
What is packed malware?
Computer Security & OS Lab, DKU
- 12 -
SRE Necessary Skills
Working knowledge of target assembly code
Experience with the tools IDA Pro sophisticated and complex
SoftICE large two-volume users manual
apktool, dex2jar» Usage : apktool d[ecode] [OPTS] <file.apk> [<dir>]
Knowledge of Executable file format Windows Portable Executable (PE) file format
Android Dalvik Executable (DEX) file format
Boundless patience and optimism
SRE is tedious and labor-intensive process!
Computer Security & OS Lab, DKU
SRE Example on MS Windows
Computer Security & OS Lab, DKU
???????????
The source is not available to the attacker.
- 14 -
SRE Example – 1/6
Consider simple example
This example only requires disassembler (IDA Pro) and hex editor
Trudy disassembles to understand code
Trudy also wants to patch the code
For most real-world code, also need a debugger (SoftICE or OllyDbg)
Program requires serial number
But Trudy doesn’t know the serial number!
Computer Security & OS Lab, DKU
Can Trudy find the serial number?
- 15 -
SRE Example – 2/6
Computer Security & OS Lab, DKU
IDA Pro disassembly
What is serial number looks like? S123N456 Why?
Try the guessed serial number.
It works!
Can Trudy do better?
- 16 -
SRE Example – 3/6
Computer Security & OS Lab, DKU
Again, IDA Pro disassembly
And hex view…
test eax,eax gives AND of eax with itself• Result is 0 only if eax is 0• If test returns 0, then jz is true
Trudy wants jz to always be true!
Can Trudy patch exe so that jz always true?
- 17 -
SRE Example – 4/6
Computer Security & OS Lab, DKU
Can Trudy patch exe so that jz always true?
xor jz always true!!!
Assembly Hex
test eax, eax 85 C0
xor eax, eax 33 C0
- 18 -
SRE Example – 5/6
Computer Security & OS Lab, DKU
Edit serial.exe with hex editor
serial.exe
serialPatch.exe
Save as serialPatch.exe
Any “serial number” now works!
Very convenient for Trudy!
- 19 -
SRE Example – 6/6
Computer Security & OS Lab, DKU
Back to IDA Pro disassembly…
serial.exe
serialPatch.exe
SRE Attack Mitigation
Computer Security & OS Lab, DKU
One Motive
• Software cracking is a serious threat to many in the software
industry.
• Attackers can insert an unconditional jump to overpass the
serial number checker.
- 21 -
SRE Attack Mitigation
Impossible to prevent SRE on open system
But can make such attacks more difficult
Anti-disassembly techniques To confuse static view of code
Anti-debugging techniques To confuse dynamic view of code
Tamper-resistance 변조(조작)방지
Code checks itself to detect tampering
Code obfuscation 코드 난독화
Make code more difficult to understand
Computer Security & OS Lab, DKU
- 22 -
Anti-disassembly
Anti-disassembly methods include
Encrypted object code
False disassembly
Self-modifying code
Many others
Encryption prevents disassembly
But still need code to decrypt the code!
Same problem as with polymorphic viruses
Computer Security & OS Lab, DKU
- 23 -
Anti-disassembly Example
Computer Security & OS Lab, DKU
Nothing changes
with these steps ->
can mingle these
ops with other ops
(or even junk)
Jmp back to original entry point
Adding Junk
- 24 -
Anti-disassembly Example
Computer Security & OS Lab, DKU
Example of “false disassembly”
Suppose actual code instructions are
What a “dumb” disassembler sees
inst 1 inst 3jmp junk inst 4 …
inst 1 inst 5inst 2 inst 3 inst 4 inst 6 …
Clever attacker will figure it out!
- 25 -
Anti-debugging
IsDebuggerPresent()
Monitor for
Use of debug registers (six debug resisters, named DR0~DR7, on x86)
Inserted breakpoints
Debuggers don’t handle threads well
Interacting threads may confuse debugger
And therefore, confuse attacker
Many other debugger-unfriendly tricks
Undetectable debugger possible in principle
Hardware-based debugging (HardICE) is possible
Computer Security & OS Lab, DKU
- 26 -
Anti-debugger Example -- 1/3
Computer Security & OS Lab, DKU
Suppose when program gets inst 1, it pre-fetches inst 2, inst 3 and inst 4 This is done to increase efficiency
Suppose when debugger executes inst 1, it does not pre-fetch instructions
Can we use this difference to confuse the debugger?
inst 1 inst 5inst 2 inst 3 inst 4 inst 6 …
- 27 -
Anti-debugger Example -- 2/3
Computer Security & OS Lab, DKU
Memory Architecture CPU (register) --- (Cache M) Main M --- Disk M ….
Suppose inst 1 overwrites inst 4 in memory
Then program (without debugger) will be OK since it fetched inst 4 at same time as inst 1 at the CPU
And execute inst1 then inst 4 in memory will be junk, but the inst4 fetched at CPU is not changed
inst 1 inst 5inst 2 inst 3 inst 4 inst 6 …junk
- 28 -
Anti-debugger Example -- 3/3
Computer Security & OS Lab, DKU
But when debugger executes inst1, it does not prefetch instructions
So, debugger will be confused when it reaches junk where inst 4 is supposed to be
Problem for program if this segment of code executed more than once! (junk code will be problem)
Also, code is very platform-dependent
Again, clever attacker will figure this out!
- 29 -
Tamper-resistance (Guards)
Computer Security & OS Lab, DKU
Goal is to make patching more difficult Making programs “hard to modify”
Code can hash parts of itself
If tampering occurs, hash check fails
Research has shown, can get good coverage of code with small performance penalty
But don’t want all checks to look similar Or else easy for attacker to remove checks
This approach sometimes called “guards” Types of guard
Guard: a piece of code responsible for performing certain security-related actions during program execution.
Checksum code: Checksum another piece of program code at runtime and verify its integrity
Repair code
- 30 -
Hash Values Comparison Example
Computer Security & OS Lab, DKU
Source:
Check against contamination of critical information
http://i.cs.hku.hk/cisc/projects/va/contam_index.html
- 31 -
MD5, SHA256
Computer Security & OS Lab, DKU
Cryptographic hash functions
- 32 -
Code Obfuscation – 1/6
The International Obfuscated C Code Contest (https://www.ioccc.org/ )
Computer Security & OS Lab, DKU
- 33 -
Code Obfuscation – 2/6
Goal is to make code hard to understand Opposite of good software engineering! Simple example: spaghetti code
Much research into more robust obfuscation Example: opaque불명확한 predicate
int x,y
:
if((xy)(xy) > (xx2xy+yy)){…}
The if() conditional is always false
Attacker will waste time analyzing dead code
Computer Security & OS Lab, DKU
- 34 -
Code Obfuscation – 3/6
Control flow obfuscation using opaque predicate
Computer Security & OS Lab, DKU
- 35 -
Code Obfuscation – 4/6
Code obfuscation sometimes promoted as a powerful security technique
Diffie and Hellman’s original ideas for public key crypto were based on obfuscation!
» But it didn’t work
Recently it has been shown that obfuscation probably cannot provide “strong” security
On the (im)possibility of obfuscating programs
Some question significance of result (Thomborson)
Obfuscation might still have practical uses!
Even if it can never be as strong as crypto
Computer Security & OS Lab, DKU
- 36 -
Code Obfuscation – 5/6
Authentication Example
Software used to determine authentication
Ultimately, authentication is 1-bit decision Regardless of method used (pwd, biometric, …)
Somewhere in authentication software, a single bit determines success/failure
If attacker (Trudy) can find this bit, he can force authentication to always succeed
Obfuscation makes it more difficult for attacker to find this all-important bit
Computer Security & OS Lab, DKU
- 37 -
Code Obfuscation – 6/6
Obfuscation forces attacker to analyze larger amounts of code
Method could be combined with
Anti-disassembly techniques
Anti-debugging techniques
Code tamper-checking
All of these increase work (and pain) for attacker
But a persistent attacker will ultimately win!
Computer Security & OS Lab, DKU
Code Clone(Duplicate Code)
Computer Security & OS Lab, DKU
- 39 -
Software Cloning
Suppose we write a piece of software
We then distribute an identical copy (or clone) to each customers
If an attack is found on one copy, the same attack works on all copies
Popular code clone: Popular open-source such as Linux, open stack, Apache, …
This approach has no resistance to “break once, break everywhere” (BOBE)
This is the usual situation in software development
Duplicate Code
Increase maintenance effort and cost [LozanoICSM2008]
Error proneness when clones are updated inconsistently [JuergensICSE2009]
Code instability [MondalACM2012]
Developers care about duplicate code and they try to avoid duplicate code when performing maintenance tasks. [YamashitaUSER2013, SilvaFSE2016]
Computer Security & OS Lab, DKU
- 40 -
Code Clone Types
Clone Type I
Exact copy of an original code
Identical code fragments except for variations in whitespace (may be also variations in layout) and comments.
Clone Type II
Structurally/syntactically identical fragments except for variations in identifiers, literals, types, layout and comments
Computer Security & OS Lab, DKU
- 41 -
Code Clone Types
Clone Type III
Copied fragments with further modifications.
Statements can be changed, added or removed in addition to variations in identifiers, literals, types, layout and comments.
Computer Security & OS Lab, DKU
Secure SW Development
Penetrate and Patch
Open vs. Closed SW
Computer Security & OS Lab, DKU
- 43 -
Penetrate and Patch
Usual approach to software development
Develop product as quickly as possible
Release it without adequate testing
Patch the code as flaws are discovered
In security, this is “penetrate and patch”
A bad approach to software development
A horrible approach to secure software!
= An even worse approach to secure software!
Computer Security & OS Lab, DKU
- 44 -
Why Penetrate and Patch? 1/2
First to market advantage
First to market likely to become market leader
Market leader has huge advantage in software
Users find it safer to “follow the leader”
Boss won’t complain if your system has a flaw, as long as everybody else has the same flaw
User can ask more people for support, etc.
Sometimes called “network economics”
Computer Security & OS Lab, DKU
- 45 -
Why Penetrate and Patch? 2/2
Secure software development is hard
Costly and time consuming development
Costly and time consuming testing
Easier to let customers do the work!
No serious economic disincentive
Even if software flaw causes major losses, the software vendor is not liable
Is any other product sold this way?
Would it matter if vendors were legally liable?
Computer Security & OS Lab, DKU
- 46 -
Penetrate and Patch Fallacy
Fallacy: If you keep patching software, eventually it will be secure
Why is this a fallacy?
Empirical evidence to the contrary
Patches often add new flaws
Software is a moving target due to new versions, features, changing environment, new uses, etc.
Computer Security & OS Lab, DKU
- 47 -
Open vs Closed Source
Open source software The source code is available to user
For example, Linux
Close source software The source code is not available to user
For example, Windows
What are the security implications?
Computer Security & OS Lab, DKU
- 48 -
Open Source Security – 1/2
Claimed advantages of open source is More eyeballs: more people looking at the code should imply
fewer flaws
A variant on Kerchoffs Principle Kerckhoffs's principle is one of the basic principles of modern cryptography.
» A cryptographic system should be secure even if everything about the system, except the key, is public knowledge.
Is this valid? How many “eyeballs” looking for security flaws?
How many “eyeballs” focused on boring parts?
How many “eyeballs” belong to security experts?
Attackers can also look for flaws!
Evil coder might be able to insert a flaw
Computer Security & OS Lab, DKU
- 49 -
Open Source Security – 2/2
Open source example: wu-ftp About 8,000 lines of code
A security-critical application
Was deployed and widely used
After 10 years, serious security flaws discovered!
More generally, open source software has done little to reduce security flaws
Why? Open source follows penetrate and patch model!
Computer Security & OS Lab, DKU
- 50 -
Closed Source Security
Claimed advantage of closed source
Security flaws not as visible to attacker
This is a form of “security by obscurity”
Is this valid?
Many exploits do not require source code
Possible to analyze closed source code…
…though it is a lot of work!
Is “security by obscurity” real security?
Computer Security & OS Lab, DKU
- 51 -
Open vs Closed Source – 1/2
Advocates of open source often cite the Microsoft fallacy which states1. Microsoft makes bad software
2. Microsoft software is closed source
3. Therefore all closed source software is bad
Why is this a fallacy? Not logically correct
More relevant is the fact that Microsoft follows the penetrate and patch model !!!
No obvious security advantage to either open or closed source
More significant than open vs closed source is software development practices
Both open and closed source follow the “penetrate and patch” model
Computer Security & OS Lab, DKU
- 52 -
Open vs Closed Source – 2/2
If there is no security difference, why is Microsoft software attacked so often? Microsoft is a big target!
Attacker wants most “bang for the buck” (본전은 뽑을 수 있을 만한 가치)
Few exploits against Mac OS X Not because OS X is inherently more secure
An OS X attack would do less damage
Would bring less “glory” to attacker
Next, we’ll consider the theoretical differences between open and closed source
See Ross Anderson’s paper
Computer Security & OS Lab, DKU
- 53 -
Secure SW Development
Goal: move away from “penetrate and patch”
Penetrate and patch will always exist But if more care taken in development, then fewer and less severe flaws to
patch
Secure software development not easy, but should do
Microsoft Security Development Lifecycle (SDL)
Secure by default, Secure by design
Much more time and effort required thru entire development process
Today, little economic incentive for this!
Computer Security & OS Lab, DKU
- 54 -
Summary, Q & A
Software Reverse Engineering
Static vs. Dynamic analysis
Is Good or Bad?
Anti Reverse Engineering
Anti-debugging,
Code obfuscation
Code Integrity Verification
Code Clone
Open vs. Closed Source
Penetrate and Patch
Secure Software Development
Computer Security & OS Lab, DKU
• What types of threat are related to this lecture?
‒ Consider the STRIDE model !