DOCSLIB.ORG

HARDWARE SECURITY THROUGH DESIGN OBFUSCATION by RAJAT

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
HARDWARE SECURITY THROUGH DESIGN OBFUSCATION by RAJAT HARDWARE SECURITY THROUGH DESIGN OBFUSCATION by RAJAT SUBHRA CHAKRABORTY Submitted in partial fulfillment of the requirements For the degree of Doctor of Philosophy Thesis Adviser: Dr. Swarup Bhunia Department of Electrical Engineering and Computer Science CASE WESTERN RESERVE UNIVERSITY May, 2010 CASE WESTERN RESERVE UNIVERSITY SCHOOL OF GRADUATE STUDIES We hereby approve the thesis/dissertation of _____________________________________________________ candidate for the ______________________degree *. (signed)_______________________________________________ (chair of the committee) ________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________ (date) _______________________ *We also certify that written approval has been obtained for any proprietary material contained therein. ii To my family and friends. iii TABLE OF CONTENTS Page LIST OF TABLES :::::::::::::::::::::::::::::::: viii LIST OF FIGURES ::::::::::::::::::::::::::::::: x 1 Introduction :::::::::::::::::::::::::::::::::: 1 1.1 Background ::::::::::::::::::::::::::::::: 1 1.2 Security Threats :::::::::::::::::::::::::::: 2 1.3 Outline of Proposed Research ::::::::::::::::::::: 4 1.4 Major Contribution of the Proposed Research :::::::::::: 6 1.5 Organization of the Thesis ::::::::::::::::::::::: 7 2 Obfuscation-Based Secure SoC Design ::::::::::::::::::: 8 2.1 Introduction ::::::::::::::::::::::::::::::: 8 2.2 Related Work :::::::::::::::::::::::::::::: 10 2.3 Analysis of Netlist Obfuscation :::::::::::::::::::: 12 2.3.1 Hardware IP Piracy: the Hacker's Perspective :::::::: 13 2.3.2 Obfuscation Metric ::::::::::::::::::::::: 15 2.4 System-level Obfuscation Methodology :::::::::::::::: 17 2.4.1 State Transition Function Modification :::::::::::: 18 2.4.2 Embedding Authentication Features ::::::::::::: 19 2.4.3 Choice of Optimal Set of Nodes for Modification ::::::: 21 2.4.4 The HARPOON Design Methodology ::::::::::: 22 2.5 Results :::::::::::::::::::::::::::::::::: 26 2.5.1 Simulation Setup :::::::::::::::::::::::: 26 2.5.2 Results for ISCAS-89 Benchmark Circuits :::::::::: 26 2.5.3 Results for the AES Encryption/Decryption Unit :::::: 32 2.5.4 Mode control through unreachable states ::::::::::: 33 iv Page 2.6 Summary :::::::::::::::::::::::::::::::: 36 3 RTL Hardware IP Protection through Obfuscation ::::::::::::: 37 3.1 Introduction ::::::::::::::::::::::::::::::: 37 3.2 Obfuscation Methodology ::::::::::::::::::::::: 38 3.2.1 STG Modification Approach :::::::::::::::::: 39 3.2.2 CDFG Modification Approach ::::::::::::::::: 42 3.2.3 Comparison between the Two Approaches :::::::::: 47 3.2.4 Obfuscation-based Secure SoC Design Flow ::::::::: 48 3.3 Measure of Obfuscation Level ::::::::::::::::::::: 48 3.3.1 Manual Attacks by Visual Inspection ::::::::::::: 48 3.3.2 Simulation-based Attacks ::::::::::::::::::: 49 3.3.3 Structural Analysis based Attack ::::::::::::::: 49 3.3.4 Quantitative Comparison of the Two Proposed Approaches : 54 3.4 Results :::::::::::::::::::::::::::::::::: 54 3.4.1 Design Flow Automation :::::::::::::::::::: 54 3.4.2 Simulation Verification ::::::::::::::::::::: 56 3.4.3 Effect of Key Length :::::::::::::::::::::: 59 3.5 Discussions ::::::::::::::::::::::::::::::: 61 3.5.1 Using Unreachable States during Initialization :::::::: 62 3.5.2 Application of Obfuscation to Memory :::::::::::: 63 3.6 Summary :::::::::::::::::::::::::::::::: 65 4 Obfuscation based Protection against Hardware Trojan :::::::::: 67 4.1 Introduction ::::::::::::::::::::::::::::::: 67 4.2 Background ::::::::::::::::::::::::::::::: 69 4.2.1 Hardware Trojan: Models and Examples ::::::::::: 69 4.2.2 Obfuscation for Hardware IP Protection ::::::::::: 72 4.3 Methodology :::::::::::::::::::::::::::::: 74 4.3.1 Effect of obfuscation on Trojan Insertion ::::::::::: 76 v Page 4.3.2 Effect of obfuscation on Trojan potency :::::::::::: 77 4.3.3 Effect of obfuscation on Trojan detectability ::::::::: 78 4.3.4 Effect of obfuscation on circuit structure ::::::::::: 81 4.3.5 Determination of unreachable states :::::::::::::: 82 4.3.6 Test generation for Trojan detection ::::::::::::: 82 4.3.7 Determination of effectiveness ::::::::::::::::: 83 4.4 Integrated Framework for Obfuscation :::::::::::::::: 84 4.5 Results :::::::::::::::::::::::::::::::::: 86 4.6 Discussions ::::::::::::::::::::::::::::::: 91 4.6.1 Protection against malicious CAD tools :::::::::::: 91 4.6.2 Improving protection and design overhead :::::::::: 93 4.6.3 Application to other Trojan models :::::::::::::: 94 4.7 Summary :::::::::::::::::::::::::::::::: 97 5 A Statistical Approach for Hardware Trojan Detection :::::::::: 98 5.1 Introduction ::::::::::::::::::::::::::::::: 98 5.2 Statistical Approach for Trojan Detection :::::::::::::: 99 5.2.1 Mathematical Analysis ::::::::::::::::::::: 100 5.2.2 Test Generation ::::::::::::::::::::::::: 103 5.2.3 Coverage Estimation :::::::::::::::::::::: 103 5.2.4 Choice of Trojan Sample Size ::::::::::::::::: 104 5.2.5 Choice of N::::::::::::::::::::::::::: 105 5.2.6 Improving Trojan Detection Coverage ::::::::::::: 105 5.3 Results :::::::::::::::::::::::::::::::::: 107 5.3.1 Simulation setup :::::::::::::::::::::::: 107 5.3.2 Comparison with Random and ATPG Patterns ::::::: 108 5.3.3 Effect of Number of Trigger Points (q) :::::::::::: 110 5.3.4 Effect of Trigger Threshold (θ) ::::::::::::::::: 111 5.3.5 Sequential Trojan Detection :::::::::::::::::: 111 vi Page 5.3.6 Application to Side-channel Analysis ::::::::::::: 113 5.4 Summary :::::::::::::::::::::::::::::::: 113 6 A Key-based Secure Scan Design Approach ::::::::::::::::: 115 6.1 Introduction ::::::::::::::::::::::::::::::: 115 6.2 Previous Work ::::::::::::::::::::::::::::: 117 6.3 Proposed Methodology ::::::::::::::::::::::::: 119 6.3.1 Probability of Breaking the Key :::::::::::::::: 121 6.3.2 Overhead Analysis ::::::::::::::::::::::: 122 6.3.3 Functionality :::::::::::::::::::::::::: 122 6.3.4 Testing the Proposed Scheme ::::::::::::::::: 123 6.4 Results :::::::::::::::::::::::::::::::::: 124 6.5 Improvement of Robustness against Attacks ::::::::::::: 127 6.6 Summary :::::::::::::::::::::::::::::::: 129 7 Embedded Software Security through Key-based Obfuscation ::::::: 131 7.1 Introduction ::::::::::::::::::::::::::::::: 131 7.2 Previous Work ::::::::::::::::::::::::::::: 133 7.3 Methodology :::::::::::::::::::::::::::::: 135 7.3.1 Obfuscation Technique ::::::::::::::::::::: 135 7.3.2 Obfuscation Example :::::::::::::::::::::: 141 7.3.3 Obfuscation Efficiency ::::::::::::::::::::: 144 7.3.4 Computational Overhead of the Obfuscation Technique ::: 147 7.3.5 Automation of the Obfuscation Technique :::::::::: 148 7.4 Results :::::::::::::::::::::::::::::::::: 151 7.4.1 Setup :::::::::::::::::::::::::::::: 151 7.4.2 Effect of Variation of the Modification Radius (rmod) :::: 151 7.4.3 Obfuscation Results :::::::::::::::::::::: 151 7.4.4 Overhead Results :::::::::::::::::::::::: 152 7.5 Discussions ::::::::::::::::::::::::::::::: 153 vii Page 7.5.1 Authentication Capabilities :::::::::::::::::: 153 7.5.2 Application to Obfuscation of Program Binaries ::::::: 154 7.5.3 Application of Software Protection in Protection against Mali- cious Modifications ::::::::::::::::::::::: 155 7.5.4 Intelligent Attack Scenarios :::::::::::::::::: 155 7.5.5 Automatic Generation of Modification Code ::::::::: 156 7.6 Summary :::::::::::::::::::::::::::::::: 156 8 Conclusion ::::::::::::::::::::::::::::::::::: 158 REFERENCES :::::::::::::::::::::::::::::::::: 160 viii LIST OF TABLES Table Page 2.1 Average Number of Failing Patterns for ISCAS-89 Benchmark Circuits for Different Modification Schemes :::::::::::::::::::::: 27 2.2 Number of Failing Patterns for ISCAS-89 Benchmark Circuits ::::: 28 2.3 Design Overheads (%) for Different Area Constraints :::::::::: 30 2.4 Obfuscation Efficiency and Design Overheads (%) for the AES modules (for 5% area constraint) :::::::::::::::::::::::::: 32 2.5 Overall Design Overheads (%) for the AES core ::::::::::::: 34 2.6 Design Overheads (%) at iso-delay for ISCAS-89 Circuits with an Embed- ded FSM Utilizing Unreachable States :::::::::::::::::: 35 3.1 Comparison of De-compilation based and CDFG based Approaches :: 47 3.2 Functional and Semantic Obfuscation Efficiency and Overheads for IP Cores for 10% area overhead target (CDFG Modification based Results at iso-delay) :::::::::::::::::::::::::::::::::: 57 3.3 Overall Design Overheads for Obfuscated IP Cores (STG modification based results at iso-delay) ::::::::::::::::::::::::: 58 3.4 Area Overhead for Multi-length Key Support :::::::::::::: 60 3.5 Comparison of Throughput Scalability with Increasing Key Length :: 61 3.6 Design Overhead for ISCAS-89 Benchmarks Utilizing Unused States :: 62 3.7 Design Overhead for IP Cores Utilizing Unused States ::::::::: 63 4.1 Effect of Obfuscation on Security Against Trojans (100,000 random pat- terns, 20,000 Trojan instances, q = 2, k = 4, θ = 0:2) :::::::::: 88 4.2 Effect of Obfuscation on Security Against Trojans (100,000 random pat- terns, 20,000 Trojan instances, q = 4. k = 4, θ = 0:2) :::::::::: 88 4.3 Design Overhead (at iso-delay) and Run-timey for the Proposed Algorithm 91 5.1 Comparison of Trigger and Trojan coverage among ATPG patterns [68], Random (100K, input weights: 0.5), and MERO patterns for q = 2 and q = 4, N = 1000, θ = 0:2 :::::::::::::::::::::::::: 108 ix Table Page 5.2 Reduction in test length with MERO approach compared to 100K random patterns along
Load more

Recommended publications
  • Bypassing Web Application Firewalls
    Bypassing Web Application Firewalls Pavol Lupták [email protected] CEO, Nethemba s.r.o Abstract The goal of the presentation is to describe typical obfuscation attacks that allow an attacker to bypass standard security measures such as various input filters, output encoding mechanisms used in web-based intrusion detection systems (IDS), intrusion prevention systems (IPS) and web application firewalls (WAFs). These attacks may include different networking tricks, polymorphic shellcode and various code techniques. At the beginning we analyse and compare different HTML parsing and interpretation approaches used by most-common browsers that can lead to unique attack vectors. Javascript, with a full range of features, represents another effective way that can be used to obfuscate or de-obfuscate code – some existing obfuscation tools are mentioned. We describe how it is possible to construct “non-alphanumeric Javascript code” which does not contain alphabetic or numeric characters, but still can contain malicious executable code. Despite the fact that most current applications are immune to SQL injection attacks, it is still possible to find many vulnerable applications. We focus on different fuzzy techniques (and useful open source SQL injection tools that implement them) which can still be used to bypass weak input validation controls. We conclude our presentation with a demonstration of the most basic obfuscation techniques that can be successfully used to bypass traditional web application firewalls (WAFs). Finally, we briefly describe current mitigation techniques that are recommended for efficient malicious Javascript code analysis and sanitizing user input containing untrusted code. Keywords: WAF, IPS, IDS, obfuscation, SQL injection, XSS, CSS, CSRF.
    [Show full text]
  • C++11 Metaprogramming Applied to Software Obfuscation
    C++11 METAPROGRAMMING APPLIED TO SOFTWARE OBFUSCATION SEBASTIEN ANDRIVET About me ! Senior Security Engineer at SCRT (Swiss) ! CTO at ADVTOOLS (Swiss) Sebastien ANDRIVET Cyberfeminist & hacktivist Reverse engineer Intel & ARM C++, C, Obj-C, C# developer Trainer (iOS & Android appsec) PROBLEM Reverse engineering • Reverse engineering of an application if often like following the “white rabbit” • i.e. following string literals • Live demo • Reverse engineering of an application using IDA • Well-known MDM (Mobile Device Management) for iOS A SOLUTION OBFUSCATION What is Obfuscation? Obfuscator O O ( ) = YES! It is also Katy Perry! • (almost) same semantics • obfuscated Obfuscation “Deliberate act of creating source or machine code difficult for humans to understand” – WIKIPEDIA, APRIL 2014 C++ templates OBJECT2 • Example: Stack of objects OBJECT1 • Push • Pop Without templates Stack singers; class Stack { singers.push(britney); void push(void* object); void* pop(); }; Stack apples; apples.push(macintosh); • Reuse the same code (binary) singers apples • Only 1 instance of Stack class With C++ templates template<typename T > Stack<Singer> singers; class Stack singers.push(britney); { void push(T object); T pop(); Stack<Apple> apples; }; apples.push(macintosh); With C++ templates Stack<Singer> singers; singers.push(britney); Stack<Singers> Stack<Apples*> Stack<Apple> apples; apples.push(macintosh); singers apples C++ templates • Two instances of Stack class • One per type • Does not reuse code • By default • Permit optimisations based on types • For ex. reuse code for all pointers to objects • Type safety, verified at compile time Type safety • singers.push(apple); // compilation error Optimisation based on types • Generate different code based on types (template parameters) template<typename T> class MyClass • Example: enable_if { ..
    [Show full text]
  • Software Protection Through Obfuscation
    This document is downloaded from DR‑NTU (https://dr.ntu.edu.sg) Nanyang Technological University, Singapore. Software protection through obfuscation Balachandran, Vivek 2014 Balachandran, V. (2015). Software protection through obfuscation. Doctoral thesis, Nanyang Technological University, Singapore. https://hdl.handle.net/10356/62930 https://doi.org/10.32657/10356/62930 Downloaded on 02 Oct 2021 00:34:50 SGT Software Protection through Obfuscation School of Computer Engineering A Thesis Submitted to the Nanyang Technological University in partial fulfillment of the requirement of the degree of Doctor of Philosophy by Vivek Balachandran under the supervision of Prof. Ng Wee Keong and Prof. Sabu Emmanuel 2015 2 Acknowledgments Foremost, I would like to express my sincere gratitude to my advisors Prof. Sabu Em- manuel and Prof. Ng Wee Keong for the continuous support of my Ph.D study and research, for their patience, motivation, enthusiasm, and immense knowledge. I thank my fellow labmates in Nanyang Technological University, Singapore: Shaheen Ansari, Deepak Subrmanyam, Chia Tee Kiah for their kind support. Many friends have helped me stay sane through these difficult years. Their support and care helped me overcome setbacks and stay focused on my graduate study. I would like to thank Aditya Venkataraman, Chitra Panchapakesan, Ganesh Bharadwaj, Girid- haran Karunagaran, Karthik Raveendran, Manaswini Ramkumar, Manisha Mujumdar, Nirnaya Sarangan, Ponnu Jacob, Roshan Wahab, Shubha Nageswaran,Vidhi Patel and Vipin Pillai for making my life wonderful as a grad student. Last but not the least, I would like to thank my family: my parents G. Balachandran and V. Santhakumari, and my brother Vishakh Balachandran who were always there for me.
    [Show full text]
  • 6.858 Final Project
    6.858 Final Project Predrag Gruevski Paul Hemberger Andres Romero Albert Wu Introduction Since remote desktop applications are such powerful tools for controlling computers from across the Internet, it stands to reason that adversaries would be motivated to discover and exploit vulnerabilities in such software. In our final project, we explored many of the most popular remote desktop applications for Android clients. Most of them provide little to no security, and we were able to easily create exploits to compromise the keyboard and mouse of the remote machine. Methods We looked at the following popular Android clients (each has at least 100,000 installs on the Google Play app market): 1. TeamViewer for Remote Control 2. Air HID 3. Remote Mouse 4. WiFi Mouse 5. Android Mouse and Keyboard 6. Mobile Mouse Lite 7. Remote Control Collection We installed each of the above clients on an Android phone and the corresponding server on a remote machine running Windows, OS X, or Linux. We used two types of tools for reverse engineering the messaging protocols: 1. Wireshark ­ Wireshark is a network protocol analyzer. Using Wireshark, we were able to analyze incoming and outgoing packets from the remote machine. This was extremely useful for applications using plaintext protocols. 2. Decompilers ­ Tools like Java Decompiler Project, JetBrains dotPeek, Decompile Android, and dex2jar allowed us to decompile many of the client APK files and server executables into very readable Java code. After reverse engineering the protocols, we set up virtual machines running the above applications and send arbitrary keyboard and mouse commands from the host machine via UDP and TCP.
    [Show full text]
  • Achieving Obfuscation Through Self-Modifying Code: a Theoretical Model
    Running head: OBFUSCATION THROUGH SELF-MODIFYING CODE 1 Achieving Obfuscation Through Self-Modifying Code: A Theoretical Model Heidi Angelina Waddell A Senior Thesis submitted in partial fulfillment of the requirements for graduation in the Honors Program Liberty University Spring 2020 OBFUSCATION THROUGH SELF-MODIFYING CODE 2 Acceptance of Senior Honors Thesis This Senior Honors Thesis is accepted in partial fulfillment of the requirements for graduation from the Honors Program of Liberty University. _____________________________ Melesa Poole, Ph.D. Thesis Chair ______________________________ Robert Tucker, Ph.D. Committee Member ______________________________ James H. Nutter, D.A. Honors Director ______________________________ Date OBFUSCATION THROUGH SELF-MODIFYING CODE 3 Abstract With the extreme amount of data and software available on networks, the protection of online information is one of the most important tasks of this technological age. There is no such thing as safe computing, and it is inevitable that security breaches will occur. Thus, security professionals and practices focus on two areas: security, preventing a breach from occurring, and resiliency, minimizing the damages once a breach has occurred. One of the most important practices for adding resiliency to source code is through obfuscation, a method of re-writing the code to a form that is virtually unreadable. This makes the code incredibly hard to decipher by attackers, protecting intellectual property and reducing the amount of information gained by the malicious actor. Achieving obfuscation through the use of self-modifying code, code that mutates during runtime, is a complicated but impressive undertaking that creates an incredibly robust obfuscating system. While there is a great amount of research that is still ongoing, the preliminary results of this subject suggest that the application of self-modifying code to obfuscation may yield self-maintaining software capable of healing itself following an attack.
    [Show full text]
  • Optimizing Away Javascript Obfuscation
    Optimizing Away JavaScript Obfuscation Adrian Herrera Defence Science and Technology Group [email protected] Abstract—JavaScript is a popular attack vector for releasing • Applying techniques rooted in compiler theory to the task malicious payloads on unsuspecting Internet users. Authors of of deobfuscating JavaScript malware; this malicious JavaScript often employ numerous obfuscation • The design and implementation of SAFE-DEOBS, an techniques in order to prevent the automatic detection by antivirus and hinder manual analysis by professional malware open-source tool to assist malware analysts to better analysts. Consequently, this paper presents SAFE-DEOBS, a understand JavaScript malware; and JavaScript deobfuscation tool that we have built. The aim • An evaluation of SAFE-DEOBS on a large corpus of real- of SAFE-DEOBS is to automatically deobfuscate JavaScript world JavaScript malware. malware such that an analyst can more rapidly determine the malicious script’s intent. This is achieved through a number of Unless otherwise stated, all malicious code used in this static analyses, inspired by techniques from compiler theory. We paper is taken from real-world malware. demonstrate the utility of SAFE-DEOBS through a case study on real-world JavaScript malware, and show that it is a useful II. BACKGROUND AND RELATED WORK addition to a malware analyst’s toolset. Software obfuscation has many legitimate uses: digital Index Terms—javascript, malware, obfuscation, static analysis rights management, software diversity (for software protec- tion), and tamper protection, to name a few. However, software obfuscation is being increasingly co-opted by malware authors I. INTRODUCTION to thwart program analysis (both automated and manual).
    [Show full text]
  • Large-Scale and Language-Oblivious Code Authorship Identification
    Large-Scale and Language-Oblivious Code Authorship Identification Mohammed Abuhamad Inha University, Incheon, South Korea Tamer AbuHmed Inha University, Incheon, South Korea Aziz Mohaisen University of Central Florida, Orlando, USA DaeHun Nyang Inha University, Incheon, South Korea CCS '18: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security Pages 101-114. Toronto, Canada — October 15 - 19, 2018 ISBN: 978-1-4503-5693-0 doi>10.1145/3243734.3243738 link: https://dl.acm.org/citation.cfm?id=3243738 Abstract: Efficient extraction of code authorship attributes is key for successful identification. However, the extraction of such attributes is very challenging, due to various programming language specifics, the limited number of available code samples per author, and the average code lines per file, among others. To this end, this work proposes a Deep Learning-based Code Authorship Identification System (DL-CAIS) for code authorship attribution that facilitates large-scale, language-oblivious, and obfuscation-resilient code authorship identification. The deep learning architecture adopted in this work includes TF-IDF-based deep representation using multiple Recurrent Neural Network (RNN) layers and fully-connected layers dedicated to authorship attribution learning. The deep representation then feeds into a random forest classifier for scalability to de-anonymize the author. Comprehensive experiments are conducted to evaluate DL-CAIS over the entire Google Code Jam (GCJ) dataset across all years (from 2008 to 2016) and over real-world code samples from 1987 public repositories on GitHub. The results of our work show the high accuracy despite requiring a smaller number of files per author. Namely, we achieve an accuracy of 96% when experimenting with 1,600 authors for GCJ, and 94.38% for the real-world dataset for 745 C programmers.
    [Show full text]
  • Automated Malware Analysis Report for Jetbrains-Toolbox
    ID: 85 Sample Name: jetbrains-toolbox Cookbook: defaultmacfilecookbook.jbs Time: 19:01:50 Date: 18/12/2020 Version: 31.0.0 Emerald Table of Contents Table of Contents 2 Analysis Report jetbrains-toolbox 3 Overview 3 General Information 3 Detection 3 Signatures 3 Classification 3 Startup 3 Yara Overview 3 Signature Overview 3 Mitre Att&ck Matrix 4 Behavior Graph 4 Screenshots 4 Thumbnails 4 Antivirus, Machine Learning and Genetic Malware Detection 4 Initial Sample 5 Dropped Files 5 Domains 5 URLs 5 Domains and IPs 5 Contacted Domains 5 Contacted IPs 5 Public 6 General Information 6 Joe Sandbox View / Context 6 IPs 6 Domains 7 ASN 7 JA3 Fingerprints 7 Dropped Files 7 Runtime Messages 7 Created / dropped Files 7 Static File Info 7 General 8 Network Behavior 8 Network Port Distribution 8 TCP Packets 8 UDP Packets 8 System Behavior 8 Analysis Process: mono-sgen32 PID: 570 Parent PID: 493 8 General 8 Analysis Process: jetbrains-toolbox PID: 570 Parent PID: 493 9 General 9 File Activities 9 File Created 9 File Read 9 File Written 9 Directory Enumerated 9 Directory Created 9 Copyright null 2020 Page 2 of 9 Analysis Report jetbrains-toolbox Overview General Information Detection Signatures Classification Sample jetbrains-toolbox Name: RReeaaddss lllaauunncchhsseerrrvviiicceess ppllliiissttt fffiiillleess Analysis ID: 85 Reads launchservices plist files MD5: 4650b54b3ec808… Ransomware SHA1: 2b9318975b9e56… Miner Spreading SHA256: f1a93cf94ae4e62… mmaallliiiccciiioouusss malicious Evader Phishing Most interesting Screenshot: sssuusssppiiiccciiioouusss
    [Show full text]
  • An Obfuscation Resilient Approach for Source Code Plagiarism Detection in Virtual Learning Environments
    X9: An Obfuscation Resilient Approach for Source Code Plagiarism Detection in Virtual Learning Environments Bruno Prado, Kalil Bispo and Raul Andrade Department of Computing, Federal University of Sergipe, Marechal Rondon Avenue, Sao¯ Cristov´ ao,¯ Brazil Keywords: Plagiarism Detection, Computer Programming, E-learning, Source Code Similarity, Re-factoring, Obfusca- tion. Abstract: In computer programming courses programming assignments are almost mandatory, especially in a virtual classroom environment. However, the source code plagiarism is a major issue in evaluation of students, since it prevents a fair assessment of their programming skills. This paper proposes an obfuscation resilient approach based on the static and dynamic source code analysis in order to detect and discourage plagiarized solutions. Rather than focusing on the programming language syntax which is susceptible to lexical and structural re- factoring, an instruction and an execution flow semantic analysis is performed to compare the behavior of source code. Experiments were based on case studies from real graduation projects and automatic obfuscation methods, showing a high accuracy and robustness in plagiarism assessments. 1 INTRODUCTION The use of multiple approaches, greatly reduces the chances of false positive cases, while the false neg- In computer science graduation, practical exercises ative condition still can be properly detected, due to for programming language courses are essential to multiple metrics analyzed. The main contributions of improve the learning process (Kikuchi et al., 2014), proposed approach are: specially through e-teaching platforms, such as Moo- • Currently multiple languages are supported, such dle (Moodle, 2017). Although, the effectiveness of as Assembly, C/C++, Go, Java, Pascal and virtual learning environments consist on ensuring that Python.
    [Show full text]
  • A Taxonomy of Software Obfuscation Techniques for Layered Security Hui Xu1*, Yangfan Zhou2, Jiang Ming3 and Michael Lyu4
    Xu et al. Cybersecurity (2020) 3:9 Cybersecurity https://doi.org/10.1186/s42400-020-00049-3 REVIEW Open Access Layered obfuscation: a taxonomy of software obfuscation techniques for layered security Hui Xu1*, Yangfan Zhou2, Jiang Ming3 and Michael Lyu4 Abstract Software obfuscation has been developed for over 30 years. A problem always confusing the communities is what security strength the technique can achieve. Nowadays, this problem becomes even harder as the software economy becomes more diversified. Inspired by the classic idea of layered security for risk management, we propose layered obfuscation as a promising way to realize reliable software obfuscation. Our concept is based on the fact that real-world software is usually complicated. Merely applying one or several obfuscation approaches in an ad-hoc way cannot achieve good obscurity. Layered obfuscation, on the other hand, aims to mitigate the risks of reverse software engineering by integrating different obfuscation techniques as a whole solution. In the paper, we conduct a systematic review of existing obfuscation techniques based on the idea of layered obfuscation and develop a novel taxonomy of obfuscation techniques. Following our taxonomy hierarchy, the obfuscation strategies under different branches are orthogonal to each other. In this way, it can assist developers in choosing obfuscation techniques and designing layered obfuscation solutions based on their specific requirements. Keywords: Software obfuscation, Layered security, Element-layer obfuscation, Component-layer obfuscation, Inter-component obfuscation, Application-layer obfuscation Introduction ProGuard (ProGuard 2016) and control-flow obfuscation Sofware obfuscation transforms computer programs to with Obfuscator-LLVM (Junod et al. 2015). new versions which are semantically equivalent with the original ones but much harder to understand (Collberg Critical challenge of obfuscation et al.
    [Show full text]
  • 4 Protecting Software Through Obfuscation: Can It Keep Pace with Progress in Code Analysis?
    4 Protecting Software through Obfuscation: Can It Keep Pace with Progress in Code Analysis? SEBASTIAN SCHRITTWIESER, St. Polten¨ University of Applied Sciences, Austria STEFAN KATZENBEISSER, Technische Universitat¨ Darmstadt, Germany JOHANNES KINDER, Royal Holloway, University of London, United Kingdom GEORG MERZDOVNIK, SBA Research, Vienna, Austria EDGAR WEIPPL, SBA Research, Vienna, Austria Software obfuscation has always been a controversially discussed research area. While theoretical results indicate that provably secure obfuscation in general is impossible, its widespread application in malware and commercial software shows that it is nevertheless popular in practice. Still, it remains largely unexplored to what extent today’s software obfuscations keep up with state-of-the-art code analysis, and where we stand in the arms race between software developers and code analysts. The main goal of this survey is to analyze the effectiveness of different classes of software obfuscation against the continuously improving de-obfuscation techniques and off-the-shelf code analysis tools. The answer very much depends on the goals of the analyst and the available resources. On the one hand, many forms of lightweight static analysis have difficulties with even basic obfuscation schemes, which explains the unbroken popularity of obfuscation among malware writers. On the other hand, more expensive analysis techniques, in particular when used interactively by a human analyst, can easily defeat many obfuscations. As a result, software obfuscation for the purpose of intellectual property protection remains highly challenging. Categories and Subject Descriptors: D.2.0 [Software Engineering]: General—Protection mechanisms General Terms: Security Additional Key Words and Phrases: software obfuscation, program analysis, reverse engineering, software protection, malware ACM Reference Format: Sebastian Schrittwieser, Stefan Katzenbeisser, Johannes Kinder, Georg Merzdovnik, and Edgar Weippl, 2015.
    [Show full text]
  • HOP: Hardware Makes Obfuscation Practical∗
    HOP: Hardware makes Obfuscation Practical∗ Kartik Nayak1, Christopher W. Fletcher2, Ling Ren3, Nishanth Chandran4, Satya Lokam4, Elaine Shi5, and Vipul Goyal4 1UMD { [email protected] 2UIUC { [email protected] 3MIT { [email protected] 4Microsoft Research, India { fnichandr, satya, [email protected] 5Cornell University { [email protected] Abstract Program obfuscation is a central primitive in cryptography, and has important real-world applications in protecting software from IP theft. However, well known results from the cryptographic literature have shown that software only virtual black box (VBB) obfuscation of general programs is impossible. In this paper we propose HOP, a system (with matching theoretic analysis) that achieves simulation-secure obfuscation for RAM programs, using secure hardware to circumvent previous impossibility results. To the best of our knowledge, HOP is the first implementation of a provably secure VBB obfuscation scheme in any model under any assumptions. HOP trusts only a hardware single-chip processor. We present a theoretical model for our complete hardware design and prove its security in the UC framework. Our goal is both provable security and practicality. To this end, our theoretic analysis accounts for all optimizations used in our practical design, including the use of a hardware Oblivious RAM (ORAM), hardware scratchpad memories, instruction scheduling techniques and context switching. We then detail a prototype hardware implementation of HOP. The complete design requires 72% of the area of a V7485t Field Programmable Gate Array (FPGA) chip. Evaluated on a variety of benchmarks, HOP achieves an overhead of 8× ∼ 76× relative to an insecure system. Compared to all prior (not implemented) work that strives to achieve obfuscation, HOP improves performance by more than three orders of magnitude.
    [Show full text]