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


- 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


- 5 -

Example of SRE Attacks in Android


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

https://www.arxan.com/wp-content/uploads/assets1/pdf/state-of-security-app-economy.pdf

- 6 -

Security threats: Mobile App Hack


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

http://www.arxan.com/

- 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


- 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


- 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


http://home.sogang.ac.kr/sites/gsinfotech/study/preClass/12345123/Lists/b6/Attachments/6/Sogang_Lecture3_2.pdf

http://newandroidbook.com/files/Andevcon-DEX.pdf

- 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


https://ibotpeaches.github.io/Apktool/

https://github.com/pxb1988/dex2jar

https://github.com/skylot/jadx

- 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?


- 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!


SRE Example on MS Windows


???????????

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!


Can Trudy find the serial number?

- 15 -

SRE Example – 2/6


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


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


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


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


Back to IDA Pro disassembly…

serial.exe

serialPatch.exe

SRE Attack Mitigation


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


- 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


- 23 -

Anti-disassembly Example


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


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


- 26 -

Anti-debugger Example -- 1/3


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 -



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 -



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)


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


Source:

Check against contamination of critical information

http://i.cs.hku.hk/cisc/projects/va/contam_index.html

http://i.cs.hku.hk/cisc/projects/va/contam_index.html

- 31 -

MD5, SHA256


Cryptographic hash functions

- 32 -

Code Obfuscation – 1/6

The International Obfuscated C Code Contest (https://www.ioccc.org/ )


https://www.ioccc.org/

- 33 -


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


- 34 -


Control flow obfuscation using opaque predicate


- 35 -


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


- 36 -


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


- 37 -


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!


Code Clone(Duplicate Code)


- 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]


- 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


- 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.


Secure SW Development

Penetrate and Patch

Open vs. Closed SW


- 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!


- 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”


- 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?


- 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.


- 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?


- 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


- 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!


- 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?


- 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


- 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


http://www.cl.cam.ac.uk/ftp/users/rja14/toulouse.pdf

- 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!


- 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


• What types of threat are related to this lecture?

‒ Consider the STRIDE model !

software reverse engineering (sre)securesw.dankook.ac.kr/iss19-1/iss_2019_07_sw_reversing.pdf ·...

Documents