P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\titulka.jpg
PV204 Security technologies
Rootkits, reverse engineering of binary applications, whitebox model
•Petr Švenda svenda@fi.muni.cz
•Faculty of Informatics, Masaryk University

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
What is planned for this lecture?
•Rootkits (and defences)
•Reverse engineering (of binary applications)
•Whitebox attacker model
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
K. Thompson – Reflections on Trusting Trust
•Subverted C compiler (Turing Award Lecture, 1983)
–Adds additional functionality for selected compiled programs
–E.g., login cmd: log password or allow user with specific name
•Inspection of login’s source code will not reveal any issues
•Adds malicious functionality of compiler into binary of compiler compiled with already subverted
compiler
–Inspection of source code of compiler will not reveal any problem
•How can we detect modified login binary?
–Expected hash, digital signatures
–What if modified signature verification tool?
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
ROOTKITS
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Rootkit definition
•Root-kit
–root user *nix systems
–kit set of tools to operate/execute commands
•Rootkit is piece or collection of software
–Designed to enable access where it would be otherwise denied
–Tries to hide(“cloak”) its presence in system
•Installed after obtaining privileged access
–Privileged escalation, credentials compromise, physical access…
•Rootkit != exploit (rootkit usually installed after exploit)
•Rootkit is usually accompanied with additional payload
–Payload does the actual (potentially malicious) work
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Protection rings
•Idea: introduce separate runtime levels
–crash in level X causes issue only in levels >=X
–Direct support provided by CPU architectures
•Ring 3: unprivileged user programs
•Ring 2/1: device drivers
•Ring 0: kernel programs
•Performance penalty associated with ring switching
–In practice, only 3 and 0 are commonly used
•Captures only rings/levels starting with OS
–Levels -1/-2/-3 introduced for layers below OS
–
| PV204: Rootkits, RE
D:\Documents\Obrazky\442px-CPU_ring_scheme.svg.png

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Rootkit
•
| PV204: Rootkits, RE
Ring -3
Ring -2
System Management Mode, BIOS
Firmware, hardware
Ring -1
Hypervisory-level (VT-x, AMD-V)
Ring 0
OS kernel, device drivers
Ring 1,2
Device drivers
Ring 3
User-mode
Ring “3+”
Managed code (runtime, JVM)
SMM abuse, bootkits
FW/HW rootkits
Hypervisory-level rootkits
Kernel rootkits
User-mode rootkits
Managed code rootkits
Ring level

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Principal ways of detection of rootkits
1.Detection running on system, same or higher level
–Flaws in rootkit cloaking, side-channel
2.Detection running on system, lower level
–Not controlled by rootkit, cannot cloak itself
3.Detection via (offline) image of system / memory
–Rootkit is not running => cannot cloak itself
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
•Alternative taxonomy – how interfaced with system
Types of offensive software (wrt OS)
Category
Interface to system
Location
Examples
Type 0
Existing APIs
Rings 3, 0
Filter driver, Browser helper objects, injected DLL/thread
Type I
Modified static components
Rings 3, 0
Hooking, patching, bootkits
Type II
Modified dynamic components
Rings 3, 0
Direct kernel object modification, Rogue callbacks
Type III
Outside of the system
Rings -1, -2,-3
Rogue hypervisor, firmware mod
| PV204: Rootkits, RE
J. Rutkowska, Introducing Stealth Malware Taxonomy

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Detection of rootkits
•Signature-based
–Files, mutexes… present on infected system
•Behavioural-based (lecture 7)
–Communication, hooks, latency…
•Integrity checking
–Detected modification of critical system files
–Prevent execution of modified files
–Memory dumps (lecture 8)
–Detect rootkit when not running (!cloaked)
–Rootkit detection tools (lectures 7,8)
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
User-mode rootkits (Ring 3)
•Injects payload into other user applications
–Injection of modified dlls (user app will use different CreateFile)
–Modification of applications (modification of CreateFile)
•Interception of messages
–RegisterWindowMessage()
•Function hooking
–More generic hooks (SetWindowsHookEx()) – window manager
–User application-specific hooks (plugins, example browser hook)
•File-system filters
–Detect access to files by user application
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Managed code rootkits (MCR) (Ring 3)
•Ring 3 (level for runtime / VM)
•Targets runtime environments for interpreted code
–.NET VM, Java VM and Dalvik runtime…
•Large attack surface for MCR
–Attacking runtime class libraries
–Attacking JIT compiler
–Abusing runtime instrumentation features
–Extending language with malware API
–Object-oriented malware (inside OO runtime)
•E. Metula: Managed Code Rootkits (Syngress)
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Kernel-mode rootkits (Ring 0)
•Runs with highest system privileges
–Usually device drivers and loadable modules
–Device drivers in MS Windows
–Loadable kernel modules in Linux
•Direct kernel object manipulation
–Data structures like list of processes…
–System Service Descriptor Table (SSDT) hook
–System call table hook
•Operating system may require mandatory drivers signing
–More difficult to insert malicious driver
–Still possible (compromised private keys: Stuxnet & Realtek’s keys)
–Rootkits below OS level
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
ROOTKITS BELOW OS LEVEL
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Hypervisory-level rootkits (Ring -1)
•Virtual-machine based rootkit (VMBR)
–Type II hypervisors (VM under ordinary OS host)
•Based on CPU hardware virtualization features
–Intel VT or AMD-V
•Rootkit hosts original target as virtual machine
–And intercepts all relevant hardware calls
•Examples: SubVirt, BluePill (AMD-V, Intel VT-x)
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
•
| PV204: Rootkits, RE
D:\Documents\Obrazky\vmbr_after.png
King et al: SubVirt: Implementing malware with virtual machines
Hypervisory-level rootkits (Ring -1)

>

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Defense against hypervisory-level rootkits
•Run detection/prevention on lower level
•Detect by timing differences of operations
–System is emulated => side-channel info (timings…)
•Read and analyze HDD physical memory
–After physical removal from (infected) computer
•Boot from safe medium (CD, USB, network boot)
–inspect before VMBR loads
–But VMBR can emulate shutdown / reboot
•Physical power unplug recommended
•Trusted boot (based on TPM, lecture 13)
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
System Management Mode abuse (R.-2)
•System Management Mode (SMM)
–x86 feature since Intel 386, all normal execution is suspended
–Used for power management, memory errors, hardware-assisted debugger…
–High-privilege mode (Ring -2)
•SMM entered via system management interrupt (SMI)
–System cannot override or disable the SMI
•Target for rootkits
–Modify memory, loaders, MBR…
–
–
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
SMM Example: SOUFFLETROUGH implant
•
•
•
•
•
•
•
•
•
•
•
•https://en.wikipedia.org/wiki/NSA_ANT_catalog
•http://leaksource.info/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-sof
tware-hardware-firmware/
•
•
| PV204: Rootkits, RE
D:\Documents\Obrazky\ant_souffle.png

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Bootkit rootkits (Ring -2)
•Bootkit  = Rootkit + Boot capability
•Infect startup code
–Master Boot Record (MBR)
–Volume Boot Record (VBR)
–Boot sector, BIOS routines…
•“Evil maid” attack
–Can be used to attack full disk encryption
–Assumption: user will left device physically unattended
–Legitimate bootloader replaced (+ key capture)
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Full-disk encryption compromise
1.Full-disk encryption used to encrypt all data
2.Laptop powered down to prevent Coldboot or FireWire-based attacks (read key from memory)
3.Laptop left unattended (“Evil maid” enters)
–USB used to read part of first sector of disk
–If TrueCrypt/Bitlocker loader, then insert malicious bootloader
4.User is prompted with forged bootloader
–Password is stored
•How to transfer saved password / data to attacker?
–Second visit of Evil maid
•
| PV204: Rootkits, RE
http://theinvisiblethings.blogspot.co.uk/2009/10/evil-maid-goes-after-truecrypt.html

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Bootkit defenses
•Prevention of physical access
–Problematic for portable devices
•Trusted boot (static vs. dynamic root of trust)
–More in Lecture 13 (Trusted boot)
–But bootloader must authenticate itself to user
•E.g., present image encrypted by key stored in TPM
•Before user enters its password
•Defense by external verification of bootloader integrity
–verify relevant unencrypted parts of disk (external USB)
–
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
•
| PV204: Rootkits, RE
D:\Documents\Obrázky\bootProcess.png
http://technet.microsoft.com/en-US/windows/dn168167.aspx

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Firmware / hardware rootkits (Ring -3)
•Persistent malware image in hardware
–Network card, router, hard drive…
•Can run even after removal of device from target computer
–Once device is powered again
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Anti-forensic techniques
•How rootkits protects itself?
•
•Common system API functions used for hooking
•Hiding files
•Hiding processes
•RAM only rootkits
•Data destruction
•Data concealment
•Data transformation and fabrication
•
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
LEGITIMATE USES
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Legitimate uses of rootkits
•To whom is legitimacy measured?
•
•Hide true nature of network “honeypots”
•Protection of AV software against termination
•Anti-theft protections
•Digital rights management
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Sony BMG Extended copy protection
•Rootkit developed for (and approved) by Sony
–Intended to limit possibility for disk copy
–Users were not notified (silently installed after CD insert)
–Digital rights management for Sony
–To hide itself, any file starting with $sys$ was hidden
•Detected by M. Russinovich’s RootkitRevealer
–After public disclose, other malware started to hide itself by naming its files as $sys$ (user was
already “infected”)
•Sony released patch for removal (web-based uninstaller)
–Even more serious flaw introduced (any visited page can install and run program)
–Resulted in class-action lawsuit against Sony BMG
–
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
REVERSE ENGINEERING
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Reverse engineering
•A process of knowledge or design extraction from final product (usually man-made)
•Engineering:
–Mental model ® blueprints/source-code ® product/binary
•Reverse engineering (back engineering):
–From product back to knowledge or design
–Blueprints/source-code might be also recreated
•Not necessary/possible to perfectly recreate design
–Engineering might be loose transformation
–Back engineering might not be perfect/complete
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Reverse engineering is general process
We will focus on software binaries only
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Reverse engineering - legal issues
•Reverse engineering is legal when
–Own binary without documentation
–Anti-virus research, Forensics…
–Interoperability, Fair use, education
•Problem with some copyright laws
–not only selling circumvented content, but also attempt to circumvent is illegal
•EFF Coders’ Rights Project Reverse Engineering FAQ
–Legal doctrines, Risky aspects, Selected decisions
–https://www.eff.org/issues/coders/reverse-engineering-faq
–
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
How to start reverse engineering
1.Learn basic concepts (compilers, memory, OS…)
2.See how source-code translates into binary
3.Try tools on simple examples (own code, tuts)
4.Utilize other knowledge (communication logs…)
5.Have fun! J
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Basics
•Debugger vs. debugger with binary modification  capabilities
–E.g., Visual Studio vs. OllyDbg
•Disassembler vs. debugger
–Static vs. dynamic code analysis
•Disassembler vs. decompiler
–Native code ® assembler ® source code
•Native code vs. bytecode
–Different instruction set, different execution model
•Registry-based vs. stack-based execution
–
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Compilation to native binary (C/C++)
1.Preprocessing "gcc -E hello.c > hello.i"
–Macro expansion, include insertion…
2.Compilation "gcc -s hello.i"
–Syntactic code control, most errors reported here
3.Assembly "as hello.s -o hello.o"
–Compilation from assembler to native executable
4.Link "gcc hello.o"
–Substitution of relative addresses by absolute
–
•Ordinary build executes all steps together
•
| PV204: Rootkits, RE
images

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Mixed source code/assembler in IDE
•Most current IDE supports mixed source code/assembler instructions mode (Visual Studio, QT
Creator...)
–Mode is usually available only during a debugging
–Write simple code (e.g., if then else condition), insert breakpoint and start debugging
•Switch to mixed mode
–Visual Studio®RClick®Go to disassembly
–QTCreator®Debug®Operate by Instruction
•Easy way to learn how particular source code is translated into assembler code
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
•
| PV204: Rootkits, RE
#include <stdio.h>
int main() {
    FILE* file = NULL;
    file = fopen("values.txt", "r");

    if (file) {
        int value1 = 0;
        int value2 = 0;
        fscanf(file, "%d", &value1);
        fscanf(file, "%d", &value2);

        value1 = value1 + value2;

        printf("Result: %d", value1);
    }
    fclose(file);
}
Original C source code
 Dump of assembler code for function main:
        2      int main() {
0x00401344  <+0>:              push   %ebp
0x00401345  <+1>:              mov    %esp,%ebp
0x00401347  <+3>:              and    $0xfffffff0,%esp
0x0040134a  <+6>:              sub    $0x20,%esp
0x0040134d  <+9>:              call   0x401a20 <__main>

        3          FILE* file = NULL;
0x00401352  <+14>:             movl   $0x0,0x1c(%esp)

        4          file = fopen("values.txt", "r");
0x0040135a  <+22>:             movl   $0x402030,0x4(%esp)
0x00401362  <+30>:             movl   $0x402032,(%esp)
0x00401369  <+37>:             call   0x401c90 <fopen>
0x0040136e  <+42>:             mov    %eax,0x1c(%esp)
...
       17     }
0x004013f5  <+177>:            leave
0x004013f6  <+178>:            ret
        End of assembler dump.

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Most common instructions/structures
•Most common ASM instructions
–Load/Store from to registers: MOV, LEA
–Arithmetic: ADD, INC…
–Relational: CMP, TEST
–Jumps: JMP, J*
–Functions: CALL, RET
•Example of typical structures (C® ASM)
–Conditional jump, for loop, function call…
–Familiarize via mixed source code/assembler in IDE
–Be aware of debug/release differences
–
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Jump operation
•Jump operation
–Unconditional JMP – jump every time
–Conditional - based on the current value of flag(s)
•JA* Jump if (unsigned) above - CF=0 and ZF=0
•JB* Jump if (unsigned) below - CF=1
•JE** Jump if equal - ZF=1
•JG* Jump if (signed) greater - ZF=0 and SF=OF (SF=SignFlag)
•JGE*Jump if (signed) gtr or equal - SF=OF
•JL* Jump if (signed) less - SF != OF (!= is not)
•JLE* Jump if (signed) less or equal - ZF=1 and OF != OF
•JMP** Jump - Jumps always
•JNE** Jump if not equal - ZF=0
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Conditional branching
•Conditional branching is usually realized by two consecutive operations:
1.Comparison operation setting Flags register
2.a) Conditional jumping operation to address based on Flags (Branch 1)
2.B) If not jumped then Branch 2 code is directly present starting with a next instruction, or
unconditional jump JMP to Branch 2 is present
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Comparison operations
•CMP EAX, -1 - will set flag(s) in Registers
–Zero and Sign flags are usually of interest
–If two values are same (EAX == -1), Zero flag is set to 1
•TEST A, B (usually TEST EAX, EAX)
–logical AND operation
–results not saved, Flags are set
–TEST EAX, EAX will test if value in EAX is equal to 0
•If EAX == 0 then Zero flag == 1, 0 otherwise
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Compilation to bytecode (Java, C#)
•Source code compiled into intermediate bytecode
–Java bytecode,.NET CLI ...
•Intermediate code interpreted by virtual machine
•Just-in-time compilation
–Intermediate code is compiled by VM into native code
–Improve performance significantly
–Relevant for dynamic analysis, not for static analysis
•Usually easier to understand then assembler code
–
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
STRUCTURE OF EXECUTABLE
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
| PV204: Rootkits, RE
C:\Users\E525127\Documents\School\Prednasky\English PE Walkthrough.png
PE File Format
Structure of Win32 binary executable

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Structure of Linux binary executable
•ELF format
| PV204: Rootkits, RE
D:\Documents\Obrazky\740px-Elf-layout--en.svg.png

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Structure of Java bytecode classfile
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
REGISTRY VS. STACK-BASED EXECUTION
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Registry-based execution
1.Values loaded (mov) from RAM to CPU registers
2.CPU operation (add, inc, test…) is executed
3.Resulting value is stored back (mov) to RAM
•Name of the registers
–EAX 32bit, AX 16bit, AH/AL 8bit
–EIP ... next address to execute (instruction pointer)
–EBX ... usually loop counter
•Registers
–Z – zero flag, C – carry flag, S – sign flag…
–
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Add two numbers from file (HDD)
1.Read values from HDD into RAM memory
lfscanf(file, "%d", &value);
2.Move value from RAM memory to CPU registry
lMOV   0x48(%esp),%eax
lMOV   0x44(%esp),%edx
3.Execute CPU instruction (e.g., ADD)
lADD    %edx,%eax
4.Transfer result from CPU register to RAM memory
lMOV   %eax, 0x48(%esp)
5.Save result from RAM memory to file
lfprintf(file, "%d", value);
•
| PV204: Rootkits, RE
cpu memory gnome-dev-harddisk memory gnome-dev-harddisk
out.txt
"30"
10
20
30
30
20
in.txt
"10 20"
10

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Stack-based execution
•Bytecode contains sequence of operations
•Bytecode contains constants
•All intermediate values stored on stack
•Interpret:
1.Reads next operation from bytecode
2.Pop operand(s) for next operation from top of stack
3.Executes operation
4.Push result of operation on top of stack
•No registers are used
–all operands for current operation at the top of the stack
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Example: JavaCard bytecode
–
•
| PV204: Rootkits, RE
// ENCRYPT INCOMING BUFFER
  void Encrypt(APDU apdu) {
      byte[]    apdubuf = apdu.getBuffer();
      short     dataLen = apdu.setIncomingAndReceive();
      short     i;

      // CHECK EXPECTED LENGTH (MULTIPLY OF 64 bites)
      if ((dataLen % 8) != 0)
         ISOException.throwIt(SW_CIPHER_DATA_LENGTH_BAD);

      // ENCRYPT INCOMING BUFFER
      m_encryptCipher.doFinal(apdubuf, ISO7816.OFFSET_CDATA, dataLen,
                              m_ramArray, (short) 0);

      // COPY ENCRYPTED DATA INTO OUTGOING BUFFER
      Util.arrayCopyNonAtomic(m_ramArray, (short) 0, apdubuf,
                              ISO7816.OFFSET_CDATA, dataLen);

      // SEND OUTGOING BUFFER
      apdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA, dataLen);
  }
.method  Encrypt(Ljavacard/framework/APDU;)V 129 {
  .stack 6;
  .locals 3;
  .descriptor     Ljavacard/framework/APDU;       0.10;
L0:     aload_1;
       invokevirtual 30;
       astore_2;
       aload_1;
       invokevirtual 42;
       sstore_3;
       sload_3;
       bspush 8;
       srem;
       ifeq L2;
L1:    sspush 26384;
       invokestatic 41;
       goto L2;
L2:    getfield_a_this 1;
       aload_2;
       sconst_5;
       sload_3;
       getfield_a_this 10;
       sconst_0;
       invokevirtual 43;
       pop;
       getfield_a_this 10;
       sconst_0;
       aload_2;
       sconst_5;
       sload_3;
       invokestatic 44;
       pop;
       aload_1;
       sconst_5;
       sload_3;
       invokevirtual 45;
       return;
}
Resulting JavaCard bytecode
Original JavaCard source code

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
DISASSEMBLING
•Recovering information from binary executables
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Disassembling of native binaries
•Reversing process of compilation
–Back from native code to ASM
•Compilation/assembly is loose process:
–Variable/function names
–Unused structures
–Performance optimization applied during compilation
•Wide range of native platforms
–Differences in support and performance of disassemblers
•Bytecode is already on the level of “disassembled” binaries (usually easier to understand)
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Structured code vs. sequence of executed ops
•Structured code contains code for all branches
–runnable binary/bytecode
•Information loss in compiled binary
–Stripped metadata and debugging symbols
–Compiler optimizations
•Sequence of executed instructions only from branches taken
–E.g., power analysis of smart card
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Structured code vs. sequence of executed ops
•
| PV204 Trusted element 25.2.2016
R32_JCBytecode_example
(source code)
m_ram1[0] = (byte) (m_ram1[0] % 1);
(bytecode)
getfield_a_this 0;
sconst_0;
baload;
sconst_1;
srem;
bastore;
(power trace)
compiler
oscilloscope
55
Bytecode reconstruction
(partial bytecode)
…; sconst_???; baload; sconst_???; srem; bastore;…

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Tool: OllyDbg
| PV204: Rootkits, RE
•Free disassembler and binary debugger
–Works with Windows 32b binaries only
–OllyDbg 64b version in development
•Easy to start with, many tutorials
•Designed to make changes in binary easy
–Change of jumps/data (valid PE is recreated)
•http://www.ollydbg.de/
•

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Tool: IDA Pro
•Interactive Disassembler is legendary full-fledged disassembler with ability to disassemble many
different platforms
•Free version available for non-commercial uses
–http://www.hex-rays.com/idapro/idadownfreeware.htm
•Free version disassemble only Windows binaries
•Very nice visualization and debugger feature (similar as OllyDbg)
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Tool: Online disassembler (ODA)
•https://www.onlinedisassembler.com/odaweb/
•
–
| PV204: Rootkits, RE
D:\Documents\Obrazky\oda_web.png

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Tool: Hopper diassembler and debugger
•Linux and OS X reverse engineering tool
–Older version supported Windows, but not anymore
•http://www.hopperapp.com
•Additional support for on Objective-C
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
•Graph representation of control flow
•Separated functions/blocks
–connection by jump instructions
Control flow graph
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Decompilation
•Native code decompilation
–Decompiler produces source code from binary/ASM/bytecode code
–Decompiler needs to do disassembling first and then try to create code that will in turn produce
binary code you have at the beginning
–Resulting code will NOT contain information removed during compilation (comments, function names,
formatting...)
•Bytecode decompilation
–usually much easier (more information preserved)
–Mapping between source code and bytecode is less ambiguous
–Compilation of decompiled bytecode produces similar bytecode
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Decompiler tools
•C/C++
–IDA
–REC Studio 4.0, http://www.backerstreet.com/rec/rec.htm
–Retargetable Decompiler, https://retdec.com/
•Java bytecode
–DJ Java Decompiler, http://neshkov.com/dj.html
–Java Decompiler, http://jd.benow.ca/
•.Net bytecode
–dotPeek, https://www.jetbrains.com/decompiler/
–ILSpy, http://ilspy.net/
–
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Resources
•Reverse Engineering for Beginners
–http://beginners.re/Reverse_Engineering_for_Beginners-en.pdf
–Great resource, many examples, tutorials
•Tutorials for You: http://www.tuts4you.com
•The Reverse Code Engineering Community: http://www.reverse-engineering.net/
•Disassembling tutorial http://www.codeproject.com/KB/cpp/reversedisasm.aspx
–
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
HOW TO PROTECT
•Protections Against Reverse Engineering
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Standard vs. whitebox attacker model
(symmetric crypto example)
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Whitebox attacker model
•The attacker is able to:
–inspect and disassemble binary (static strings, code...)
–observe/modify all executed instructions (OllyDbg...)
–observe/modify used memory (OllyDbg, memory dump...)
•How to still protect value of cryptographic key?
•Who might be whitebox attacker?
–Mathematician (for fun)
–Security researcher / Malware analyst (for work)
–DRM cracker (for fun&profit)
–...
–
–
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Classical obfuscation and its limits
•Time-limited protection
•Obfuscation is mostly based on obscurity
–add bogus jumps
–reorder related memory blocks
–transform code into equivalent one, but less readable
–pack binary into randomized virtual machine...
•Barak’s (im)possibility result (2001)
–family of functions that will always leak some information
–but practical implementation may exists for others
•Cannetti et. al. positive results for point functions
•Goldwasser et. al. negative result auxiliary result
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
CEF&CED
•Computation with Encrypted Data and Encrypted Function
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Scenario
•We’d like to compute function F over data D
–secret algorithm F or sensitive data D (or both)
•Solution with trusted environment
–my trusted PC, trusted server, trusted cloud…
•Problem: can be cloud or client really trusted?
–server hack, DRM, malware...
•Whitebox attacker model
–controls execution environment (debugging)
–sees all instructions and data executed
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
CEF
•Computation with Encrypted Function (CEF)
–A provides function F in form of P(F)
–P can be executed on B’s machine with B’s data D as P(D)
–B will not learn function F during computation
•
•
•
•
| PV204: Rootkits, RE
A
B

>

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
CED
•Computation with Encrypted Data (CED)
–B provides encrypted data D as E(D) to A
–A is able to compute its F as F(E(D)) to produce E(F(D))
–A will not learn D
| PV204: Rootkits, RE
A
B

>

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
CED via homomorphism
1.Convert your function into circuit with additions (xor) and multiplications (and) only
2.Compute addition and/or multiplication “securely”
–an attacker can compute E(D1+D2) = E(D1)+E(D2)
–but will learn neither D1 nor D2
3.Execute whole circuit over encrypted data
•Partial homomorphic scheme
–either addition or multiplication is possible, but not both
•Fully homomorphic scheme
–both addition and multiplication (unlimited)
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Partial homomorphic schemes
•Example with RSA (multiplication)
–E(d1).E(d2) = d1e . d2e mod m = (d1d2)e mod m = E(d1d2)
•Example Goldwasser-Micali (addition)
–E(d1).E(d2) = xd1r12 . Xd2r22 = xd1+d2(r1r2)2 = E(d1Åd2)
•Limited to polynomial and rational functions
•Limited to only one type of operation (mult or add)
–or one type and very limited number of other type
•Slow – based on modular mult or exponentiation
–every operation equivalent to whole RSA operation
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Fully homomorphic scheme - usages
•Outsourced cloud computing and storage
–FHE search, Private Database Queries
–protection of the query content
•Secure voting protocols
–yes/no vote, resulting decision
•Protection of proprietary info - MRI machines
–expensive algorithm analyzing MR data, HW protected
–central processing restricted due to private patient’s data
•…
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Fully homomorphic scheme (FHE)
•Holy grail - idea proposed in 1978 (Rivest et al.)
–both addition and multiplication securely
•But no scheme until 2009 (Gentry)!
–based on lattices over integers
–noisy FHE usable only for few operations
–combined with repair operation (enable to use it for more again)
–
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Fully homomorphic scheme - practicality
•Not very practical (yet J) (Gentry, 2009)
–2.7GB key & 2h computation for every repair operation
–repair needed every ~10 multiplication
•FHE-AES implementation (Gentry, 2012)
–standard PC Þ 37 minutes/block (but 256GB RAM)
•Gentry-Halevi FHE accelerated in HW (2014)
–GPU / ASICS, many blocks in parallel => 5 minutes/block
•Replacing AES with other cipher (Simon) (2014)
–2 seconds/block
•Very active research area!
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
White-box attack resistant cryptography
•Problem limited from every cipher to symmetric cryptography cipher only
–protects used cryptographic key (and data)
•Special implementation fully compatible with standard AES/DES… 2002 (Chow et al.)
–series of lookups into pre-computed tables
•Implementation of AES which takes only data
–key is already embedded inside
–hard for an attacker to extract embedded key
–Distinction between key and implementation of algorithm (AES) is removed
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
| PV204: Rootkits, RE
Whitebox transform

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Impractical solution
•
•
•
•
•
•
•
•
•Secure, but 2128 x 16B memory storage
| PV204: Rootkits, RE
00…00…00
00…00…01
00…01…11
11…11…11
01…11…11
…
…
10…01…11
10…11…01
01…11…11
10…00…10
01…10…00
…
…
2128
Input block
Output block = AES(input, keyX)
Precomputed table
2128

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
WBACR AES – some techniques
•Pre-compute table for all possible inputs
–practical for one 16bits or two 8bits arguments table with up to 216  rows (~64KB)
–AddRoundKey: data Å key
•8bit argument data, key fixed
•Pack several operations together
–AddRoundKey+SubBytes: T[i] = S[i Å key];
•Protect intermediate values by random bijections
–removed automatically by next lookup
–X = F-1(F(X))
–T[i] = S[F-1(i) Å key];
–
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
AES – short remainder (used ops)
| PV204: Rootkits, RE
Pictures taken from http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
| PV204: Rootkits, RE


P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Whitebox cryptography lifecycle
•[Secure environment]
1.Generate required key (random, database...)
2.Generate WAES tables (in secure environment)
•[Potential insecure environment]
3.Compile WAES tables into target application
•[Insecure environment (User PC)]
4.Run application and use WAES as usual (with fixed key)
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
•
| PV204: Rootkits, RE
makeTable()
precompTable
data
encrypted data
encrypt(data)
AES
key
Environment under control
of an attacker
Environment outside control
of an attacker

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Resulting implementation
•More difficult to detect that crypto was used
–no fixed constants in the code
–precomputed tables change with every generation
–even two tables for same key are different
–(but can still be found)
•Resistant even when precomputed tables are found
–when debugged, only table lookups are seen
–key value is never manipulated in plaintext
–transformation techniques should provide protection to key embedded inside tables
–
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Demo – WAES
•WAES tables generator
–configuration options
–*.h files with pre-computed tables
•WAES cipher implementation
–compile-in tables
–tables as memory blob
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
WAES performance
•Intel Core i5 M560@2.67GHz
| PV204: Rootkits, RE
L. Bacinska, https://is.muni.cz//th/373854/fi_m/

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
WBACR AES - pros
•Practically usable
–implementation size ~800KB (tables)
–speed ~MBs/sec (~6.5MB/s vs. 220MB/s)
•Hard to extract embedded key
–Complexity semi-formally guaranteed
–(if the scheme is secure)
•One can simulate asymmetric cryptography!
–implementation contains only encryption part of AES
–until attacker extracts key, decryption is not possible
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
WBACR AES - cons
•Implementation can be used as oracle (black box)
–attacker can supply inputs and obtain outputs
–even if she cannot extract the key
–(can be partially solved by I/O encodings)
•Problem of secure input/output
–protected is only AES, not code around
•Key is fixed and cannot be easily changed
•Successful cryptanalysis for several schemes
–several former schemes broken
–new techniques proposed
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Can whitebox transform replace secure hardware (e.g., smart card)?
•Only to limited extent
•Limitation of arguments size
•Operation atomicity
–one cannot execute only half of card’s operations
•No secure memory storage
–no secure update of state (counter)
•Both can be used as black-box
–smart card can use PIN to limit usage
•But still some reasonable usages remain
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
List of proposals and attacks
•(2002) First WB AES implementation by Chow et. al. [Chow02]
–IO bijections, linear mixing bijections, external coding
–broken by BGE cryptanalysis [Bill04]
•algebraic attack, recovering symmetric key by modelling round function by system of algebraic
equations
•(2006) White Box Cryptography: A New Attempt [Bri06]
–attempt to randomize whitebox primitives, perturbation & random equations added, S-boxes are enc.
keys. 4 AES ciphers, major voting for result
–broken by Mulder et. al. [Mul10]
•removes perturbations and random equations, attacking on final round removing perturbations,
structural decomposition. 217 steps
•(2009) A Secure Implementation of White-box AES [Xia09]
–broken by Mulder et. al. [Mul12]
•linear equivalence algorithm used (backward AES-128 compatibility => linear protection has to be
inverted in next round), 232 steps
•(2011) Protecting white-box AES with dual ciphers [Kar11]
–broken by our work [Kli13]
•protection shown to be ineffective
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
BGE attack in progress
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
More resources
•Overviews, links
–http://whiteboxcrypto.com/research.php
–https://minotaur.fi.muni.cz:8443/~xsvenda/docuwiki/doku.php?id=public:mobilecrypto
•Crackme challenges
–http://www.phrack.org/issues.html?issue=68&id=8
•Whitebox crypto in DRM
–http://whiteboxcrypto.com/files/2012_MISC_DRM.pdf
–
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
Whitebox transform IS used in the wild
•Proprietary DRM systems
–details are usually not published
–AES-based functions, keyed hash functions, RSA, ECC...
–interconnection with surrounding code
•Chow at al. (2002) proposal made at Cloakware
–firmware protection solution
•Apple’s FairPlay & Brahms attack
•http://whiteboxcrypto.com/files/2012_MISC_DRM.pdf
•...
•
•
| PV204: Rootkits, RE

P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg
•
| PV204: Rootkits, RE