Just a minor bug-fix release to fix spawn() on Mac, and resolve some teardown issues. Enjoy!

This release introduced a serious regression on iOS and was quickly pulled from our Cydia repo, though it was available for Mac, Linux and Android while waiting to be replaced by 2.0.0.

It’s time for a new and exciting release! Key changes include:

• No more kernel panics on Mac and iOS! Read the full story here.
• Mac and iOS injector performs manual mapping of Frida’s dylib. This means we’re able to attach to heavily sandboxed processes.
• The CLI tools like frida-trace, frida-repl, etc., have brand new support for spawning processes:

$ frida-trace -i 'open*' -i 'read*' /bin/cat /etc/resolv.conf
    27 ms	open$NOCANCEL()
    28 ms	read$NOCANCEL()
    28 ms	read$NOCANCEL()
    28 ms	read$NOCANCEL()
Target process terminated.
Stopping...
$

• Usability improvements in frida-repl and frida-discover.
• First call to DeviceManager.enumerate_devices() does a better job and also gives you the currently connected iOS devices, so for simple applications or scripts you no longer have to subscribe to updates if you require the device to already be present.
• The python API now provides you with frida.get_usb_device(timeout = 0) and frida.get_remote_device() for easy access to iOS and remote/Android devices.
• The onEnter and onLeave callbacks passed to Interceptor.attach() may access this.registers to inspect CPU registers, which is really useful when dealing with custom calling conventions.
• console.log() logs to the console on your application’s side instead of the target process. This change is actually why we had to bump the major version for this release.
• Android 5.0 compatibility, modulo ART support.
• Brand new support for Android/x86. Everything works except the Dalvik integration; please get in touch if you’d like to help out with a pull-request to fix that!

Want to help out? Have a look at our GSoC 2015 Ideas Page to get an overview of where we’d like to go next.

Enjoy!

Update 2am: An iOS issue slipped through the final testing, so we just pushed 2.0.1 to remedy this.

Update 11pm: Thanks to your excellent feedback we found a critical bug when using Frida on Windows with certain iOS device configurations. Please upgrade to 2.0.2 and let us know if you run into any issues.

Just a quick bug-fix release to remedy an iOS issue that slipped through the final testing of 2.0.0. Enjoy!

Thanks to your excellent feedback we just eliminated a crasher when using Frida on Windows with certain iOS device configurations. As this is a very important use-case we decided to do a hotfix release without any other changes.

Please keep the bug-reports coming!

You may have wondered:

Why a Python API, but JavaScript debugging logic?

Well, you can now do this:

$ npm install frida

We just brought you brand new Node.js bindings, and they are fully asynchronous:

Check out the examples to get an idea what the API looks like. It’s pretty much a 1:1 mapping of the API provided by the Python bindings, but following Node.js / JavaScript conventions like camelCased method-names, methods returning ES6 Promise objects instead of blocking, etc.

Now, combine this with NW.js and you can build your own desktop apps with HTML, CSS, and JavaScript all the way through.

So, brand new Node.js bindings; awesome! We did not stop there, however. But first, a few words about the future. I am excited to announce that I have just started a company with the goal of sponsoring part-time development of Frida. By offering reverse-engineering and software development expertise, the goal is to generate enough revenue to pay my bills and leave some time to work on Frida. Longer term I’m hoping there will also be demand for help adding features or integrating Frida into third-party products. In the meantime, however, if you know someone looking for reverse-engineering or software development expertise, I would really appreciate it if you could kindly refer them to get in touch. Please see my CV for details.

That aside, let’s get back to the release. Next up: 32-bit Linux support! Even Stalker has been ported. Not just that, the Linux backend can even do cross-architecture injection like we do on the other platforms. This means a 64-bit Frida process, e.g. your Python interpreter, can inject into a 32-bit process. The other direction works too.

Another awesome update is that Tyilo contributed improvements to frida-trace so it now uses man-pages for auto-generating the log handlers. Awesome, huh? But there’s even more goodies:

• frida-server ports are now recycled, so if you’re using Frida on Android you won’t have to keep forwarding ports unless you’re actually attaching to multiple processes at the same time.
• Linux and Android spawn() support has been improved to also support PIE binaries.
• Android stability and compatibility improvements.
• Mac and Linux build system have been revamped, and make it easy to build just the parts that you care about; and maybe even some components you didn’t even know were there that were previously not built by default.
• Python bindings have a minor simplification so instead of frida.attach(pid).session.create_script() it’s simply just frida.attach(pid).create_script(). This is just like in the brand new Node.js bindings, and the reason we had to bump the major version.

That’s the gist of it. Please help spread the word by sharing this post across the inter-webs. We’re still quite small as an open source project, so word-of-mouth marketing means a lot to us.

Enjoy!

It’s time for an insane release with tons of improvements.

Let’s start with a user-facing change. The CLI tool called frida-repl has been renamed to just frida, and now does tab completion! This and some other awesome REPL goodies were contributed by @fitblip.

There is also integrated support for launching scripts straight from the shell:

$ frida Calculator -l calc.js
    _____
   (_____)
    |   |    Frida 4.0.0 - A world-class dynamic
    |   |                  instrumentation framework
    |`-'|
    |   |    Commands:
    |   |        help      -> Displays the help system
    |   |        object?   -> Display information about 'object'
    |   |        exit/quit -> Exit
    |   |
    |   |    More info at http://www.frida.re/docs/home/
    `._.'

# The code in calc.js has now been loaded and executed
[Local::ProcName::Calculator]->
# Reload it from file at any time
[Local::ProcName::Calculator]-> %reload
[Local::ProcName::Calculator]->

Or, perhaps you’re tired of console.log() and would like to set some breakpoints in your scripts to help you understand what’s going on? Now you can, because Frida just got an integrated Node.js-compatible debugger.

Yep yep, but it is actually quite useful, and all of the CLI tools provide the --debug switch to enable it:

# Connect Frida to a locally-running Calculator.app
# and load calc.js with the debugger enabled
$ frida Calculator -l calc.js --debug
    _____
   (_____)
    |   |    Frida 4.0.0 - A world-class dynamic
    |   |                  instrumentation framework
    |`-'|
    |   |    Commands:
    |   |        help      -> Displays the help system
    |   |        object?   -> Display information about 'object'
    |   |        exit/quit -> Exit
    |   |
    |   |    More info at http://www.frida.re/docs/home/
    `._.'

Debugger listening on port 5858
# We can now run node-inspector and start debugging calc.js
[Local::ProcName::Calculator]->

Here’s what it looks like:

Ever found yourself wanting to frida-trace Objective-C APIs straight from the shell? Thanks to @Tyilo you now can:

# Trace ObjC method calls in Safari
$ frida-trace -m '-[NSView drawRect:]' Safari

There are also other goodies, like brand new support for generating backtraces and using debug symbols to symbolicate addresses:

var f = Module.findExportByName("libcommonCrypto.dylib",
    "CCCryptorCreate");
Interceptor.attach(f, {
    onEnter: function (args) {
        console.log("CCCryptorCreate called from:\n" +
            Thread.backtrace(this.context, Backtracer.ACCURATE)
            .map(DebugSymbol.fromAddress).join("\n") + "\n");
    }
});

Or perhaps you’re on Windows and trying to figure out who’s accessing certain memory regions? Yeah? Well check out the brand new MemoryAccessMonitor. Technically this code isn’t new, but it just hasn’t been exposed to the JavaScript API until now.

Another nice feature is that starting with this release it is no longer necessary to forward multiple TCP ports when using frida-server running on another device, e.g. Android.

There is now also much better error feedback propagated all the way from a remote process to different exceptions in for example Python. With the previous release attaching to an inexistent pid on Mac would give you:

SystemError: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2↩
dio_2derror_2dquark.Code0: task_for_pid() for remote pid failed w↩
hile trying to make pipe endpoints: (os/kern) failure (5)

Whoah, madness. This is now simply:

frida.ProcessNotFoundError: unable to find process with pid 1234

That’s better. Let’s talk about performance. Perhaps you used frida-trace and wondered why it spent so much time “Resolving functions…”? On a typical iOS app resolving just one function would typically take about 8 seconds. This is now down to ~1 second. While there were some optimizations possible, I quickly realized that no matter how fast we make the enumeration of function exports, we would still need to transfer the data, and the transfer time alone could be unreasonable. Solution? Just move the logic to the target process and transfer the logic instead of the data. Simple. Also, the Dalvik and ObjC interfaces have been optimized so seconds have been reduced to milliseconds. The short story here is further laziness in when we interrogate the language runtimes. We took this quite far in the ObjC interface, where we now use ES6 proxies to provide a more idiomatic and efficient API.

That brings us to the next topic. The ObjC interface has changed a bit. Essentially:

var NSString = ObjC.use("NSString");

is now:

var NSString = ObjC.classes.NSString;

You still use ObjC.classes for enumerating the currently loaded classes, but this is now behaving like an object mapping class name to a JavaScript ObjC binding.

Also, there’s no more casting, so instead of:

var NSSound = ObjC.use('NSSound');
var sound = ObjC.cast(ptr("0x1234"), NSSound);

You just go:

var sound = new ObjC.Object(ptr("0x1234"));

Yep, no more class hierarchies trying to mimic the ObjC one. Just a fully dynamic wrapper where method wrappers are built on the first access, and the list of methods isn’t fetched unless you try to enumerate the object’s properties.

Anyway, this is getting long, so let’s summarize the other key changes:

• The Dalvik interface now handles varargs methods. Thanks to @dmchell for reporting and helping track this down.
• NativePointer also provides .and(), .or() and .xor() thanks to @Tyilo.
• The Interceptor’s onEnter/onLeave callbacks used to expose the CPU registers through this.registers, which has been renamed to this.context, and now allows you to write to the registers as well.
• Process.enumerateThreads()’s thread objects got their CPU context field renamed from registers to context for consistency.
• Synchronous versions of enumerateFoo() API available as enumerateFooSync() methods that simply return an array with all of the items.
• Memory.readCString() is now available for reading ASCII C strings.
• Frida.version can be interrogated to check which version you’re running, and this is also provided on the frida-core end, which for example is exposed by frida-python through frida.__version__.
• Stalker now supports the jecxz and jrcxz instructions. This is good news for CryptoShark, which should soon provide some updated binaries to bundle the latest version of Frida.
• V8 has been updated to 4.3.62, and a lot of ES6 features have been enabled.
• We’re now using a development version of the upcoming Capstone 4.0.
• All third-party dependencies have been updated to the latest and greatest.
• Windows XP is now supported. This is not a joke. I realized that we didn’t actually use any post-XP APIs, and as I had to rebuild the dependencies on Windows I figured we might as well just lower our OS requirements to help those of you still instrumenting software on XP.

Enjoy!

It’s release o’clock, and this time we’re taking the iOS support to the next level while also bringing some solid quality improvements. I’m also really excited to announce that I’ve recently joined NowSecure, and the awesomeness of this release is no conincidence.

Let’s start with a brand new iOS feature. It’s now possible to list installed apps, which frida-ps can do for you:

$ frida-ps -U -a
  PID NAME        IDENTIFIER
10582 Facebook    com.facebook.Facebook
11066 IRCCloud    com.irccloud.IRCCloud
  451 Mail        com.apple.mobilemail
10339 Mailbox     com.orchestra.v2
 6866 Messages    com.apple.MobileSMS
10626 Messenger   com.facebook.Messenger
11043 Settings    com.apple.Preferences
10542 Skype       com.skype.skype
11218 Slack       com.tinyspeck.chatlyio
11052 Snapchat    com.toyopagroup.picaboo
$

Add the -i switch and it will also include all installed applications, and not just those of them that are currently running.

This is also available from your language binding of choice, e.g. from Python:

>>> import frida
>>> iphone = frida.get_usb_device()
>>> print("\n".join(map(repr, iphone.enumerate_applications())))
Application(identifier="com.google.ios.youtube", name="YouTube")
Application(identifier="com.toyopagroup.picaboo", name="Snapchat")
Application(identifier="com.skype.skype", name="Skype", pid=10542)
…
>>>

That’s cool, but wouldn’t you like to do early instrumentation of those apps? Now you can do that too, by just asking us to spawn an app identifier:

$ frida-trace -U -f com.toyopagroup.picaboo -I "libcommonCrypto*"

Or at the API level:

>>> import frida
>>> iphone = frida.get_usb_device()
>>> pid = iphone.spawn(["com.toyopagroup.picaboo"])
>>> snapchat = iphone.attach(pid)
>>> …apply instrumentation…
>>> iphone.resume(pid)

Note that we piggy-back on Cydia Substrate for the early launch part in order to maximize interoperability; after all it’s not too good if multiple frameworks all inject code into launchd and risk stepping on each others’ toes. This dependency is however a soft one, so we’ll throw an exception if Substrate isn’t installed when trying to call spawn() with an app identifier.

So, early instrumentation of iOS apps is pretty cool. But, those applications are typically consuming tons of Objective-C APIs, and if we want to instrument them we often find ourselves having to create new Objective-C classes in order to create delegates to insert between the application and the API. Wouldn’t it be nice if such Objective-C classes could be created in pure JavaScript? Now they can:

const MyConnectionDelegateProxy = ObjC.registerClass({
  name: 'MyConnectionDelegateProxy',
  super: ObjC.classes.NSObject,
  protocols: [ObjC.protocols.NSURLConnectionDataDelegate],
  methods: {
    '- init': function () {
      const self = this.super.init();
      if (self !== null) {
        ObjC.bind(self, {
          foo: 1234
        });
      }
      return self;
    },
    '- dealloc': function () {
      ObjC.unbind(this.self);
      this.super.dealloc();
    },
    '- connection:didReceiveResponse:': function (conn, resp) {
      /* this.data.foo === 1234 */
    },
    /*
     * But those previous methods are declared assuming that
     * either the super-class or a protocol we conform to has
     * the same method so we can grab its type information.
     * However, if that's not the case, you would write it
     * like this:
     */
    '- connection:didReceiveResponse:': {
      retType: 'void',
      argTypes: ['object', 'object'],
      implementation: function (conn, resp) {
      }
    },
    /* Or grab it from an existing class: */
    '- connection:didReceiveResponse:': {
      types: ObjC.classes
          .Foo['- connection:didReceiveResponse:'].types,
      implementation: function (conn, resp) {
      }
    },
    /* Or from an existing protocol: */
    '- connection:didReceiveResponse:': {
      types: ObjC.protocols.NSURLConnectionDataDelegate
          .methods['- connection:didReceiveResponse:'].types,
      implementation: function (conn, resp) {
      }
    },
    /* Or write the signature by hand if you really want to: */
    '- connection:didReceiveResponse:': {
      types: 'v32@0:8@16@24',
      implementation: function (conn, resp) {
      }
    }
  }
});

const proxy = MyConnectionDelegateProxy.alloc().init();
/* use `proxy`, and later: */
proxy.release();

Though most of the time you’d like to build a proxy object where you pass on everything and only do some logging for the few methods you actually care about. Check this out:

const MyConnectionDelegateProxy = ObjC.registerProxy({
  protocols: [ObjC.protocols.NSURLConnectionDataDelegate],
  methods: {
    '- connection:didReceiveResponse:': function (conn, resp) {
      /* fancy logging code here */
      /* this.data.foo === 1234 */
      this.data.target
          .connection_didReceiveResponse_(conn, resp);
    },
    '- connection:didReceiveData:': function (conn, data) {
      /* other logging code here */
      this.data.target
          .connection_didReceiveData_(conn, data);
    }
  },
  events: {
    forward: function (name) {
      console.log('*** forwarding: ' + name);
    }
  }
});

const method = ObjC.classes.NSURLConnection[
    '- initWithRequest:delegate:startImmediately:'];
Interceptor.attach(method.implementation, {
  onEnter: function (args) {
    args[3] = new MyConnectionDelegateProxy(args[3], {
      foo: 1234
    });
  }
});

So that’s Objective-C. The Dalvik integration also got some sweet new API for enumerating loaded classes thanks to @marc1006, who also fixed our handling of static methods and being able to return booleans from overriden implementations.

We also got lots of awesome improvements from @Tyilo who helped improve the ObjC integration, beat the REPL into better shape, added APIs for enumerating malloc ranges, and added some convenience APIs to NativePointer.

While all of this was going on, @s1341 has been hard at work doing an amazing job porting Frida to QNX, which is now really close to working like a charm.

Let’s run through the remaining changes:

4.0.1:

• objc: support for more types
• frida-trace: fix ObjC tracing regression

4.0.2:

• frida-node: fix encoding of the pixels property

4.0.3:

• frida-repl: fix Windows regression

4.0.5:

• objc: support for more types and better type checking
• objc: arm64 now working properly
• frida-repl: allow variables to be created

4.0.6:

• platform: support passing a plain array of data to send()
• arm: support for relocating cbz/cbnz instructions

4.1.0:

• platform: fix spawning of child processes that write to stdout
• platform: fix NativeCallback’s handling of bool/int8/uint8 return values (this was preventing Dalvik method overrides from being able to return false).
• platform: allow Memory.readByteArray() with length < 1
• arm: support for relocating the ldrpc t2 instruction
• arm: improved redirect resolver
• arm64: fix relocation of the adrp instruction
• arm64: support for relocating PC-relative ldr instruction
• dalvik: add Dalvik.enumerateLoadedClasses()
• dalvik: fix handling of static methods
• python: fix console.log() on Windows
• frida-repl: bugfixes and improvements
• frida-trace: glob support for tracing ObjC methods

4.1.1:

• platform: add missing pid field in enumerate_applications()

4.1.2:

• objc: class and proxy creation APIs
• objc: new ObjC.protocols API for enumerating protocols

4.1.3:

• platform: improved concurrency by releasing V8 lock while calling NativeFunction
• platform: add Process.getModuleByName(name)
• platform: faster and more robust detach
• python: stability improvements in CLI tools
• frida-repl: replace readline with prompt-toolkit

4.1.4:

• platform: faster and more robust teardown
• frida-server: clean up on SIGINT and SIGTERM

4.1.5:

• frida-ps: add support for listing applications

4.1.6:

• platform: fix crash on spawn on Mac, iOS and Linux
• platform: add NativePointer.compare() and NativePointer.equals()
• platform: add Process.enumerateMallocRanges{,Sync}()
• frida-trace: switch from Enter to Ctrl+C for stopping
• frida-trace: fix spawning of iOS apps
• frida-repl: add prototype names to autocomplete

4.1.7:

• python: CLI tools stability improvements

That’s all for now. Please help spread the word by sharing this post across the inter-webs. We’re still quite small as an open source project, so word-of-mouth marketing means a lot to us.

Enjoy!

The Frida co-conspirators have been cracking away on several fronts, so much lately that I figured it was worth jotting this down to get the word out.

In Dalvik land, @marc1006 contributed a really neat new feature – the ability to do object carving, essentially scanning the heap for objects of a certain type. Check this out:

const strings = [];
Dalvik.choose('java.lang.String', {
  onMatch: function (str) {
    strings.push(str);
  },
  onComplete: function () {
    console.log('Found ' + strings.length + ' strings!');
  }
});

Meanwhile, @Tyilo has been rocking out adding the same feature for Objective-C:

const strings = [];
ObjC.choose(ObjC.classes.NSString, {
  onMatch: function (str) {
    strings.push(str);
  },
  onComplete: function () {
    console.log('Found ' + strings.length + ' strings!');
  }
});

In other mobile news, @pancake added support for enumerating applications on Firefox OS. Sweet!

While all of this was going on, @s1341 has been hard at work stabilizing the QNX port, and it’s reportedly working really well now.

On my end I have been applying Frida to interesting challenges at NowSecure, and ran into quite a few bugs and limitations in the Objective-C integration. There’s now support for overriding methods that deal with struct types passed by value, e.g. -[UIView drawRect:], which means NativeFunction and NativeCallback also support these; so for declaring a struct simply start an array with the fields’ types specified sequentially. You can even nest them. So for the - drawRect: case where a struct is passed by value, and that struct is made out of two other structs, you’d declare it like this:

const f = new NativeFunction(ptr('0x1234'), 'void',
    [[['double', 'double'], ['double', 'double']]]);

Another thing worth mentioning is that a long-standing issue especially visible when instrumenting 32-bit iOS apps, but affecting all platforms, has finally been fixed.

So let’s run quickly through all the changes:

4.1.8:

• core: add support for enumerating applications on Firefox OS
• core: add NativePointer.toMatchPattern() for use with Memory.scan()
• core: fix QNX injector race condition
• objc: massively improved handling of types
• objc: fix implicit conversion from JS string to NSString
• objc: fix crash during registration of second proxy or unnamed class
• objc: new ObjC.Object properties: $className and $super
• dalvik: add Dalvik.choose() for object carving

4.1.9:

• core: NativeFunction and NativeCallback now support functions passing struct types by value
• core: fix accidental case-sensitivity in Process.getModuleByName()
• dalvik: new object property: $className

4.2.0:

• core: add this.returnAddress to Interceptor’s onEnter and onLeave callbacks
• objc: add ObjC.choose() for object carving

4.2.1:

• core: fix exports enumeration of stripped libraries on QNX
• objc: new ObjC.Object property: $kind, a string that is either instance, class or meta-class
• objc: fix the $class property so it also does the right thing for classes
• objc: fix crash when looking up inexistent method
• python: ensure graceful teardown of the reactor thread
• frida-discover: fix regression
• frida-repl: fix hang when target crashes during evaluation of expression

4.2.2:

• core: fix exception handling weirdness; very visible on ios-arm
• core: QNX stability improvements
• objc: add ObjC.api for direct access to the Objective-C runtime’s API
• objc: new ObjC.Object properties: equals, $superClass and $methods
• objc: fix iOS 7 compatibility
• objc: fix toJSON() of ObjC.classes and ObjC.protocols
• dalvik: fix handling of java.lang.CharSequence
• frida-repl: add %time command for easy profiling

4.2.3:

• core: fix crash when handling exceptions without a message object
• core: fix the life-time of CpuContext JS wrappers
• core: expose the file mapping info to Process.enumerateRanges()
• core: make it possible to coalesce neighboring ranges when enumerating
• core: add convenience API for looking up modules and ranges
• core: make the QNX mprotect read in a loop instead of just the once
• dalvik: avoid crashing the process if a type conversion fails
• dalvik: allow null as call parameter
• objc: fix conversion of structs with simple field types
• objc: speed up implicit string conversion by caching wrapper object

4.2.4:

• objc: fix crash when interacting with not-yet-realized classes

4.2.5:

• core: optimize Interceptor callback logic and make it twice as fast when onEnter and onLeave aren’t both specified
• core: fix return-address seen by the invocation-context on arm64
• core: add a fuzzy backtracer for arm64

That’s all for now. Please help spread the word by sharing this post across the inter-webs. We’re still quite small as an open source project, so word-of-mouth marketing means a lot to us.

Enjoy!

It’s release o’clock, and this time we have a slew of improvements all over the place. In brief:

4.3.0:

• core: add support for getting details about the frontmost application, initially only for iOS
• python: add Device.get_frontmost_application()
• node: add Device.getFrontmostApplication()

4.3.1:

• core: add support for relocating PC-relative CBZ on arm64
• frida-repl: fix crash and loading of script on Py3k

4.3.2:

• core: add support for launching an iOS app with a URL
• dalvik: fix bug in field caching
• frida-trace: color and indent events based on thread ID and depth
• frida-ps: fix application listing on Py3k

4.3.3:

• core: re-enable the Darwin mapper after accidentally disabling it

4.3.4:

• core: gracefully handle attempts to replace functions
• core: throw an exception when Interceptor’s attach() and replace() fail
• core: fix clean-up of agent sessions
• core: fix assertion logging and log to CFLog on Darwin
• dalvik: add Dalvik.synchronized(), Dalvik.scheduleOnMainThread() and Dalvik.isMainThread()
• dalvik: port Dalvik.androidVersion and Dalvik.choose() to Android 4.2.2
• python: fix the PyPI download URL for windows-i386
• frida-trace: handle attach() failures gracefully

4.3.5:

• frida-server: better resource tracking

4.3.6:

• core: fix for arm64 function hooking
• dalvik: fix for Dalvik.enumerateLoadedClasses()

4.3.7:

• objc: add ObjC.Block for implementing and interacting with blocks

Enjoy!

With 4.4 out the door, we can now offer you a brand new RPC API that makes it super-easy to communicate with your scripts and have them expose services to your application. We also got some amazing contributions from Adam Brady, who just ported frida-node to Nan, making it easy to build it for multiple versions of Node.js.

So to summarize this release:

• core: add new RPC API
• python: add support for calling RPC exports
• node: add support for calling RPC exports
• node: allow posted message value to be anything serializable to JSON
• node: port to Nan

Enjoy!

Time for another packed release. This time we’re bringing a brand new spawn gating API that lets you catch processes spawned by the system, and tons of Android improvements and improvements all over the place.

So without further ado, the list of changes:

4.5.0:

• core: add Process.pageSize constant
• core: let Memory.alloc() allocate raw pages when size >= page size
• core: fix NativeFunction’s handling of small return types
• core: fix PC alignment when rewriting BLX instructions
• core: add spawn gating API
• core: implement get_frontmost_application() on Android
• core: implement enumerate_applications() on Android
• core: add support for spawning Android apps
• core: add support for injecting into arm64 processes on Android
• core: add support for Android M
• core: patch the kernel’s live SELinux policy
• core: integrate with SuperSU to work around restrictions on Samsung kernels
• core: work around broken sigsetjmp on Android, and many other Android fixes
• core: fix crash when enumerating modules on Linux
• core: optimize exports enumeration for remote processes on Darwin
• dalvik: port to ART and deprecate Dalvik name, now known as Java
• java: add Java.openClassFile() to allow loading classes at runtime
• java: fixes for array conversions and field setters
• python: add support for the new spawn gating API
• python: allow script source and name to be unicode on Python 2.x also
• python: fix error-propagation in Python 3.x
• python: fix the Linux download URL computation
• node: add support for the new spawn gating API
• node: port to Nan 2.x

4.5.1:

• core: fix ensure_host_session() error propagation

Enjoy!

Wow, another major release! We decided to change the Device API to give you persistent IDs so you can easily tell different devices apart as they’re hotplugged.

But that’s just the beginning of it, we’re also bringing a ton of other improvements this time:

5.0.0:

• core: change Device.id to represent individual devices across reconnects
• core: add new Droidy backend for interfacing with connected Android devices
• core: adjust confusing iPhone 5+ device name on Darwin
• core: normalize the fallback iOS device name for consistency with Android
• core: upgrade V8 to 4.5.103.30
• objc: include both class and instance methods in $methods and $ownMethods
• python: add -D switch for specifying the device id to connect to
• python: add frida-ls-devices CLI tool for listing devices
• python: update to the new Device.id API
• python: add get_local_device() and improve API consistency with frida-node
• node: update to the new Device.id API
• node: improve the top-level facade API
• qml: update to the new Device.id API
• clr: update to the new Device.id API
• frida-ps: improve the output formatting

5.0.1:

• core: add support for source maps
• node: add frida.load() for turning a CommonJS module into a script
• node: upgrade Nan

5.0.2:

• core: add console.warn() and console.error()
• core: add Module.enumerateImports() and implement on Darwin, Linux, and Windows
• core: allow null module name when calling Module.findExportByName()
• core: move Darwin.Module and Darwin.Mapper from frida-core to frida-gum, allowing easy Mach-O parsing and out-of-process dynamic linking
• core: better handling of temporary files
• frida-trace: add support for conveniently tracing imported functions
• frida-trace: blacklist dyld_stub_binder from being traced
• python: avoid logging getting overwritten by the status message changing

5.0.3:

• core: improve arm64 hooking, including support for hooking short functions

5.0.4:

• core: improve arm64 hooking, also taking care to avoid relocating instructions that other instructions depend on, including the next instruction after a BL/BLR/SVC instruction
• core: port Arm64Writer and Arm64Relocator to Capstone

5.0.5:

• core: fix crash on teardown by using new API provided by our GLib patch
• core: fix module name resolving on Linux
• core: improve ELF handling to also consider ET_EXEC images as valid modules
• core: improve arm64 hooking
• core: port {Arm,Thumb}Writer and {Arm,Thumb}Relocator to Capstone
• python: fix tests on OS X 10.11
• node: fix tests on OS X 10.11

5.0.6:

• core: turn NativeFunction invocation crash into a JS exception when possible
• core: add Process.setExceptionHandler() for handling native exceptions from JS
• core: install a default exception handler that emits error messages
• core: prevent apps from overriding our exception handler if we install ours early in the process life-time
• core: gracefully handle it if we cannot replace native functions
• core: allow RPC exports to return ArrayBuffer values
• python: add support for rpc methods returning ArrayBuffer objects
• node: add support for rpc methods returning ArrayBuffer objects

5.0.7:

• core: don’t install a default exception handler for now

5.0.8:

Re-release of 5.0.7 due to build machine issues.

5.0.9:

• python: update setup.py to match new build server configuration

5.0.10:

• core: fix instrumentation of arm64 functions with early usage of IP registers

Enjoy!

Epic release this time, with brand new iOS 9 support and improvements all over the place. For some more background, check out my blog posts here and here.

There’s a lot of ground to cover here, but the summary is basically:

6.0.0:

• core: add support for OS X El Capitan
• core: add support for iOS 9
• core: fix launchd plist permissions in Cydia package
• core: disable our dynamic linker on iOS for now
• core: add new JavaScript runtime based on JavaScriptCore, as we cannot use V8 on iOS 9 with the current jailbreak
• core: add brand new system session when attaching to pid=0
• core: improve arm hooking, including support for early TBZ/TBNZ/IT/B.cond, and avoid relocating instructions that a later instruction loops back to
• core: fix relocation of LDR.W instructions on arm64
• core: abort when we’re stuck in an exception loop
• core: fix AutoIgnorer-related deadlocks
• core: drop our . prefix so temporary files are easier to discover
• python: add support for running without ES6 support
• python: tweak setup.py to allow offline installation
• python: lock the prompt-toolkit version to 0.38 for now
• frida-repl: fix display of raw buffers as returned by Memory.readByteArray()
• frida-repl: fix crash in completion on error
• node: add support for DeviceManager’s added and removed signals
• node: add example showing how to watch available devices
• node: use prebuild instead of node-pre-gyp
• node: Babelify the source code read by frida.load()
• node: remove frida.load() as it’s now in the frida-load module

6.0.1:

• python: stop providing 3.4 binaries and move to 3.5 instead
• node: fix Linux linking issue where we fail to pick up our libffi
• node: also produce prebuild for Node.js LTS

6.0.2:

• core: provide FridaGadget.dylib for instrumenting iOS apps without jailbreak
• core: add support for the iOS Simulator
• core: improve MemoryAccessMonitor to allow monitoring any combination of R, W or X operations on a page
• python: fix UTF-8 fields being accidentally exposed as str on Python 2.x

6.0.3:

• core: fix spawn() on OS X

6.0.4:

• core: add partial support for using the gadget standalone
• CLI tools: fix crash when the stdout encoding cannot represent all characters
• frida-trace: always treat handler scripts as UTF-8

6.0.5:

• core: add logical shift right and left operations to NativePointer
• core: improve Interceptor to support attaching to a replaced function
• core: add support for hooking tiny functions on 32-bit ARM
• core: emulate {Get/Set}LastErrror and TLS key access on Windows, allowing us to hook more low-level APIs

6.0.6:

• core: fix launchd / Jetsam issue on iOS 9
• core: fix iOS 9 code signing issue
• core: update security attributes on named pipe to allow us to inject into more Windows apps

6.0.7:

• core: add support for injecting into processes on linux-arm
• core: fix crashes related to the DebugSymbol API on Mac and iOS
• frida-trace: improve manpage parser

6.0.8:

• core: fix Linux compatibility issue caused by failing to link libstdc++ statically

6.0.9:

• core: add support for running frida-gadget standalone
• core: add a temporary workaround for Windows compatibility regression
• core: port the Fruity backend to Linux, allowing direct access to connected iOS devices
• core: expose the InvocationContext context read-write in the JavaScriptCore runtime also
• core: fix issue with InvocationContext’s CpuContext getting GCed prematurely

6.0.10:

Re-release of 6.0.9 with a Windows build regression fix.

6.0.11:

• core: prevent stale HostSession objects in case of network errors
• CLI tools: assume UTF-8 when the stdout encoding is unknown
• node: fix double free caused by using the wrong Nan API

6.0.12:

• core: update security attributes on named pipe on Windows
• core: add CreateProcessW flags to prevent IFEO loop on Windows
• core: fix hooking of recursive functions on arm and arm64
• python: fix Python 3 line endings regression
• node: update prebuild dependency

Enjoy!

Some time ago @s1341 ported Frida to QNX, and just a few weeks back he was running into memory footprint issues when using Frida on embedded ARM devices. This was right after he contributed pull-requests porting Frida to linux-arm. We started realizing that it might be time for a new JavaScript runtime, and agreed that Duktape seemed like a great fit for our needs.

This runtime has now landed, all tests are passing, and it even beats our V8 runtime on the measured overhead for a call to a hooked function with an empty onEnter/onLeave callback. To give you an idea:

…/interceptor_on_enter_performance: V8 min=2 max=31 avg=2 OK
…/interceptor_on_enter_performance: DUK min=1 max=2 avg=1 OK

(Numbers are in microseconds, measured on a 4 GHz i7 running OS X 10.11.2.)

Anyway, even if that comparison isn’t entirely fair, as we do some clever recycling and copy-on-write tricks that we don’t yet do in our V8 runtime, this new runtime is already quite impressive. It also allows us to run on really tiny devices, and the performance difference between a roaring JIT-powered monster like V8 and a pure interpreter might not really matter for most users of Frida.

So starting with this release we are also including this brand new runtime in all of our prebuilt binaries so you can try it out and tell us how it works for you. It only adds a few hundred kilobytes of footprint, which is nothing compared to the 6 MB that V8 adds per architecture slice. Please try it out by passing --disable-jit to the CLI tools, or calling session.disable_jit() before the first call to session.create_script().

Considering that this new runtime also solves some issues that would require a lot of work to fix in our JavaScriptCore runtime, like ignoring calls from background threads and avoid poisoning the app’s heap, we decided to get rid of that runtime and switch to this new Duktape-based runtime on OSes where V8 cannot currently run, like on iOS 9. We feature-detect this at runtime, so you still get to use V8 on iOS 8 like before – unless you explicitly --disable-jit as just mentioned.

So in closing, here’s a summary of the changes:

6.1.0:

• core: replace the JavaScriptCore runtime with its successor built on Duktape
• core: add disable_jit() to allow users to try out the new Duktape engine
• core: fix crash on Linux when injecting into processes where pthread_create has never been called/bound yet
• core: add support for linux-armhf (e.g. Raspberry Pi)
• python: add disable_jit() to Session
• node: add disableJit() to Session
• CLI tools: add –disable-jit switch
• frida-repl: upgrade to latest prompt-toolkit
• frida-trace: fix crash when attempting to trace partially resolved imports
• frida-trace: stick to ES5 in the generated handlers for Duktape compatibility

6.1.1:

• core: fix synchronization logic and error-handling bugs in the Duktape runtime

6.1.2:

• core: fix Android regression resulting in crash on inject
• core: fix Python 3.x build regression
• clr: add DisableJit() to Session

Enjoy!

oleavr and karltk presented Frida at the FOSDEM Testing and Automation devroom yesterday.

Slides for our talk—titled Testing interoperability with closed-source software through scriptable diplomacy—are available on our presentations page. No videos of the talk yet.

It’s release o’clock, and this time we’re bringing you massive performance improvements on all platforms, a brand new API for looking up functions, and major stability improvements on iOS 9.

Let’s talk about the latter subject first. Some of you may have noticed weird bugs and deadlocks when using Frida on iOS 9. The root cause was simply that our inline hooking was causing the process to lose the CS_VALID bit of its code-signing status. This was not a problem on iOS 8 and older as jailbreaks were always able to patch the kernel to loosen up on its code-signing requirements. Starting with this release we have implemented some tricks to be able to do inline hooking without breaking the code-signing status. For the technically curious this means that we dynamically generate a .dylib as a temporary file, write out the new versions of the memory pages that we’d like to modify, e.g. the libc memory page containing open(), then pseudo-sign this binary, ask the kernel to F_ADDFILESIGS to it, and finally mmap() from this file on top of the original memory pages.

This brings us to the next topic: performance. The tricks that I just talked about do actually add quite a bit of extra overhead just to hook one single function. It is also a very different approach from what we can do on systems with support for read-write-execute memory-pages and relaxed code-signing requirements, so this obviously meant that major architectural changes were needed. I had also been thinking for a while about being able to apply a whole batch of hooks in one go, allowing us to be more efficient and have more control on exactly when hooks are activated.

Starting with this release, our Interceptor API now supports transactions. Simply call begin_transaction(), hook all the functions, and make them all active in one go by calling end_transaction(). This results in a massive performance boost, and you get all of this for free without any changes to your existing code. This is because we implicitly begin a transaction whenever we’re entering the JavaScript runtime, and end it when we’re leaving it (and just before we send() a message or return from an RPC method). So unless you’re attaching your hooks from timers or asynchronous APIs like Memory.scan(), they will all be batched into a single transaction and get a performance boost.

Here’s how we stack up to CydiaSubstrate in terms of performance:

Note that if you’re using our instrumentation engine from C or C++ you will have to call begin_transaction() and end_transaction() yourself to get this boost, but your code will still work even if you don’t, because every operation will implicitly contain a transaction, and the API allows nesting those calls.

That was function hooking performance, but we didn’t stop there. If you’ve ever used frida-trace to trace Objective-C APIs, or glob for functions across all loaded libraries, you may have noticed that it could take quite a while to resolve all the functions. If you combined this with early instrumentation it could even take so long that we exceeded the system’s launch timeout. All of this has now been optimized, and to give you an idea of the speed-up, a typical Objective-C case that used to take seconds is now completing in a few milliseconds.

Now to the final part of the news. Considering that dynamically discovering functions to hook is such a common use-case, and not just something that frida-trace does, we now have a brand new API for just that:

So in closing, here’s a summary of the changes:

6.2.0:

• core: improve Interceptor to avoid breaking dynamic code-signing on iOS 9
• core: move to a transaction-based Interceptor API for improved performance
• core: fix crash when scheduled callbacks are freed late (V8 and Duktape)
• frida-trace: improve performance by removing setTimeout() logic, allowing many hooks to be applied in the same transaction
• frida-trace: batch log events in 50 ms chunks to improve performance

6.2.1:

• core: add ApiResolver API
• frida-trace: improve performance by using the new ApiResolver API

Enjoy!

It’s been a while since our last major release bump. This time we’re addressing the long-standing issue where 64-bit integers were represented as JavaScript Number values. This meant that values beyond 53 bits were problematic due to the fact that the underlying representation is a double.

The 64-bit types in the Memory, NativeFunction, and NativeCallback APIs are now properly represented by the newly introduced Int64 and UInt64 types, and their APIs are almost identical to NativePointer.

Now let’s cross our fingers that int64/uint64 make it into ES7.

So in closing, here’s a summary of the changes:

7.0.0:

• core: rework handling of 64-bit integers
• core: improve strictness of constructors
• core: improve QNX support
• frida-repl: update the logo

7.0.1:

• core: fix Int64/UInt64 field capacity on 32-bit architectures

7.0.2:

• core: allow Int64 and UInt64 to be passed as-is to all relevant APIs
• core: fix handling of $protocols on ObjC instances

7.0.3:

• core: fix race-condition where listener gets destroyed mid-call
• core: fix handling of nested native exception scopes
• core: improve QNX support
• frida-repl: tweak the startup message

7.0.4:

• core: massively improve the function hooking success-rate on 32-bit ARM
• core: improve the function hooking success-rate on 64-bit ARM
• core: fix the sp value exposed by Interceptor on 32-bit ARM

7.0.5:

• core: spin the main CFRunLoop while waiting for Device#resume() when spawning iOS apps, allowing thread-sensitive early instrumentation to be applied from the main thread

Enjoy!

The Frida co-conspirators have been cracking away on several fronts, so much lately that I figured it was worth jotting this down to get the word out.

In Dalvik land, @marc1006 contributed a really neat new feature – the ability to do object carving, essentially scanning the heap for objects of a certain type. Check this out:

conststrings=[];Dalvik.choose('java.lang.String',{onMatch:function(str){strings.push(str);},onComplete:function(){console.log('Found '+strings.length+' strings!');}});

Meanwhile, @Tyilo has been rocking out adding the same feature for Objective-C:

conststrings=[];ObjC.choose(ObjC.classes.NSString,{onMatch:function(str){strings.push(str);},onComplete:function(){console.log('Found '+strings.length+' strings!');}});

In other mobile news, @pancake added support for enumerating applications on Firefox OS. Sweet!

While all of this was going on, @s1341 has been hard at work stabilizing the QNX port, and it’s reportedly working really well now.

On my end I have been applying Frida to interesting challenges at NowSecure, and ran into quite a few bugs and limitations in the Objective-C integration. There’s now support for overriding methods that deal with struct types passed by value, e.g. -[UIView drawRect:], which means NativeFunction and NativeCallback also support these; so for declaring a struct simply start an array with the fields’ types specified sequentially. You can even nest them. So for the - drawRect: case where a struct is passed by value, and that struct is made out of two other structs, you’d declare it like this:

constf=newNativeFunction(ptr('0x1234'),'void',[[['double','double'],['double','double']]]);

Another thing worth mentioning is that a long-standing issue especially visible when instrumenting 32-bit iOS apps, but affecting all platforms, has finally been fixed.

So let’s run quickly through all the changes:

4.1.8:

• core: add support for enumerating applications on Firefox OS
• core: add NativePointer.toMatchPattern() for use with Memory.scan()
• core: fix QNX injector race condition
• objc: massively improved handling of types
• objc: fix implicit conversion from JS string to NSString
• objc: fix crash during registration of second proxy or unnamed class
• objc: new ObjC.Object properties: $className and $super
• dalvik: add Dalvik.choose() for object carving

4.1.9:

• core: NativeFunction and NativeCallback now support functions passing struct types by value
• core: fix accidental case-sensitivity in Process.getModuleByName()
• dalvik: new object property: $className

4.2.0:

• core: add this.returnAddress to Interceptor’s onEnter and onLeave callbacks
• objc: add ObjC.choose() for object carving

4.2.1:

• core: fix exports enumeration of stripped libraries on QNX
• objc: new ObjC.Object property: $kind, a string that is either instance, class or meta-class
• objc: fix the $class property so it also does the right thing for classes
• objc: fix crash when looking up inexistent method
• python: ensure graceful teardown of the reactor thread
• frida-discover: fix regression
• frida-repl: fix hang when target crashes during evaluation of expression

4.2.2:

• core: fix exception handling weirdness; very visible on ios-arm
• core: QNX stability improvements
• objc: add ObjC.api for direct access to the Objective-C runtime’s API
• objc: new ObjC.Object properties: equals, $superClass and $methods
• objc: fix iOS 7 compatibility
• objc: fix toJSON() of ObjC.classes and ObjC.protocols
• dalvik: fix handling of java.lang.CharSequence
• frida-repl: add %time command for easy profiling

4.2.3:

• core: fix crash when handling exceptions without a message object
• core: fix the life-time of CpuContext JS wrappers
• core: expose the file mapping info to Process.enumerateRanges()
• core: make it possible to coalesce neighboring ranges when enumerating
• core: add convenience API for looking up modules and ranges
• core: make the QNX mprotect read in a loop instead of just the once
• dalvik: avoid crashing the process if a type conversion fails
• dalvik: allow null as call parameter
• objc: fix conversion of structs with simple field types
• objc: speed up implicit string conversion by caching wrapper object

4.2.4:

• objc: fix crash when interacting with not-yet-realized classes

4.2.5:

• core: optimize Interceptor callback logic and make it twice as fast when onEnter and onLeave aren’t both specified
• core: fix return-address seen by the invocation-context on arm64
• core: add a fuzzy backtracer for arm64

4.2.6:

• core: fix access to arguments 4 through 7 on arm64
• core: add Memory.readFloat(), Memory.writeFloat(), Memory.readDouble() and Memory.writeDouble()
• dalvik: improved type checking
• qnx: implement side-stack for calling onEnter()/onLeave() with the stack-hungry V8 engine

4.2.7:

• core: Darwin backend bug-fixes
• core: optimize handling of the send() data payload
• core: add APIs for interacting with the iOS kernel through task_for_pid(0), only available in the attach(pid=0) session
• core: side-stack support for replaced functions on QNX
• objc: add getOwnPropertyNames() to ObjC.classes
• frida-repl: improved completion

4.2.8:

• python: fix Py3k regression

4.2.9:

• objc: add $ownMethods to ObjC.Object
• dalvik: add support for primitive arrays and object arrays
• python: improve compatibility between Python 2 and 3
• frida-repl: better magic commands

4.2.10:

• core: fix Interceptor vector register clobbering issue on arm64
• core: improve temporary directory handling on Android

4.2.11:

• dalvik: add support for accessing instance and static fields
• dalvik: type conversion improvements
• python: resolve python runtime lazily on Mac to allow our binaries to work with multiple Python distributions
• python: pip support

4.2.12:

• python: fix Py3k regressions

That’s all for now. Please help spread the word by sharing this post across the inter-webs. We’re still quite small as an open source project, so word-of-mouth marketing means a lot to us.

Enjoy!

It’s release o’clock, and this time we have a slew of improvements all over the place. In brief:

4.3.0:

• core: add support for getting details about the frontmost application, initially only for iOS
• python: add Device.get_frontmost_application()
• node: add Device.getFrontmostApplication()

4.3.1:

• core: add support for relocating PC-relative CBZ on arm64
• frida-repl: fix crash and loading of script on Py3k

4.3.2:

• core: add support for launching an iOS app with a URL
• dalvik: fix bug in field caching
• frida-trace: color and indent events based on thread ID and depth
• frida-ps: fix application listing on Py3k

4.3.3:

• core: re-enable the Darwin mapper after accidentally disabling it

4.3.4:

• core: gracefully handle attempts to replace functions
• core: throw an exception when Interceptor’s attach() and replace() fail
• core: fix clean-up of agent sessions
• core: fix assertion logging and log to CFLog on Darwin
• dalvik: add Dalvik.synchronized(), Dalvik.scheduleOnMainThread() and Dalvik.isMainThread()
• dalvik: port Dalvik.androidVersion and Dalvik.choose() to Android 4.2.2
• python: fix the PyPI download URL for windows-i386
• frida-trace: handle attach() failures gracefully

4.3.5:

• frida-server: better resource tracking

4.3.6:

• core: fix for arm64 function hooking
• dalvik: fix for Dalvik.enumerateLoadedClasses()

4.3.7:

• objc: add ObjC.Block for implementing and interacting with blocks

Enjoy!