What will be checked?

In the Liasoft report for security in apps and software, we conduct two core analyzes

Static analysis

In the static analysis many factors are examined for safety deficiencies. This analysis starts with an overview. In other words, your application will be examined for used frameworks and libraries.

Examining the archive and directory structure

Here we determine the first information about your application. We compile a list of binaries, decompile files and third-party libraries to analyze with our databases and identify any frameworks that are used at first glance.
The information obtained here initiates the next step in the analysis.

Collect and prepare managed resources.

A ‘managed’ resource is code that is loaded via a runtime. This can be bytecode or interpretable code. We automatically decompile all code to perform the subsequent analysis. That means in the Konkrekten that we all Java files, .NET assemblies, Javascript files and much more. decompose and deobfuscate. These steps happen automatically. Currently we support more than 50 different frameworks and technologies and there are almost more weekly.

Collect and prepare binaries.

Afterwards we determine all native binaries (C, C ++, Objective-C), ie executables and shared libraries that are integrated in your application.

Analysis

After collecting metadata and analyzable files, an in-depth analysis starts. We have a specific checklist and a workflow we follow up. It should be understood that we do not document the internal workflow here.
Nevertheless, we would like to give a short overview of some points that are searched for:

  • Metadata
  • Import/Export Tables?
  • Segmente that are unusual (Packer).
  • Are there encrypted? How easy is it to decode these?
  • Anti-Debugging checks?
  • Syscalls?
  • RTTI Information in binary?
  • Protobuf (inclunding Metadata) in binary?
  • Script Engine with exported Metadata?
  • Certificates in Binary?
  • Are code pages modified at runtime?
  • Is there a control flow obfuscation?
  • Is there stack spilling?
  • Is a shell opened with user input?
  • Did the target use common crypto libraries?
  • Debug-Informationen?
  • What libraries are used?
  • Binaries/Android only: Are there internal Java APIs accessed?
  • .NET: Is it fully restorable or obfuscated?
  • .NET: Is there a protection against IL patching?

From the point of view of reverse engineering we have a lot of metadata and a large database of knowledge about the internas of your application.
From our experience we can use this information to plan an attack scenario.

Runtime analysis

In runtime analysis, we specifically target your application. In other words, we leverage all security features, such as anti-debugging, SSL certificate pinning, or encryption, and try to attack the application in some way. Of course, that depends very much on the usefulness of your application and is different in each case.

Attack scenarios during runtime analysis

  • Can we extract more metadata at runtime? (Databases, script registrations, etc.)
  • Can we make a MITM attack to access your APIs?
  • Can we even completely implement a supposedly secure connection without much effort?
  • Is your application or backend handling incorrect data correctly?
  • Are data leaks from your backend or even user data possible?
  • Can we create any advantage in any form of attack that a normal user can not achieve?