Corellium Workshop at ARM DevSummit 2020

Workshops December 2020

In October, Corellium presented an interactive workshop at the ARM DevSummit called “App Unknown: An Introduction to Rapid Security Analysis on ARM.” Spots for the workshop filled up in a matter of hours, so we wanted to share some highlights and resources here for those who weren’t able to attend!

Click here to download the workshop slides.

The workshop was designed to introduce the audience to essential tools and methods for quickly assessing an unknown application for potential security threats. Someone sends you an app you don’t recognize — how can you get an idea if it’s doing something bad?

Virtual devices like Corellium’s offer an ideal place to test unknown apps. You don’t have to worry about contaminating a physical test device with malware, and you can simply delete the virtual device when you’re done testing. Our devices also offer unique built-in tools that give you greater control over the device environment and a ready-made setup for rapid analysis. Plus, Corellium’s devices run on ARM, giving you a realistic platform for testing without the hassle of recompiling.

Network Capture 

One of the first things you might want to inspect in an unknown app is network traffic. This can give you an idea if the app is sending traffic to a nefarious source. There are a number of ways you might approach this:

  1. tcpdump
  2. mitmproxy
  3. Certificate Pinning
  4. Frida

Corellium’s built-in Network Monitor tool makes it easy to inspect HTTP and HTTPS network traffic on your virtual device. Network Monitor leverages sslsplit to capture and present HTTP and HTTPS network traffic, transparently defeating certificate pinning. For any captured packet, you can drill in to view more information, the request, and the response.

System Call Tracing

Another key approach to assessing an unknown app is system call tracing, or intercepting and recording the system calls that are called and received by a process. This approach enables you to drill down into precisely what an application is doing and how it’s interacting with the surrounding system. It’s an invaluable dynamic analysis technique when source is not readily available.

Traditionally, to perform this type of tracing, you would use strace, a Linux diagnostic utility that can be used to monitor interactions between processes and the Linux kernel. The strace utility relies on a kernel feature known as ptrace. This makes it susceptible to anti-ptrace techniques. 

Corellium’s CoreTrace tool provides even more sophisticated tracing. EL2 patches the kernel system call entry to trap into the hypervisor, so it can record the system call and its arguments. Because it’s implemented at the hypervisor level, it avoids anti-ptrace techniques and cannot be easily detected by applications. CoreTrace can also trace the entire system at once — it isn’t limited to a single process. 

KASAN

If you happen to be up against a kernel vulnerability, one powerful tool at your disposal is to run the app with KASAN, Kernel Address Sanitizer. KASAN is a dynamic memory error detector designed to find out-of-bound and use-after-free bugs, and it works by checking whether all memory accesses are valid with compiler instrumentation. 

KASAN is appropriate to use in virtual environments like Corellium or QEMU. It can also be used on commercial products with unlocked bootloaders, or by SOC or OEM vendors. To try this in a Corellium virtual environment, check out our resources on building a Corellium Linux kernel, uploading a custom kernel to a Corellium device, and checking for KASAN output in the Corellium console. 

Kernel Debugging

The final method we reviewed in our workshop for assessing an unknown app is kernel debugging. Kernel debugging provides unparalleled introspection, but it can be difficult to set up, and it requires an understanding of Linux or XNU kernel internals. Often, it’s easier to reach for SystemTap first. 

Corellium devices make kernel debugging much more convenient by injecting a gdb stub into the device kernel’s memory. If you’re interested in exploring kernel debugging with a virtual Corellium device, check out our resources on kernel debugging and loading a custom kernel.