> Side Channel Analysis
Ready-to-use side channel tools to assess cryptography algorithms.
> Laser & EM Fault Injection
Make sure your chip withstands different techniques of physical fault injections.
> Firmware Security Analysis
Qualify embedded code binaries without physical devices and benches.
> Security Failure Analysis
Photoemission analysis to explore internal information in a chip.
> Vulnerability Research
Dynamic analyses at a system level for investigating potential vulnerabilities.
> Data Science Platform
esDynamic is a complete data focused platform to leverage the know-how of your team for complex analyses.
> esFirmware Engine
Assess the security of the firmware of IoT devices against logical and physical attacks.
> esReven Engine
Record and replay vulnerability researches within reverse engineering processes and tools.
> Cybersecurity Training
Grow your expertise with training modules driven by a coach.
> Hardware Evaluation Lab
High-end laboratory capabilities specialized in hardware security evaluations.
> Mobile App Security
Know the threats and risks of your Mobile App.
Integrate the security protections verification in your CI/CD pipeline.
> Mobile App Security Testing (MAST)
esChecker SaaS: automating the security testing of your mobile app binary.
> Mobile App Penetration Testing
Testing the resiliency of your Mobile App, SDK or RASP tool.
> Backend Penetration Testing
Testing the resiliency of your Web App, API or Backend Systems.
> Coaching for Mobile App Developers
Providing insights into the mobile app threats and how attackers work by a learning-by-doing approach.
If you read this blog post, this certainly means there is no need to convince you about the importance of securing your mobile application against hacking. And to make a proper job, you certainly embrace a multi-layer approach.
First, by designing and coding with the aim to handle well the sensitive data and operations. This is what OWASP specified in the MASVS by two levels: L1 (Standard Security) and L2 (Defense-in-depth).
Second, by hardening the code against attacking tools, mixing code obfuscation and anti-tampering measures to make reverse-engineering harder to achieve. OWASP’s MASVS have captured this in the R, Resiliency, layer.
We wrote a blog post about this: How can OWASP help you define your mobile app security policy?
Now comes this critical question: how do you validate these software protections? They are implemented to withstand attacks. This means that you need to create the conditions of attacks to observe if they are effective.
Easy to say, but how difficult in practice?
You don’t have necessarily the knowledge and skills internally to do this. And the human external resource is tedious and incompatible with regular and systematic verifications.
There is one option though: specialised automated testing tools. There are quite a few. They are not necessarily appropriate to address the critical point of security protection validation. We believe that a testing process should mandatorily have the application actually executed.
In other words: make sure the application is running when testing different attack scenarios and observe if the behaviour is as expected.
In “Gartner” language, this could be seen as a Dynamic test. And the tool feature would be named a DAST (Dynamic Application Security Testing). Okay ... but this wording mainly comes from AST (Application Security Testing), and the application to mobile apps does not necessarily work.
Many DAST tools do not make the proper testing of the application binary running and being tested. Maybe because it is difficult to implement.
Regardless of the toolmaker and the terminology, you will need to do one thing: make sure you know precisely which problem you want to solve: which assurance do you want on your mobile application. Once done, selecting the right tool should easily flow...
To protect your application, you have to understand how it behaves when:
As a result, a dynamic test is a test happening at runtime. We need:
If your application is correctly protected, it should NOT allow the use of emulators. As a result, all your dynamic tests run on an emulator will be biased.
Using an emulator would generate a lot of false-positive tests as the app would crash immediately, even though you're testing your root detection or your code injection protection.
Let’s imagine one needs to test the protections against hooking techniques to inject some code.
On an emulator, if you’re protected against the emulation, all your tests would trigger the protection, making you confident about your protection level.
On a real device, you would test your protections layer by layer, passing through the emulation detection, the root detection, and the hook detection.
Long story short, running Dynamic Testing for the same application on an emulator or on a real device would end up in completely different results.
Don’t. Do. That.
Allowing your app to run on an emulated device is highly risky as it allows attackers to better handle the runtime environment, which makes reverse-engineering easier.
In your strategy to slow the work of attackers down, blocking emulators to run your app is essential.
🚨 Disclaimer: to run your own dynamic tests on real devices, you need to be able to develop a custom ROM and manage the dynamic attacks yourselves. This part requires strong expertise. Believe me 🙂
It’s neither that complex nor that expansive to get your own devices to run dynamic attacks. If you can’t afford to buy some devices and pay them upfront, you can think of renting your fleet
An even more efficient way to run dynamic tests is to automate them with MAST tools (Mobile Application Security Testing). At eShard, we released esChecker to automate hundreds of tests on behalf of our clients.
It’s an easy way for them to test their Android and iOS mobile apps every time a new app build is ready against top-market and cutting-edge static and dynamic tests.
Integrating the security verifications within your SDLC (Software Development Lifecycle) is the best way to make sure that every app update doesn’t push any protection regression in production. We highly recommend automating these tests within your CI/CD pipeline (using built-in plugins or APIs).
In a nutshell, here’s what you need to remember:
From our experience, it’s really hard to internalise this skill set. This is why we’ve built esChecker.
Do you want to see how it can help you automate your security testing? Give it a try for your iOS or Android applications.