Microsoft Has Embraced GitHub. Can GitHub Embrace Obfuscation?

In its recent GitHub $7.5B acquisition announcement, Microsoft promised to “bring its developer tools and services to new audiences.” “New audiences” in this context mean, quite literally, GitHub’s 28 million developer users. As the “largest open source community in the world,” GitHub audiences will most surely also mean new requirements, new priorities, and new expectations – but these will also come with old biases. And there is no better example of open source bias than code obfuscation.

For the typical open source developer, obfuscation is “like a pearl onion on a banana split” – it simply does not belong (with thanks and apologies to Philip Marlowe in Raymond Chandler’s The Long Goodbye).

The argument is simple enough – there is no reason to prevent the reverse engineering of open source applications because the source code is already public. It’s like picking an unlocked door.

In addition to the sheer lunacy of the act, the benefits of open source development (access to existing code and limitless engineering resources) far outweigh any advantage that might come from jealously hiding your own handiwork from the rest of the world.

The argument is compelling – if you only concern yourself with intellectual property (IP) issues and ignore user privacy and safety.

Privacy and security obligations trump IP policy and must drive DevOps practices

There is no praise or reward for unsafe software – no matter how efficiently or innovatively developed.

Runtime application self-protection (RASP), as defined by Gartner, is a security technology that is built or linked into an application or application runtime environment, and is capable of controlling application execution and detecting and preventing real-time attacks.

Examples of RASP attack “prevention and detection” include Android root detection, application tamper detection, and unauthorized debugger/emulator detection. These scenarios share the following important qualities:

• Advanced techniques are required to evaluate and ultimately detect these runtime incidents,
• Bad actors are actively upgrading their attack patterns to evade detection,
• Evaluation and detection “techniques” must continuously evolve to stay ahead of evolving exploit patterns.

Increasing the time required for bad actors to dissect – and ultimately evade – RASP prevention and detection algorithms reduces the cost and complexity of effective RASP controls.

Reducing the requirement for all developers to keep up with these development patterns further reduces the cost of security and streamlines a development organization’s ability to respond quickly.

Including multiple RASP checks throughout an application with multiple detection and response layers can dramatically improve overall RASP effectiveness and extend the lifespan of RASP controls.

Privacy and safety controls typically also require audit records to demonstrate compliance. Unless carefully designed, privacy and safety compliance steps can also increase cost and reduce overall efficiency.

PreEmptive Solutions pioneered RASP before it had a name – in 2006, Dotfuscator first included Tamper detection and defense. Anti-debug, (Android) root detection, emulator detection, etc. have all followed.

What we have validated over the past 12+ years is that post-compile injection of RASP controls helps to meet each of these requirements.

• Ensure advanced detection and evaluation algorithms
• Minimizing development training and expertise to implement
• Ensure controls can be distributed throughout systems without impeding core development schedules
• Generating audit logs and other compliance evidence to meet regulatory and statutory obligations

…and what’s this got to do with obfuscation?

As mentioned above – slowing discovery (and impeding evasion) of RASP controls improves privacy and safety – while simultaneously lowering the cost and complexity of implementing those controls. The PCI Council recommends obfuscation to better secure rooted device detection, Google recommends obfuscation to impede hacks on SafetyNet, and the list goes on-and-on. Obscuring RASP controls via obfuscation is a recommended (and increasingly required) practice.

Post-compile injection lets you develop in open source – while injecting (and optionally obfuscating) your RASP controls post compile.

Is there a role for obfuscation to play in the open source community?

YES IF,

• If RASP controls are required AND
• Your RASP technology can be wholly injected post-compile (no logic or APIs are included in the app source code itself)

It’s the inverse of the IP scenario above. Putting your RASP control source inside your project for hackers to see would be “sheer lunacy” as the benefits of injection (improved safety and privacy for users and lower cost and complexity of security derived from injection) far outweigh any advantage that might come from dogmatically publishing source that actually has nothing to do with the application you’re building.

Like most everyone – we at PreEmptive are energized by Microsoft’s acquisition of GitHub – and we look forward to helping new audiences effectively and efficiently protect their apps and the data they process.