Towards a Toolchain for Exploiting Smart Contracts on the Ethereum Blockchain

Total Page:16

File Type:pdf, Size:1020Kb

Towards a Toolchain for Exploiting Smart Contracts on the Ethereum Blockchain Towards a Toolchain for Exploiting Smart Contracts on the Ethereum Blockchain by Sebastian Kindler M.A., University of Bayreuth, 2011 Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of Bachelor of Science in the Computer Science Program Faculty of Computer Science Supervisor: Prof. Dr. Stefan Traub Second Assessor: Prof. Dr. Markus Schäffter External Assessor: Dr. Henning Kopp Ulm University of Applied Sciences March 22, 2019 Abstract The present work introduces the reader to the Ethereum blockchain. First, on a con- ceptual level, explaining general blockchain concepts, and viewing the Ethereum blockchain in particular from different perspectives. Second, on a practical level, the main components that make up the Ethereum blockchain are explained in detail. In preparation for the objective of the present work, which is the analysis of EVM bytecode from an attacker’s perspective, smart contracts are introduced. Both, on the level of EVM bytecode and Solidity source code. In addition, critical assem- bly instructions relevant to the exploitation of smart contracts are explained in detail. Equipped with a definition of what constitutes a vulnerable contract, further practical and theoretical aspects are discussed: The present work introduces re- quirements for a possible smart contract analysis toolchain. The requirements are viewed individually, and theoretical focus is put on automated bytecode analysis and symbolic execution as this is the underlying technique of automated smart contract analysis tools. The importance of semantics is highlighted with respect to designing automated tools for smart contract exploitation. At the end, a min- imal toolchain is presented, which allows beginners to efficiently analyze smart contracts and develop exploits. i Contents Introduction1 1 Preliminaries3 1.1 Blockchain.............................3 1.2 Ethereum.............................. 10 1.2.1 Ethereum from Different Perspectives........... 10 1.2.2 Ethereum World State σ .................. 13 1.2.3 Ethereum Account Types.................. 15 1.2.4 Ethereum Transactions................... 16 1.2.5 Ethereum Virtual Machine (EVM)............. 23 1.2.6 Ethereum Peer-to-Peer Network.............. 26 1.3 Smart Contracts........................... 28 1.3.1 Smart Contracts at EVM Bytecode Level......... 29 1.3.2 Solidity and the Structure of Smart Contracts....... 35 1.4 Vulnerability of Smart Contracts.................. 43 1.4.1 Critical Bytecode Instructions in Smart Contracts..... 43 1.4.2 Exploitation of Critical Instructions............ 46 1.4.3 Defining Vulnerable Smart Contracts and Exploits.... 49 ii 2 Towards a Smart Contract Exploit Development Toolchain 50 2.1 Requirements Analysis....................... 50 2.2 Requirement 1: EVM Bytecode Deployment............ 53 2.3 Requirement 2: Manual EVM Bytecode Analysis (Tools)..... 55 2.4 Requirement 3: Automated Analysis (Theory)........... 57 2.4.1 Symbolic Execution.................... 57 2.5 Requirement 4: Automated Exploit Development......... 70 2.6 Toolchain for Automated EVM Bytecode Analysis and Exploit Development............................ 73 Conclusions 74 iii Introduction The concept of smart contracts was introduced in 1994 by cryptographer Nick Szabo [46], who offers the following definition: A smart contract is a computerized transaction protocol that executes the terms of a contract. The general objectives of smart contract design are to satisfy common contractual conditions (such as payment terms, liens, confidentiality, and even enforcement), minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries. Related economic goals include lowering fraud loss, arbitration and enforcement costs, and other transaction costs1. A smart contract is as binding as a legal contract. The bytecode of a smart contract constitutes the contractual conditions, to which users subject themselves when they execute the respective smart contract. However, unlike a legal contract, a smart contract can neither be circumvented nor fought in court. As programs, and from the perspective of the end user, smart contracts execute precisely the way they are designed. In this sense, Ethereum blockchain technology is an implementation of a decentralized crypto-law system [51]. In contrast to national legal systems, Ethereum non-contract account owners do not decide by which law they want to abide, but rather by which law they want to be bound. Once called via a message call transaction, smart contract execution cannot be stopped, and the contractual conditions are binding in the absolute sense. However, if program code is what constitutes the law, then programming errors are part of the law as well. Hence, by definition, the abuse of programming errors in a 1The term transaction costs goes back to the article The problem of Social Cost by Ronald Coase [10], the theses of which were later summarized as the Coase theorem [12]. Transaction costs have a negative connotation and refer to the time and effort as well as the resources that are required to negotiate the exchange of legal entitlements. According to the interpretation [12] of Coase’s proposal, from the perspective of efficiency, the original allocation of resources is of no concern as long as transactions of legal entitlements are costless. Reducing transaction costs facilitates the efficient exchange of legal entitlements and increases cooperation between competing parties. 1 decentralized system such as Ethereum cannot constitute a violation of the system’s crypto-law. Any condemnation of attacks against error-prone smart contracts builds on the remnants of thinking in centralized legal systems. A decentralized system thus eradicates such thinking. Public blockchain implementations such as Ethereum are transparent but trustless environments. However, the trust people put in Ethereum does not depend on centralized legal institutions. Rather, people put their trust in algorithms [35] the security of blockchain technology is build on. Regarding the consensus algorithm, i.e., the proof-of-work, such trust may be justified. However, complete trust in the correct execution of arbitrary programs seems ill-placed. Especially, when these programs manage ’real’ people’s money: Ethereum smart contracts own Ether worth millions of US dollar, and heists [33] on the Ethereum blockchain have shown how vulnerable and insecure smart contracts can be. To comprehend the severity of smart contract vulnerabilities as well as the importance of a toolchain for smart contract vulnerability analysis, the subsequent work serves as a thorough introduction to the Ethereum blockchain. The present work introduces the reader to the Ethereum blockchain. First, on a conceptual level, explaining general blockchain concepts, and viewing the Ethereum blockchain in particular from different perspectives. Second, on a practical level, the main components that make up the Ethereum blockchain are explained in detail. In preparation for the objective of the present work, which is the analysis of EVM bytecode from an attacker’s perspective, smart contracts are introduced. Both, on the level of EVM bytecode and Solidity source code. In addition, critical assembly instructions relevant to the exploitation of smart contracts are explained in detail. Equipped with a definition of what constitutes a vulnerable contract, further practical and theoretical aspects are discussed: The present work introduces requirements for a possible smart contract analysis toolchain. The requirements are viewed individually, and theoretical focus is put on automated bytecode analysis and symbolic execution as this is the underlying technique of automated smart contract analysis tools. The importance of semantics is highlighted with respect to designing automated tools for smart contract exploitation. At the end, a minimal toolchain is presented, which allows beginners to efficiently analyze smart contracts and develop exploits. 2 1 Preliminaries 1.1 Blockchain Blockchain as an append-only linked list The term blockchain refers to a data structure, which can be loosely described as an append-only linked list, whose data content and sequence of data elements are immutable. In comparison, a standard singly linked list is a linear sequence of individual data elements, each of which contains some data and a reference to the next element. Thus, the elements themselves implement the list by referencing the address of the respective next element as shown in Figure1. Each of the elements in the singly linked list can be modified, moved within the sequence or be deleted. Moreover, new elements can be inserted at any point in the sequence: at the beginning, the middle or the end. Thus, a singly linked list is neither append-only nor is it immutable with regards to data content and sequence of data elements. address : 0x0004 address : 0x000A address : 0x0032 data 12 data 35 data 17 next 0x000A next 0x0032 next Null F irst element Second element Last element Figure 1: A singly linked list consisting of three elements, each of which stores an integer value and references the next element by pointing to its address. In contrast, a blockchain is designed as an append-only linked list: the linear sequence of previously added data elements is immutable, so is the data stored in the data elements. The data elements on a blockchain are referred to as blocks. Each block is comprised of two sections: (1) a block header that contains various pieces of information particular
Recommended publications
  • 1 SEC Consult – Cyber Security Challenge Austria / CTF Tips & Tricks
    SEC Consult – Austria Cyber Security Challenge Tips & Tricks Responsible: R. Freingruber Version/Date: 1.0 / 26.04.2018 Confidentiality class: Public 1 SEC Consult – Cyber Security Challenge Austria / CTF Tips & Tricks This article is intended to give useful tips and tricks for participants of the Cyber Security Challenge Austria, however in general, it can be seen as a guideline to Capture-the-Flag (CTF) competitions. The first chapter is for beginners who don’t know where they can acquire the required skills to participate and how to get started. The later chapters give some hints for various categories in CTFs. Please note that the tips range from basic tips to more complex ones like “how to solve hard binaries” or “how to win attack-defense CTFs” (which is very likely not required for Cyber Security Challenge Austria). Please also note that the article has a strong focus on the binary / exploit category because that’s the authors main category. 1.1 How to get started? This chapter is for people who want to do more in the field of IT security, but who don’t know how to get started and where the required knowledge can be learned. The best source of information are books that summarize the most common attack techniques and protections against them. Since the entire topic of IT security is very extensive there is not a “one-size-fits- all” book which lists all attacks in-depth. Instead, there are standard books which cover specific topics. The following list is not exhaustive, but tries to list the best books (in the authors opinion) for the respective topics: • Web o The Web Application Hackers Handbook by Dafydd Stuttard ▪ The standard book on web attacks which covers lots of different topics.
    [Show full text]
  • Reverse Software Engineering As a Project-Based Learning Tool
    Paper ID #33764 Reverse Software Engineering as a Project-Based Learning Tool Ms. Cynthia C. Fry, Baylor University CYNTHIA C. FRY is currently a Senior Lecturer of Computer Science at Baylor University. She worked at NASA’s Marshall Space Flight Center as a Senior Project Engineer, a Crew Training Manager, and the Science Operations Director for STS-46. She was an Engineering Duty Officer in the U.S. Navy (IRR), and worked with the Naval Maritime Intelligence Center as a Scientific/Technical Intelligence Analyst. She was the owner and chief systems engineer for Systems Engineering Services (SES), a computer systems design, development, and consultation firm. She joined the faculty of the School of Engineering and Computer Science at Baylor University in 1997, where she teaches a variety of engineering and computer science classes, she is the Faculty Advisor for the Women in Computer Science (WiCS), the Director of the Computer Science Fellows program, and is a KEEN Fellow. She has authored and co- authored over fifty peer-reviewed papers. Mr. Zachary Michael Steudel Zachary Steudel is a 2021 graduate of Baylor University’s computer science department. In his time at Baylor, he worked as a Teaching Assistant under Ms. Cynthia C. Fry. As part of the Teaching Assistant role, Zachary designed and created the group project for the Computer Systems course. Zachary Steudel worked as a Software Developer Intern at Amazon in the Summer of 2019, a Software Engineer Intern at Microsoft in the Summer of 2020, and begins his full-time career with Amazon in the summer of 2021 as a software engineer.
    [Show full text]
  • Improving Mobile-Malware Investigations with Static and Dynamic Code Analysis Techniques
    IMPROVING MOBILE-MALWARE INVESTIGATIONS WITH STATIC AND DYNAMIC CODE ANALYSIS TECHNIQUES Vom Fachbereich Informatik (FB 20) der Technischen Universität Darmstadt zur Erlangung des akademischen Grades eines Doktor-Ingenieurs (Dr.-Ing.) genehmigte Dissertation von Siegfried Rasthofer, M.Sc. geboren in Landshut, Deutschland. Referenten: Prof. Dr. Eric Bodden (Referent) Prof. Dr. Andreas Zeller (Korreferent) Prof. Dr. Mira Mezini (Korreferentin) Tag der Einreichung: 7. November 2016 Tag der Disputation: 22. Dezember 2016 Darmstadt 2017 Hochschulkennziffer: D17 Siegfried Rasthofer: Improving Mobile-Malware Investigations with Static and Dynamic Code Analysis Techniques © January 2017 phd referees: Prof. Dr. Eric Bodden Prof. Dr. Andreas Zeller Prof. Dr. Mira Mezini further phd committee members: Prof. Dr. Reiner Hähnle Prof. Dr. Christian Bischof Prof. Dr. Patrick Eugster Darmstadt, Germany January 2017 ABSTRACT Similar to the PC world, the abundance of mobile malware has become a serious threat to smartphone users. Thousands of new apps or app versions are uploaded to popular app stores every day. All of them need to be analyzed against violations of the app store’s content policy. In particular, one wishes to detect whether an application contains malicious behavior. Similarly, antivirus companies check thousands of apps every day to determine whether or not they are malicious. Both app store operators and antivirus vendors face the same problem: it is generally challenging to tell apart malware from benign applications. This is because malware developers aim to hide their applications’ malicious behavior as long as possible from being detected by applying different obfuscation techniques. The raising sophistication with which such measures are implemented pose a serious problem not just to automated malware detection approaches but also to the manual analysis of potential malware by human experts.
    [Show full text]
  • Flexible Software Protection
    Flexible Software Protection JENS VAN DEN BROECK, BART COPPENS, and BJORN DE SUTTER, Department of Electronics and Information Systems, Ghent University, Belgium To counter software reverse engineering or tampering, software obfuscation tools can be used. However, such tools to a large degree hard-code how the obfuscations are deployed. They hence lack resilience and stealth in the face of many attacks. To counter this problem, we propose the novel concept of flexible obfuscators, which implement protections in terms of data structures andAPIs already present in the application to be protected. The protections are hence tailored to the application in which they are deployed, making them less learnable and less distinguishable. In our research, we concretized the flexible protection concept for opaque predicates. We designed an interface to enable the reuse of existing data structures and APIs in injected opaque predicates, we analyzed their resilience and stealth, we implemented a proof-of-concept flexible obfuscator, and we evaluated it on a number of real-world use cases. This paper presents an in-depth motivation for our work, the design of the interface, an in-depth security analysis, and a feasibility report based on our experimental evaluation. The findings are that flexible opaque predicates indeed provide strong resilience and improved stealth, but also that their deployment is costly, and that they should hence be used sparsely to protect only the most security-sensitive code fragments that do not dominate performance. Flexible obfuscation therefor delivers an expensive but also more durable new weapon in the ever ongoing software protection arms race. CCS Concepts: • Security and privacy ! Software security engineering; Software reverse engineering.
    [Show full text]
  • A Novel Two-Factor Honeytoken Authentication Mechanism
    A novel Two-Factor HoneyToken Authentication Mechanism Vassilis Papaspirou Leandros Maglaras Mohamed Amine Ferrag Department of Computer Science Cyber Technology Institute Department of Computer Science University of Thessaly De Montfort University University of Guelma Volos, Greece Leicester, UK Guelma, Algeria [email protected] [email protected] [email protected] Ioanna Kantzavelou Helge Janicke Christos Douligeris Department of Informatics Cyber Security Cooperative Research Centre Department of Informatics University of West of Attica Edith Cowan University University of Piraeus Athens, Greece Australia [email protected] [email protected] [email protected] Abstract—The majority of systems rely on user authentication guessing, etc. Several best practices have been suggested on passwords, but passwords have so many weaknesses and for the use of passwords. Some of them are very difficult widespread use that easily raise significant security concerns, to use and others do not fulfill the security needs of the regardless of their encrypted form. Users hold the same password for different accounts, administrators never check password files organization. To overcome the password problem, two factor for flaws that might lead to a successful cracking, and the lack of authentication using devices such as tokens and ATM cards a tight security policy regarding regular password replacement has been suggested and has been shown to be difficult to hack are a few problems that need to be addressed. The proposed re- [2]. There are several limitations of two-factor authentication, search work aims at enhancing this security mechanism, prevent including the cost of purchasing, issuing, and handling tokens penetrations, password theft, and attempted break-ins towards securing computing systems.
    [Show full text]
  • INFILTRATE Ghidra
    Three Heads Are Better Than One: Mastering NSA's Ghidra Reverse Engineering Tool Alexei Bulazel Jeremy Blackthorne @0xAlexei @0xJeremy github.com/0xAlexei/INFILTRATE2019 Disclaimer This material is based on the publicly released Ghidra, there is no classified information in this presentation Alexei Bulazel @0xAlexei ● Senior Security Researcher at River Loop Security ● Research presentations and publications: ○ Presentations at REcon (MTL & BRX), SummerCon, DEFCON, Black Hat, etc. ○ Academic publications at USENIX WOOT and ROOTS ○ Cyber policy in Lawfare, etc. ● Collaborated with Jeremy on research at RPI, MIT Lincoln Laboratory, and Boston Cybernetics Institute ● Proud RPISEC alumnus Jeremy Blackthorne @0xJeremy ● Instructor at the Boston Cybernetics Institute ● PhD candidate at RPI focused on environmental keying ● Former researcher at MIT Lincoln Laboratory ● United States Marine Corps 2002 - 2006 ● RPISEC alumnus Outline 1. Intro 2. Interactive Exercises a. Manual Static Analysis b. Scripting Ghidra 3. P-Code & SLEIGH 4. Discussion 5. Conclusion Participating 1. Install OpenJDK 11, add its bin directory to your PATH ● jdk.java.net/11 2. Download Ghidra ● ghidra-sre.org ● github.com/NationalSecurityAgency/ghidra/releases 3. Download our demo scripts and binaries ● github.com/0xAlexei/INFILTRATE2019 Ghidra ● Java-based interactive reverse engineering tool developed by US National Security Agency - similar in functionality to IDA Pro, Binary Ninja, etc… ○ Static analysis only currently, debugger support promised to be coming soon ○ Runs on Mac, Linux, and Windows ● All credit for creating Ghidra goes to the developers at NSA ● Released open source at RSA in March 2019 ○ 1.2M+ lines of code ● NSA has not discussed the history of the tool, but comments in source files go as far back as February 1999 Outline 1.
    [Show full text]
  • Arxiv:1611.10231V1 [Cs.CR] 30 Nov 2016 a INTRODUCTION 1
    00 Android Code Protection via Obfuscation Techniques: Past, Present and Future Directions Parvez Faruki, Malaviya National Institute of Technology Jaipur, India Hossein Fereidooni, University of Padua, Italy Vijay Laxmi, Malaviya National Institute of Technology Jaipur, India Mauro Conti, University of Padua, Italy Manoj Gaur, Malaviya National Institute of Technology Jaipur, India Mobile devices have become ubiquitous due to centralization of private user information, contacts, messages and multiple sensors. Google Android, an open-source mobile Operating System (OS), is currently the mar- ket leader. Android popularity has motivated the malware authors to employ set of cyber attacks leveraging code obfuscation techniques. Obfuscation is an action that modifies an application (app) code, preserving the original semantics and functionality to evade anti-malware. Code obfuscation is a contentious issue. Theoretical code analysis techniques indicate that, attaining a verifiable and secure obfuscation is impos- sible. However, obfuscation tools and techniques are popular both among malware developers (to evade anti-malware) and commercial software developers (protect intellectual rights). We conducted a survey to uncover answers to concrete and relevant questions concerning Android code obfuscation and protection techniques. The purpose of this paper is to review code obfuscation and code protection practices, and evalu- ate efficacy of existing code de-obfuscation tools. In particular, we discuss Android code obfuscation methods, custom app protection techniques, and various de-obfuscation methods. Furthermore, we review and ana- lyze the obfuscation techniques used by malware authors to evade analysis efforts. We believe that, there is a need to investigate efficiency of the defense techniques used for code protection. This survey would be beneficial to the researchers and practitioners, to understand obfuscation and de-obfuscation techniques to propose novel solutions on Android.
    [Show full text]
  • Verifying the Integrity of Open Source Android Applications Michael Macnair
    Verifying the Integrity of Open Source Android Applications Michael Macnair Technical Report RHUL–MA–2015–4 4 March 2015 Information Security Group Royal Holloway University of London Egham, Surrey, TW20 0EX United Kingdom www.ma.rhul.ac.uk/tech Michael Macnair Student number: 100761605 Verifying the Integrity of Open Source Android Applications 28th August 2014 Supervisor: Keith Mayes Submitted as part of the requirements for the award of the MSc in Information Security at Royal Holloway, University of London. I declare that this assignment is all my own work and that I have acknowledged all quotations from published or unpublished work of other people. I also declare that I have read the statements on plagiarism in Section 1 of the Regulations Governing Examination and Assessment Offences, and in accordance with these regulations I submit this project report as my own work. Signature: Contents Executive Summary 1 1 Introduction 3 1.1 Android and Android Applications . 3 1.2 Reverse Engineering . 4 1.3 Obfuscation . 4 1.4 Verifying Integrity of Binary Distributions . 5 1.5 Objectives . 5 1.6 Report Structure . 6 2 Use Cases for Reversing and Obfuscation 7 2.1 Use Cases . 7 2.2 Conclusion . 10 3 Reverse Engineering Android Applications 11 3.1 The APK File Format . 11 3.2 Techniques . 12 3.3 Tools . 14 4 Verifying Android Application Integrity 23 4.1 APKDiff . 23 4.2 AppIntegrity . 26 5 Analysis of Applications on the Play Store 35 5.1 RedPhone . 35 5.2 ChatSecure . 37 5.3 Telegram . 38 5.4 TextSecure . 40 5.5 Lil’ Debi: Debian Installer .
    [Show full text]
  • Pypanda: Taming the Pandamonium of Whole System Dynamic Analysis
    PyPANDA: Taming the PANDAmonium of Whole System Dynamic Analysis Luke Craig∗, Andrew Fasano∗y, Tiemoko Ballo∗, Tim Leek∗ Brendan Dolan-Gavittz William Robertsony ∗MIT Lincoln Laboratory {Luke.Craig,Andrew.Fasano,Tleek,Tiemoko.Ballo}@ll.mit.edu yNortheastern University [email protected], [email protected] zNew York University [email protected] Abstract—When working with real world programs, dy- IDA Pro1, and Ghidra2 all support conducting analyses namic analyses often must be run on a whole-system instead of from scripting languages, such functionality is rarely just a single binary. Existing whole-system dynamic analysis present in whole-system dynamic analysis platforms lead- platforms generally require analyses to be written in compiled languages, a suboptimal choice for many iterative analysis ing to cumbersome workflows. For example, consider the tasks. Furthermore, these platforms leave analysts with a split task of conducting a whole-system dynamic taint analysis view between the behavior of the system under analysis and on data sent to a custom kernel module that ultimately the analysis itself—in particular the system being analyzed flow into a user space application. An analyst must must commonly be controlled manually while analysis scripts approach this task through two distinct, but complemen- are run. To improve this process, we designed and imple- mented PyPANDA, a Python interface to the PANDA dynamic tary, processes. First, they must drive the guest system’s analysis platform. PyPANDA unifies the gap between guest behavior: boot the system, log in, obtain the relevant virtual machines behavior and analysis tasks; enables painless source code and toolchains, compile the code (or copy in a integrations with other program analysis tools; and greatly prebuilt binary), and load the kernel module.
    [Show full text]
  • Get the Most from Capture the Flag
    Maximum CTF Get the most from capture the flag Friday, July 31, 2009 capture the flag (Two Toy Soldiers) http://www.flickr.com/photos/janramroth/2264184078/ http://creativecommons.org/licenses/by/2.0/deed.en jot.punkt lightning round "Hack the planet______" Friday, July 31, 2009 Trivia 100 from 2006 qualifier. And yeah this should be insanely obvious. The funny part though is that the next year, the 100 point question was The thunder and lightning RonAlmog http://www.flickr.com/photos/ronalmog/2053473900/ http://creativecommons.org/licenses/by/2.0/deed.en lightning round "Hack the planet______" Friday, July 31, 2009 Trivia 100 from 2006 qualifier. And yeah this should be insanely obvious. The funny part though is that the next year, the 100 point question was The thunder and lightning RonAlmog http://www.flickr.com/photos/ronalmog/2053473900/ http://creativecommons.org/licenses/by/2.0/deed.en lightning round "_____Hack the planet" Friday, July 31, 2009 And likewise, the year after that: lightning round "_____Hack the planet" Friday, July 31, 2009 And likewise, the year after that: lightning round "Hack the___ planet" Friday, July 31, 2009 A fair amount of CTF has been inside jokes and homages to years past. If you plan on participating, check out and practice on previous years answers and writeups as they will make your life much easier. lightning round "Hack the___ planet" Friday, July 31, 2009 A fair amount of CTF has been inside jokes and homages to years past. If you plan on participating, check out and practice on previous years answers and writeups as they will make your life much easier.
    [Show full text]
  • A Reverse Engineering Approach
    Iowa State University Capstones, Theses and Graduate Theses and Dissertations Dissertations 2019 Android ransomware trends and case studies: A reverse engineering approach Chenliang Xu Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/etd Part of the Computer Engineering Commons Recommended Citation Xu, Chenliang, "Android ransomware trends and case studies: A reverse engineering approach" (2019). Graduate Theses and Dissertations. 17810. https://lib.dr.iastate.edu/etd/17810 This Thesis is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Graduate Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Android ransomware trends and case studies: A reverse engineering approach by Chenliang Xu A thesis submitted to the graduate faculty in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Major: Computer Engineering Program of Study Committee: Yong Guan, Major Professor Daji, Qiao Jaeyoun Kim The student author, whose presentation of the scholarship herein was approved by the program of study committee, is solely responsible for the content of this thesis. The Graduate College will ensure this thesis is globally accessible and will not permit alterations after a degree is conferred. Iowa State University Ames, Iowa 2019 Copyright © Chenliang
    [Show full text]
  • Cardpliance: PCI DSS Compliance of Android Applications
    Cardpliance: PCI DSS Compliance of Android Applications Samin Yaseer Mahmud,? Akhil Acharya,? Benjamin Andow,† William Enck,? and Bradley Reaves? ?North Carolina State University †IBM T.J. Watson Research Center Abstract a virtual token that is linked to the actual credit card, and b) Smartphones and their applications have become a predomi- handling both payment information and authorization outside nant way of computing, and it is only natural that they have of the third-party application [3]. However, recent work [8] become an important part of financial transaction technology. reported that 4,433 of a random sample of 50,162 applications However, applications asking users to enter credit card num- from Google Play were asking the user to enter credit card bers have been largely overlooked by prior studies, which information via text fields in the application UI. There are frequently report pervasive security and privacy concerns in many reasons why this may occur. For example, an appli- the general mobile application ecosystem. Such applications cation developer may wish to offer an alternative if the user are particularly security-sensitive, and they are subject to the does not want to use the Google or Apple payment system. Payment Card Industry Data Security Standard (PCI DSS). Alternatively, the application developer may wish to avoid In this paper, we design a tool called Cardpliance, which overhead charges from Google and Apple [37, 38]. Whatever bridges the semantics of the graphical user interface with the reason, the fact remains: applications are asking users to static program analysis to capture relevant requirements from enter credit card information.
    [Show full text]