Web and Hybrid applications

Why not Native apps?

Native Apps are not that good (or not always that good).

• Have low Code Reusability,

• Require more development and maintenance,

• Requires designers and developers' experts on multiple architectures,

• Have low upgrade flexibility.

Once it was the traditional way of developing applications.

• Currently being surpassed by web and hybrid applications.

From a RE perspective, the toolset and languages are very different.

• More complex to analyze.

• Better commonly available obfuscators.

Web apps

Use standard web technologies (HTML, CSS, Javascript).

Especially since HTML5 allowed:

• Advanced UI components.

• Access to media types and sources.

• Access to geolocation.

• Access to local storage.

Look like a standard application (present an Icon).

Completely different stack.

• Standalone Mobile Web Browser.

Hybrid apps

Combine both worlds: Native and Web.

• A thin Java application with a Web application.

Most commonly:

• Web for the interface.

• Java for the application backend.

• Custom Interface connecting both levels.

Installable from the store and indistinguishable from native apps.

• As devices are more powerful, these are becoming very common.

RE Perspective

Most frameworks use JS, but sometimes with custom VMs.

Packaging consists of adding the application JS code, HTML, styles and remaining resources.

• May use a bundle, including all resources.

• May leave resources bare in the APK.

• May use binary libs with obfuscated code, but frequently they are just plugins for native functions.

Code is frequently obfuscated.

• Inheritance of the JS obfuscators is available.

Code may be compiled to an intermediate representation.

• Decompilers are not as robust as the ones for Java.

IONIC

Runs on the Apache Cordova infrastructure.

• Framework implemented in Java.

• Application presented through a Web View.

The actual application is a webpage in the assets/www directory.

• Cordova Plugins in www/plugins.

  • Implemented in JS, communicating with the main framework through interface.

The framework is event-driver with actions activated on interactions.

Every file contains a single line.

• Minified code.

• Pushing logic, or a handler.

Index.html as the entry point.

Workflow:

• Beautify code and extract information.

• Launching Cordova on local PC.

• Inspection through browser.

• Dynamic Analysis.

Flutter

UI from Google based on the Dart Language.

• Compiled under the scope of the Dart VM.

• Designed as a dual-purpose framework: Web and Mobile.

• With Native and Web components.

  • In mobile devices, Flutter is compiled to a native object (libapp.so).

Two deployment flavours.

• AOT: Ahead of Time – the most frequent – as a bytecode for the Dart VM.

• JIT: Just in Time – for debug builds, interpreted from Source Code.

Project structure:

• Small Java shim to load the actual code.

• Framework in libfutter.so.

• Application in another .so libapp.so (yes, an ELF!).

  • It contains a snapshot of the VM to be loaded.

From a RE perspective

• Flutter compiles Dart to native assembly in a single bundle.

  • Internal formats are not publicly known in detail.

• By default, there is no obfuscation or encryption.

  • However, the formats are not known.

• Flutter applications are difficult to reverse engineer.

  • Good for intellectual property.

Flutter-Weather

Simple application showing weather info.

Follows typical structure.

• 2 .so: Framework and App for multiple arches.

Current tools extract classes from VM snapshots, but there is little similarity with the original code.