logging in or signing up Shiva Sunil_Rawat Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT lite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 159 Category: Entertainment License: All Rights Reserved Like it (0) Dislike it (0) Added: April 14, 2009 This Presentation is Public Favorites: 1 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Shiva Advances in ELF Binary Encryption : Shiva Advances in ELF Binary Encryption Shaun Clowes (shaun@securereality.com.au) Neel Mehta (nmehta@iss.net) The Encryptor’s Dilemma: : The Encryptor’s Dilemma: To be able to execute, a program’s code must eventually be decrypted A Losing Game : A Losing Game Thus binary encryption is fundamentally an arms race. The encryptors cannot win. Just make life hard for the attackers Encryption Keys : Encryption Keys If the encrypted executable has access to the encryption keys for the image: By definition a solid attack must be able to retrieve those keys and decrypt the program To reiterate, binary encryption can only slow a determined attacker Our Aim : Our Aim Introduce some novel new techniques. Advance the state of the art: Unix executable encryption technology trails Windows dramatically Promote interest in Reverse Engineering on Unix platforms Really a losing game : Really a losing game By describing the details of our encryptor in this speech we're making it dramatically easier to attack We'll release an encrypted version of the encryptor today Source release in 3 months We expect generic attacks will exist by then What’s the point? : What’s the point? An encryptor can be used to: Prevent trivial reverse engineering of algorithms Protect setuid programs (with passwords) Hide sensitive data/code in programs Standard Attacks : Standard Attacks A good encryptor will try to deter standard attacks: strace – System Call Tracing ltrace – Library Call Tracing fenris – Execution Path Tracing gdb – Application Level Debugging /proc – Memory Dumping strings – Don’t Ask Deterring Standard Attacks : Deterring Standard Attacks strings Encrypting the binary image in any manner will scramble the strings Deterring Standard Attacks : Deterring Standard Attacks ltrace, strace, fenris and gdb These tools are all based around the ptrace() debugging API Making that API ineffective against encrypted binaries would be a big step towards making them difficult to attack Deterring Standard Attacks : Deterring Standard Attacks /proc memory dumping Based on the idea that the memory image of the running process must contain the unencrypted executable A logical fallacy A good encryptor will invalidate it Countermeasures : Countermeasures The majority of attacks against encrypted executables (excluding static analysis) can be detected by the running program Unless the attacker notices and prevents it, the program can take offensive action Layers : Layers Static analysis is significantly harder if the executable is encrypted on more than one level The layers act like an onion skin The attacker must strip each layer of the onion before beginning work on the next level (Un) Predictable Behavior : (Un) Predictable Behavior Efforts to make encryptor behavior differ from one executable to another are worthwhile The less generic the methodology, the harder it is to create a generic unwrapper Shiva : Shiva The encyptor we'll present today tries to implement all of the defences we’ve described so far Our encryptor is designed to encrypt ELF executables on Linux machines Other (public) ELF Encryptors : Other (public) ELF Encryptors Burneye – Scut Multi layer encryption Strong password encryption “Host Key” encryption Entire executable decrypted to memory ELFcrypt – JunkCode Simple executable wrapper and obfuscator Shiva v0.95 : Shiva v0.95 Currently encrypts dynamic or static Linux ELF executables Does not handle shared libraries (yet) Encryptor / Decryptor : Encryptor / Decryptor Development of an ELF encryptor is really two separate programs Symmetrical operation Encryptor : Encryptor Normal executable, which performs the encryption process, wrapping the target executable Decryptor : Decryptor Statically-linked executable, which performs decryption and handles runtime processing Embedded within the encrypted executable Self contained Cannot link with libc etc. Shiva ELF Abstraction API : Shiva ELF Abstraction API Represent any ELF executable as a structure in memory Allows for easy manipulation of ELF executables within encryptor, not relevant for decryptor Dual-process Model (Evil Clone) : Dual-process Model (Evil Clone) Slave process (main executable thread) creates a controller process (the clone) Inter-ptrace (functional and anti-debug) x86 Assembly Byte-Code Generation : x86 Assembly Byte-Code Generation Allows for the generation of x86 assembly byte-code from within C (a basic assembler) Pseudo-random code generation, pseudo-random functionality Encryption Layers – Layer 1 : Encryption Layers – Layer 1 Initial Obfuscation Layer : Initial Obfuscation Layer Intended to be simple, to evade simple static analysis Somewhat random, generated completely by in-line ASM byte-code generation Encryption Layers – Layer 2 : Encryption Layers – Layer 2 Password Layer : Password Layer Optional Wrap entire executable with 128-bit AES encryption Key is SHA1 password hash, only as strong as the password Encryption Layers – Layer 3 : Encryption Layers – Layer 3 Crypt Blocks : Crypt Blocks Two important types – immediate map, map on-demand Controller process handles map on-demand blocks Random unmap Only small portion of executable decrypted at any time Instruction length parsing – necessary to create map on-demand blocks Crypt Block Mapping : Crypt Block Mapping Crypt Block Mapping : Crypt Block Mapping Crypt Block Encryption : Crypt Block Encryption Block content encrypted with strong algorithm Guess Code to generate keys made pseudo-randomly on the fly (asm byte-code) Keys are never stored in plain text Tries to bind itself to a specific location in memory (and other memory context) Dynamically Linked ELF’s : Dynamically Linked ELF’s Decryptor interacts with system’s dynamic linker Decryptor must map dynamic linker itself, and then regain control after linker is done Anti-debugging/disassembly : Anti-debugging/disassembly Inherent anti-debugging provided by dual-ptrace – link verified Catch tracing: Check eflags Check /proc/self/stat Anti-debugging/disassembly : Anti-debugging/disassembly Timing and SIGTRAP Simple SIGTRAP catch JMP into instructions – common anti-disassembly trick Problems Encountered, Solutions : Problems Encountered, Solutions Clone, ptrace, and signals Fork processing Exec processing Life without libc Simple implementations of malloc etc Current Limitations : Current Limitations Can’t handle vfork(), threads Can’t encrypt static executables that call fork() On Linux, exec() fails if the calling process tries to exec a setuid program Section Headers Nothing that can’t be solved by the next release ? Other work in progress: Burneye 2 - Scut : Other work in progress: Burneye 2 - Scut Divides programs into blocks at compile-time, decrypts one block at a time Determines decryption keys based on code-flow constraints of the original program Larger binaries; execute slower; must be statically linked Future Direction : Future Direction Ports to other OS’s/Architectures Support for shared libraries Advanced anti-debugging Advanced manipulation of assembly byte-code (branch instructions, relocation of static data) Adapting when people break it End of Presentation : End of Presentation Thanks for listening Questions? You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.
Shiva Sunil_Rawat Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT lite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 159 Category: Entertainment License: All Rights Reserved Like it (0) Dislike it (0) Added: April 14, 2009 This Presentation is Public Favorites: 1 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Shiva Advances in ELF Binary Encryption : Shiva Advances in ELF Binary Encryption Shaun Clowes (shaun@securereality.com.au) Neel Mehta (nmehta@iss.net) The Encryptor’s Dilemma: : The Encryptor’s Dilemma: To be able to execute, a program’s code must eventually be decrypted A Losing Game : A Losing Game Thus binary encryption is fundamentally an arms race. The encryptors cannot win. Just make life hard for the attackers Encryption Keys : Encryption Keys If the encrypted executable has access to the encryption keys for the image: By definition a solid attack must be able to retrieve those keys and decrypt the program To reiterate, binary encryption can only slow a determined attacker Our Aim : Our Aim Introduce some novel new techniques. Advance the state of the art: Unix executable encryption technology trails Windows dramatically Promote interest in Reverse Engineering on Unix platforms Really a losing game : Really a losing game By describing the details of our encryptor in this speech we're making it dramatically easier to attack We'll release an encrypted version of the encryptor today Source release in 3 months We expect generic attacks will exist by then What’s the point? : What’s the point? An encryptor can be used to: Prevent trivial reverse engineering of algorithms Protect setuid programs (with passwords) Hide sensitive data/code in programs Standard Attacks : Standard Attacks A good encryptor will try to deter standard attacks: strace – System Call Tracing ltrace – Library Call Tracing fenris – Execution Path Tracing gdb – Application Level Debugging /proc – Memory Dumping strings – Don’t Ask Deterring Standard Attacks : Deterring Standard Attacks strings Encrypting the binary image in any manner will scramble the strings Deterring Standard Attacks : Deterring Standard Attacks ltrace, strace, fenris and gdb These tools are all based around the ptrace() debugging API Making that API ineffective against encrypted binaries would be a big step towards making them difficult to attack Deterring Standard Attacks : Deterring Standard Attacks /proc memory dumping Based on the idea that the memory image of the running process must contain the unencrypted executable A logical fallacy A good encryptor will invalidate it Countermeasures : Countermeasures The majority of attacks against encrypted executables (excluding static analysis) can be detected by the running program Unless the attacker notices and prevents it, the program can take offensive action Layers : Layers Static analysis is significantly harder if the executable is encrypted on more than one level The layers act like an onion skin The attacker must strip each layer of the onion before beginning work on the next level (Un) Predictable Behavior : (Un) Predictable Behavior Efforts to make encryptor behavior differ from one executable to another are worthwhile The less generic the methodology, the harder it is to create a generic unwrapper Shiva : Shiva The encyptor we'll present today tries to implement all of the defences we’ve described so far Our encryptor is designed to encrypt ELF executables on Linux machines Other (public) ELF Encryptors : Other (public) ELF Encryptors Burneye – Scut Multi layer encryption Strong password encryption “Host Key” encryption Entire executable decrypted to memory ELFcrypt – JunkCode Simple executable wrapper and obfuscator Shiva v0.95 : Shiva v0.95 Currently encrypts dynamic or static Linux ELF executables Does not handle shared libraries (yet) Encryptor / Decryptor : Encryptor / Decryptor Development of an ELF encryptor is really two separate programs Symmetrical operation Encryptor : Encryptor Normal executable, which performs the encryption process, wrapping the target executable Decryptor : Decryptor Statically-linked executable, which performs decryption and handles runtime processing Embedded within the encrypted executable Self contained Cannot link with libc etc. Shiva ELF Abstraction API : Shiva ELF Abstraction API Represent any ELF executable as a structure in memory Allows for easy manipulation of ELF executables within encryptor, not relevant for decryptor Dual-process Model (Evil Clone) : Dual-process Model (Evil Clone) Slave process (main executable thread) creates a controller process (the clone) Inter-ptrace (functional and anti-debug) x86 Assembly Byte-Code Generation : x86 Assembly Byte-Code Generation Allows for the generation of x86 assembly byte-code from within C (a basic assembler) Pseudo-random code generation, pseudo-random functionality Encryption Layers – Layer 1 : Encryption Layers – Layer 1 Initial Obfuscation Layer : Initial Obfuscation Layer Intended to be simple, to evade simple static analysis Somewhat random, generated completely by in-line ASM byte-code generation Encryption Layers – Layer 2 : Encryption Layers – Layer 2 Password Layer : Password Layer Optional Wrap entire executable with 128-bit AES encryption Key is SHA1 password hash, only as strong as the password Encryption Layers – Layer 3 : Encryption Layers – Layer 3 Crypt Blocks : Crypt Blocks Two important types – immediate map, map on-demand Controller process handles map on-demand blocks Random unmap Only small portion of executable decrypted at any time Instruction length parsing – necessary to create map on-demand blocks Crypt Block Mapping : Crypt Block Mapping Crypt Block Mapping : Crypt Block Mapping Crypt Block Encryption : Crypt Block Encryption Block content encrypted with strong algorithm Guess Code to generate keys made pseudo-randomly on the fly (asm byte-code) Keys are never stored in plain text Tries to bind itself to a specific location in memory (and other memory context) Dynamically Linked ELF’s : Dynamically Linked ELF’s Decryptor interacts with system’s dynamic linker Decryptor must map dynamic linker itself, and then regain control after linker is done Anti-debugging/disassembly : Anti-debugging/disassembly Inherent anti-debugging provided by dual-ptrace – link verified Catch tracing: Check eflags Check /proc/self/stat Anti-debugging/disassembly : Anti-debugging/disassembly Timing and SIGTRAP Simple SIGTRAP catch JMP into instructions – common anti-disassembly trick Problems Encountered, Solutions : Problems Encountered, Solutions Clone, ptrace, and signals Fork processing Exec processing Life without libc Simple implementations of malloc etc Current Limitations : Current Limitations Can’t handle vfork(), threads Can’t encrypt static executables that call fork() On Linux, exec() fails if the calling process tries to exec a setuid program Section Headers Nothing that can’t be solved by the next release ? Other work in progress: Burneye 2 - Scut : Other work in progress: Burneye 2 - Scut Divides programs into blocks at compile-time, decrypts one block at a time Determines decryption keys based on code-flow constraints of the original program Larger binaries; execute slower; must be statically linked Future Direction : Future Direction Ports to other OS’s/Architectures Support for shared libraries Advanced anti-debugging Advanced manipulation of assembly byte-code (branch instructions, relocation of static data) Adapting when people break it End of Presentation : End of Presentation Thanks for listening Questions?