OWASP Reverse Engineering and Code Modification Prevention Project

=Overview=



{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 * valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

Project Description
This project educates security professionals about the risks of reverse engineering and how to ensure that code cannot be reverse engineered or modified. If you are placing sensitive code in an environment in which an attacker can get physical access to that environment (read: mobile, desktops, cloud, particular geographies), you should be concerned with the risks of reverse engineering or unauthorized code modification. This umbrella project will help you understand the risks and how to mitigate them.

A Brief History of This Problem Space
Historically, organizations offered their customers web applications that exposed an interface to some necessary business services. The services expose high-value functionality that allows an organization to deliver value to its clients. Attackers had a specific set of threats or goals that they realized by exploiting vulnerabilities that the organization exposed through the application’s presentation layer. Security practitioners address these specific sets of vulnerabilities through the web application or the associated infrastructure security disciplines.

Most often, attackers successfully realized their threats by providing malicious input that they fed into the web application’s presentation layer. Classic attack vectors used by attackers that use this technique include: SQL Injection, Cross-Site (XSS) Scripting, and URL parameter tampering vulnerabilities. Often, security professionals detect the presence of these vulnerabilities through source code analysis or penetration testing. In response to the detection, security professionals recommend to the organization that its Software Engineers should mitigate these vulnerabilities by applying secure coding techniques and adding appropriate data validation security controls to the affected application. Generally, this is sage advice and it works well for traditional web-based applications. In this common scenario, this advice is enforceable because the organization is hosting the web application in a highly controlled (more trustworthy) environment where only the organization’s Software Engineers can modify the application’s underlying code.

In present day, consumers have demanded richer user experiences than what organizations could traditionally offer through web applications they exposed online. In response to these demands, organizations began augmenting the user experience with mobile applications. These applications offer genuinely quicker and richer user experiences than what users would otherwise get through traditional browser-based web applications.

In making the switch to mobile applications, organizations are now deploying more of the presentation layer and business layer of the application on a phone instead of on their own servers. As a result, they lose a lot more control over who gets to see or modify their application’s code. Before the switch, most of the application’s presentation and business layer functionality was hidden within the organization’s trusted server environments. Outside users or attackers did not get much of an opportunity to see executing code in action.

With the recent move towards mobile applications, an attacker can now see, touch, and directly modify a lot of the application’s presentation and business layer code within the attacker’s mobile computing environment. This capability allows the attacker to realize the same traditional business threats as before (with web applications) but in genuinely new and unconventional ways.

Licensing
Any documentation or educational material associated with this project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.


 * valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

What does this project deliver?
Prevent an attacker from reverse engineering your code or making unauthorized changes to that code. The following audiences get something from this project:


 * Risk Specialists - Understand the business and technical risks that an attacker will deploy in order to reverse engineer or modify your code in unsafe environments;


 * Security Architects - Understand the architectural features that should be embedded into code to prevent an attacker from reverse engineering or modifying your code;


 * Penetration Testers - Learn how to conduct binary attacks against mobile apps understand threats that can be realized against various different platforms. You'll have a better understanding of useful attack vectors to verify the strength of reverse engineering prevention or unauthorized code modification;


 * Software Engineers - Learn things that you can do to make reverse engineering as painful as possible for someone that is interested in reverse-engineering your code.

Sub-projects
RISK: Technical Risks of Reverse Engineering and Unauthorized Code Modification

This sub-project helps organizations understand the various technical risks that they are exposed to when they host sensitive code in untrustworthy environments. It is useful to stakeholders that must decide how/if to mitigate these risks.

ARCHITECTURE: Architectural Principles That Prevent Code Modification or Reverse Engineering

This sub-project helps security architects and designers understand the features of their application that should be included to prevent reverse engineering or code modification.

Related Projects
This project is associated with
 * OWASP_Mobile_Security_Project
 * OWASP_AppSensor_Project
 * OWASP_iMAS_iOS_Mobile_Application_Security_Project
 * Mobile_Jailbreaking_Cheat_Sheet


 * valign="top" style="padding-left:25px;width:200px;" |

Project Contributors

 * Jonathan Carter (Leader)
 * Kajihara Masao (Project Contributor)
 * Jim DelGrosso (Project Contributor)
 * Chris Stahly (Project Contributor)
 * Rennie Allen (Project Contributor)

Presentations

 * [[Media:OWASP Mobile App Hacking (AppSecUSA 2015) Workshop Content.pdf]]
 * [[Media:Consequences_of_a_Jailbroken_iDevice.pdf]]
 * [[Media:Mobile Risks and Solutions.pdf]]
 * [[Media:OWASP Mobile App Hacking (AppSecUSA 2014) Workshop Content.pdf]]
 * [[Media:OWASP Mobile App Hacking (AppSecUSA 2014) Feedback.pdf]]

News and Events

 * [September 2014] - AppSec USA Workshop 2014 conducted
 * [April 2014] - Architectural Principles content finalized and released
 * [March 2014] - Technical Risks content translated into Japanese
 * [January 2014] - Technical Risks content finalized and released
 * [December 2013] - Establishment of project wiki

Classifications

 * }

=FAQs=


 * Is there anything that an organization can really do to prevent someone from modifying their code if the attacker has physical access to the code?
 * Absolutely. There are a lot of things that Software Engineers can do to prevent an attacker from understanding or modifying their code.


 * Is this really a frequently occurring problem?
 * Yes, this is a huge problem that many different business verticals have had to deal with over time. It's just now starting to hit the web and mobile development communities.

= Road Map and Getting Involved =

=Project About=