I am really looking forward to growing the project - interview with Ole André Vadla Ravnås creator of Frida

Dear Readers,

today we present you great interview with Ole André Vadla Ravnås who is creator of Frida- application which lets you inject your own JavaScript code into any process. He told us about the process of developing his tool, stealthy code tracking, his thoughts about JavaScript and many more. Enjoy reading! 

[PenTest Magazine] Ole. can you tell us something about yourself?

profile[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?

[OAVR] During the time when I was reverse-engineering the MSN webcam video codec, I found myself injecting a DLL into Microsoft's software so that I could patch their codec to gradually use my implementation. I had a test-suite that would encode/decode a sequence of frames and verify that the output would still be bit-exact compared to the original implementation. I did this function by function, starting out with Microsoft's implementation as inline assembly, and gradually translating that to C. Starting out with simple statements and gotos, then collapsing assignments. etc., recognizing for-loops vs do-while vs while loops, etc. For my next reversing project, which was Microsoft ActiveSync, as I had just gotten myself a Windows Phone (out of curiosity), I was faced with a very different reversing challenge. I tried to use Wireshark but it was really hard to see which process was doing what, and how the binary protocol was parsed. I ended up taking the tricks I learned from my codec project and quickly hacking up a tool called oSpy (screenshots attached) that would inject a DLL, hook some network API functions, and present the API calls in a simple UI. This helped me a lot, and I kept coming back to this tool for future projects, each time adding more hooks for the APIs I was dealing with. While it certainly got the job done, I really didn't feel too good about copy-pasting more and more C code and having this tool become like a kitchen-sink, so I just kept using this tool as a boilerplate for throw-away code that I wrote for each project. So there was that, but also the feeling that there was just too much friction, having to recompile the DLL, restart the target application to get it back into a consistent state, then inject, and finally get the feedback. With most projects, I found myself rinsing and repeating this process many times, as I'd improve my API hooks iteratively as my understanding of the problem kept evolving. The feedback loop was just too long. So there was that itch I wanted to scratch, but for the next few years, I would be too busy with my day-job to do much reversing, being just a hobby after all. I did, however, find some spare-time once in a while, so from 2008 or so, I slowly started piecing together a generic code instrumentation library written in C. This was an evolution of ideas from my crude C macros for hooking APIs, but all done at runtime. Fast-forward to 2010, and I finally got to the part where I packaged this instrumentation library into a shared library and built an API to inject this library into arbitrary processes. I also bundled Google's V8 JavaScript engine, and made my instrumentation library's APIs available to the JavaScript runtime. This was how Frida was born. I started out with Windows, as I had already been doing DLL injection for years, but it wasn't long until this evolved to also cover Mac, Linux, iOS, Android, and, thanks to a contributor, now also QNX.


[PM] Can you explain what Frida is, in case some of our readers don’t know?

[OAVR] Frida lets you inject your own JavaScript code into any process, on both desktop and mobile. This JavaScript runtime that Frida injects is conceptually just a language binding for Frida’s instrumentation engine, frida-gum. Beside letting you enumerate threads, loaded modules, hook arbitrary functions, call native APIs, etc., you can also interact with Objective-C and Java APIs on Mac/iOS and Android. You do all of this from the inside of the process, so not only can you spy on it, you can also change its behavior by replacing APIs or injecting errors anywhere you want, and everything happens in-process. With a traditional debugger, conditional breakpoints are very slow, because the external debugger process is involved every time each breakpoint hits, but with an in-process debugger, like Frida, you can implement this with a simple if-statement and it will be blazing fast, even on mobile. For example, hooking a function on an iPhone 6, the base overhead for an empty JavaScript callback is something like 15 microseconds.

[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?

[OAVR] It was a lot of work, as I had to reimplement the entire API (http://www.frida.re/docs/javascript-api/) that was already implemented for V8, but this time for JavaScriptCore. Thankfully, I had already written tests (https://github.com/frida/frida-gum/blob/master/tests/gumjs/script.c) since day one for the V8 runtime, so I knew that once these were all green, I could feel confident that no APIs were missing or behaving differently from the V8 runtime.

[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

[PM] Some time ago there were articles complaining about JavaScript. What is your opinion on it?

[OAVR] I personally think that JavaScript is a great scripting language, especially with ES6 (let, const, arrow functions, etc.). For Frida, the choice of JavaScript was always a pragmatic one, and I chose it because:

- 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. :-)


Ole André Vadla Ravnås
twitter: @fridadotre
Frida: http://www.frida.re

November 25, 2015
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest Most Voted
Inline Feedbacks
View all comments
Rachel Allen
6 years ago

Hi there, great article! I’ll be sure to share it on social media. What are your thoughts on tools like http://www.tweetfavy.com/ I’m using it to get more followers on my Twitter profile. Great stuff, you should check it out!

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013