[PenTest Magazine] Ole. can you tell us something about yourself?
[Ole André Vadla Ravnås] I grew up on a farm in a tiny place called Bjørheimsbygd, which is near Stavanger on the west-coast of Norway. Initially attracted to computers for gaming, I eventually discovered programming, and at that point I was hooked. As a huge fan of Linux, I started out by creating my own distro called JBLinux. Early on, I got really frustrated by vendor lock-in, as I had friends using MSN Messenger/Windows Live Messenger, and some of its features were only available to Windows users. This really motivated me to figure out the webcam protocol, which lead me to discover that Microsoft were using a proprietary video codec. At this point, I was supposed to focus on my studies, but for the next six months, I would be translating the disassembled video codec from assembly to C. I sadly never finished my degree, but I got a working video codec that even hit Slashdot (http://tech.slashdot.org/story/05/04/05/0240236/logitech-msn-webcam-codec-reverse-engineered). This was my gateway-drug into the world of reverse-engineering. After four years working for Tandberg, and towards the end of that, Cisco, who acquired them, me and some friends started Soundrop (www.soundrop.com) where we launched our own music discovery service inside of Spotify. Throughout these years, my passion for reverse-engineering was confined to my limited spare-time, and in May 2015, I finally took this passion full-time by joining NowSecure as a security researcher, where we are using Frida for dynamic instrumentation of mobile apps.
[PM] How did you came up with idea of creating Frida?
[PM] Can you explain what Frida is, in case some of our readers don’t know?
[PM] Dozen days ago you released new version of your tool. Please tell us what’s new about it?
[OAVR] Frida 6.0 makes it possible to instrument apps and system services on iOS 9, and also comes with huge improvements to its function hooking abilities. The technical solutions that made this possible also paved the way for Frida to be able to instrument apps on iOS without a jailbreak. As of today, one week after this release, this is now a reality: http://www.frida.re/docs/ios/#without-jailbreak
[PM] Have you got any difficulties with creating it?
[PM] Frida works on the most popular operating systems. Which one do you prefer to work on the most?
[OAVR] I've been lucky enough to do professional software development on/for all of the OSes that Frida supports. Just like with programming languages, I do appreciate the different OSes for different aspects. I really like Linux for its openness and F/OSS, yet even if I once built my own distro and loved tweaking every little detail at some point, I did grow increasingly lazy over the years. I found myself switching to Gentoo, then later Ubuntu, and as my laziness grew even further, I found myself using OS X. I really enjoy reverse-engineering proprietary software, so in that sense, I enjoy the challenges that Mac and iOS keep on giving. At the same time, I'm also a fan of Microsoft's developer tools and native debugger, so I do enjoy occasional reboots into Bootcamp to work on Frida's Windows backend. So the bottom line is that I prefer using OS X, as it's the only setup where I have a UNIX system and can run all the other OSes virtualized (without Hackintosh-like tampering, or worrying about driver support).
[PM] Can you tell us more about stealthy code tracking in Frida?
[OAVR] Frida was designed to be an in-process debugger that tries to avoid using OS-provided debugger APIs whenever possible. The level of stealth depends on the OS, and there is still lots of room for improvement. The most recent improvement was on Mac, where we no longer use dlopen() to load our shared library into the process that we want to inject code into. Instead, I have written an out-of-process dynamic linker (https://github.com/frida/frida-gum/blob/master/gum/backend-darwin/gumdarwinmapper.c) that lets us inject Frida into processes that are sandboxed and don't have access to the file-system. This also means that our injected library isn't part of the list of loaded libraries. Another cool area is Frida's Stalker, which is a code tracer based on dynamic recompilation. Instead of executing the original instructions, or modifying them to "hook" certain points of execution, the Stalker copies the original instructions to a new memory location and adds the desired logging code around the original instructions. As some instructions are position-dependent, it takes great care to rewrite those instructions so their behavior is identical to the original instructions. It also rewrites instructions so that their side-effects on the stack and memory are identical. For example: a CALL instruction will push the address of the next instruction on the stack, and we rewrite those so that the address pushed is exactly what it would have been if it was the original CALL instruction that got executed. This means we're invisible to the code, and also means we can stop tracing that thread at any point in time without having to roll back addresses on the stack. Here's a demo app using Stalker: https://www.youtube.com/watch?v=hzDsxtcRavY
- it's dynamic, which is great for rapid iterative experimentation;
- minimal, there isn't really any standard library beside a few built-in types, so you get to define your own world for just your application (giving you more freedom to customize it for your domain, without having to build your own DSL from scratch);
- no assumption that there is a file-system available;
- there's a great selection of blazing fast high-quality runtimes available.
That said, I really believe in using different languages based on the task at hand. For example, in Frida, its low-level instrumentation engine, frida-gum, is written in C and assembly. However, for frida-core, which is more of a logistics layer that takes care of injecting this engine into remote processes and communicating with those, that's written in a C#-like language called Vala. The beauty of Vala is that it compiles to the same flavor of C that frida-gum is written in, and lets us expose a simple C API for consumption by language bindings. Then you have frida-python that is written mostly in Python, with a little bit of glue code in C to give you access to the frida-core APIs from Python. Anyway, my point is just that IMHO there isn't really a perfect language to rule them all, they all have their strengths and weaknesses.
[PM] What is the future of the application?
[OAVR] The next big thing for Frida is all about community. I'm really excited to see what people will build on top of it, but more importantly, I am really looking forward to growing the project. We're still somewhat obscure as an open source project, and even if there's been a few great contributions, they've been few and far between. I am still the only active maintainer, currently maintaining 12 different OS/arch combinations while also working on new features and fixing bugs. Still it's a lot of fun and there's really nothing else I'm more passionate about than this. :-)
[PM] Have you got any final thoughts? Is there anything you would like to add?
[OAVR] No, I think I might have gone a bit overboard already. :-)