Intrepidus Group

Author Archives: jeremy.allen

Scorched Earth — How to REALLY Disable Certificate Verification on iOS

Posted: January 25, 2013 – 1:18 pm | Author: | Filed under: Uncategorized

Some days, you are just going about your life, happily reversing and tearing apart software, which developers spent hundreds of hours to build, when certificate pinning happens. Certificate pinning, in my opinion, is generally a good thing. It just isn’t good when I want to MiTM your traffic. I am used to my easy life of installing a CA certificate or two from my tools, such as Mallory and Burp, and going about my business.

I caught some MiTM failing in my most recent assessment and thought to myself, no problem. I will go grab ios-ssl-kill-switch, and everything will be ok, even with this application’s certificate pinning. Alas, this is where our tale takes a turn for the dark and unseemly. This application was not using NSURLConnection, which ios-ssl-kill-switch knows how to defeat. Using some data gathered from the logs, and my knowledge of iOS security guts, I identified one function SecTrustEvaluate, that I thought was responsible for all of the certificate trust decisions in my application. I spent some time in IDA, verifying these assumptions. I was reasonably convinced that hooking SecTrustEvaluate would solve my problem.  As it turns out, SecTrustEvaluate is used, well, everywhere in OS X and iOS. most Apple components that verify a certificate chain rely on this function as the entry point to the code that verifies the certificate chain.

Happily, SecTrustEvaluate is a simple C function that returns a simple integer result and modifies the value of one pointer. I thought, I can write a MUCH better version of SecTrustEvaluate!

Enter MobileSubstrate. MobileSubstrate is installed along with Cydia. MobileSubstrate, using DYLD_INSERT_LIBRARIES (which is like LD_PRELOAD), allows you to use a couple of handy functions to hook virtually any C function or Objective-C method in applications on an iOS device. MobileSubstrate requires a simple dynamic library with a few bits of the right code. These libraries are often called, “Tweaks”, as they originally focused on SpringBoard, the equivalent of the Explorer shell in windows. However, it is a general purpose function and message hooking facility that works system wide.

I decided to name my Tweak trustme. You can visit our Github project for more details on its construction, downloads, and to see how it works under the hood. The code is quite small. The result is quite big. I patterned the project on ios-ssl-kill-switch. The tweak disables virtually all certificate chain checking. I successfully tested Facebook, MobileSafari and a few other apps with full MiTM running. I tested in transparent mode Burp and Mallory successfully. The beauty of hooking SecTrustEvalaute is that it usually much deeper and ultimately used to resolve most trust decisions on iOS.

Jan 25 09:18:19 HackPhone4 MobileSafari[760]: MS:Notice: Loading: /Library/MobileSubstrate/DynamicLibraries/trustme.dylib
Jan 25 09:18:19 HackPhone4 MobileSafari[760]: trustme: Loaded
Jan 25 09:18:19 HackPhone4 MobileSafari[760]: trustme: Hooking SecTrustEvaluate

tl;dr — Wrote a MobileSubstrate tweak that hooks SecTrustEvaluate and disables certificate checking almost everywhere. Download trustme via our Github page. 

If you have any suggestions for other calls that might belong in trustme, let us know!



Comments disabled

Windows Phone 8 and Windows 8 Similarity

Posted: December 15, 2012 – 9:42 am | Author: | Filed under: Uncategorized

Here at Intrepidus Group we wanted to understand WP8 (Windows Phone 8) under the hood, and just how similar WP8 and Windows 8 are. As we gear up for Windows 8 and WP8 assessments, having this knowledge will allow us to make smarter decisions on our assessments. More developers are focusing on the platform, and the carriers will be releasing a variety of WP8 devices in the near future.

We wanted to devise a way to compare some of the core OS components of the two operating systems. WP8 is migrating from the WinCE kernel to the WinNT kernel. The question for us was, “How similar are the two operating systems, then?”

There are not many WP8 devices available at the time this blog post was written. There are no known “root” or “jailbreak” style tools for the few WP8 devices that are available, so we decided to turn to Windows 8 (x86) and WP8 (x86). Ultimately, we would like to compare Windows RT binaries with WP8 (ARM), but we felt our solution was good enough to draw some conclusions.

We mounted the WP8 emulator image, from the Windows Phone 8 SDK, and extracted ntdll.dll and ntoskrnl.exe. The emulator executed regular x86 code, making the comparison between Windows 8 and WP8 easy. These two files are the kernel and user side of the same coin. Much of the Native Windows API uses ntdll to implement its functionality (note that ntdll is a private library with no documented API). Chris Valasek, along with Tarjei Mandt, have done a great job analyzing some of the internals for these two components, which makes them ideal candidates for a comparison. We let IDA analyze them, and then we fired up BinDiff, by Zynamics (which was acquired by Google), and compared our IDA databases for the two files.


With similarity scores of 99.1% for ntdll.dll, and 99.5% for ntoskrnl.exe, it seems safe to assume that the two operating systems are dramatically similar to one another. Our WP8 emulator image binaries are newer than the Windows 8 binaries, which means some of the deltas could be due to updated code. The key differences, then, will be in higher level components and APIs and how they are implemented. The real conjecture on our part is this: that WP8 for ARM is similar enough, or very close to the same barring ARM platform required code deltas, that we can call this WP8 Emulator to Windows 8 comparison valid. If this is true, and we think it is, then we can say the two share much of their common kernel code and core OS components.

This similarity means that common drivers may also be shared between Windows RT, Windows 8 and WP8. This also means that bugs will be shared between these platforms for the first time. Windows Phone 7 (WP7), implemented using a WinCE kernel, did not have to worry about Windows 7 bugs. What this means for the future of bug discovery and exploitation on Microsoft mobile devices is not clear at this point, but we are guessing it will make the number of bugs discovered for the platforms higher (at least). Much will come down to how effective many of the safeguards in Windows 8 and WP8 are at making exploitation more difficult.


Happy Friday,

Please enjoy this old, but funny, IG post about PCI jokes



Comments disabled

Friday Double Feature – Free Rides and WebCrypto

Posted: September 21, 2012 – 12:40 pm | Author: | Filed under: Uncategorized

This article will cover not one, but two topics!

 NFC For Free Rides and Rooms (on your phone) 

First up is a quick review of the research Corey Benninger and Max Sobell presented in Amsterdam this week. Corey and Max have spent considerable time hacking on NFC related topics. This time, they discovered a flaw in the way many municipalities implement “disposable” fare cards. In many cases there is no central authentication or tracking and the tags are read, and can be written to, via NFC. This allows Max and Corey to overwrite the section of the card that tracks how many rides are left. This is accomplished via their UltraReset Android application. One misconception that should be cleared up is that this is an NFC problem. The Android application was just a convenient method of accessing the data on the fare cards via NFC.

You can see the app in action over at Vimeo.  The relevant coverage can be found at the following places:

WebCrypto first working draft released

The first working draft of the WebCrypto API has been released. Much has been written about cryptography, cryptography for pen testers, cryptography for developers, crypto for everone! Crypto, crypto, crypto. It is a fascinating topic and a required part of having a more safe digital world. Nothing gets a crypto geeks blood’ pumping like a new spec that focuses on crypto. This week there has been quite a bit of discussion about WebCrypto and its API. It is pretty new and is going to need some very careful consideration, but it is my estimation that WebCrypto is not off to a great start. Many of our customers out there writing applications in HTML 5 are going to rely on this API and it does not solve many of the fundamental problems they will face in utilizing cryptography. The WebCrypto API is really only half of the story for most developers, and it really needs to be a complete picture.

My main complaint, aside from some broken and already known to be flawed algorithms and crypto primitives sneaking into the API, is that this API only provides primitives. If you sit a group of developers down and ask them to implement cryptography securely using a library with nothing but primitives such as “AES-128-CBC” and “ECDSA”, chances are very good that you will end up with trivial and not so trivial flaws in the implementation the first go around. Just convincing everyone that authentication is as important as confidentiality can be a real challenge (Hello Padding Oracle!). As a long time software developer I look for APIs that expose just the “tip” of the iceberg in terms of functionality. A truly beautiful API only exposes as much as it needs to and hides the rest. Never is there a time where experienced designers should be hiding details than in a crypto library. For the vast majority of crypto code I have seen, if there was a much simpler API that abstracted out a lot of the common pitfalls and got rid of the insecure and flawed modes and algorithms, my crypto reviews would have been a lot less interesting. Developers need functions that are simple and safe, by default: encrypt(some_data), decrypt(some_data), verify(some_data), sign(some_data). It needs to be almost that simple!

Developers are not (typically) cryptography practitioners, and should not have to make algorithm and primitive choices. Instead when I look at the standard, I see a bunch of primitives! For some examples of APIs done right, check out Bernstein’s NaCl or the Windows Data Protection API (DPAPI). Nate Lawson has also written on this topic, you could take his blog post and the same arguments apply.Even these APIs are too low level for my taste, but it is far better than thrusting a bunch of crypto primitives at developers. And my final problem is that many development teams *will* abstract WebCrypto, and they will do it using JavaScript, which puts us right back in the mess of having to deal with sensitive crypto code written in a language and runtime that is not trustworthy. So really, what are we accomplishing here? DRM for Netflix (via @tqbf)?

That said, this API is a nice set of primitives and it does include some practical things like PBKDF2 (Password Based Key Derivation Function 2), which will be really useful for the applications that need it. Explaining to everyone what PBKDF2 is, and why they should be using it to derive an encryption key is a task in and of itself. Enough of my soapbox. I will review this spec in more detail and give more constructive thoughts in the future. Thanks to @DarthNull and @tqbf for rousing me enough to write this post. WebCrypto has been on my mind, I know it will be creeping into our application work for years to come. Let this blog post serve as a point of reference for when we start seeing real apps using WebCrypto.


Java Reflection in Android…FTW

Posted: April 13, 2012 – 11:57 am | Author: and | Filed under: android, Conferences, Mobile Security, NFC, Reverse Engineering, RFID, Tools

I’ll be hitting a few smaller security conferences this spring (whatup BeaCon and BSidesROC) with a turbo talk on how Java reflection can be useful for accessing hidden APIs in Android. The team at Gibraltar had some great posts on this last year, but getting reflection to work for accessing the NfcAdapterExtras and NfcExecutionEnvironment classes was not as straight forward as things seemed. Here’s some tips on how to get it working (at least on an Gingerbread Nexus S).

First, you want to get familiar with the nfc_extras framework. This is not included in the standard Android SDK, but you can either pull the /system/framework/ file from a device or look at the Android source. You’ll see there are two classes: NfcAdapterExtras and NfcExecutionEnvironment. What I really wanted was in the embedded NfcExecutionEnvironment, but the proper way to get that object is from NfcAdapterExtras.getEmbeddedExecutionEnvironment(). So we’ll need to create that object and method first.

I decided to use reflection to access these classes in my own Android application. Since they’re not in the SDK, I couldn’t just “include android.nfc_extras.NFCAdapterExtras” in my code. Instead, we’ll just ask for that class by name at runtime.

String sReflectedClassName = "";
Class cReflectedNFCExtras = Class.forName(sReflectedClassName);

Wow, that’s pretty easy. Except that we’re going to need to tell the Dalvik VM to load that additional nfc_extras framework so that it knows about that class. To do that, add the following after your application tag in the AndroidManifest.XML file of your application.

<uses-library android:name=”” android:required=”true” />

Now back to our “cReflectedNFCExtras” class. The first thing we’ll need to do is get the singleton NfcAdapterExtras. This is returned by the get(NfcAdapter paramNfcAdapter) method. Note that it takes an NfcAdpater as a parameter, so we have to specify the class for that when looking for this method. The following line should work for that.

Method mReflectedGet = cReflectedNFCExtras.getMethod("get", Class.forName("android.nfc.NfcAdapter"));

However, at first I had mistake in my code that cause this method not to be found (thank Jeremy for fixing this). So instead, I had looped through all the methods using getDeclaredMethods() and stopped when the “get” method we want was found. Here’s the code for doing that followed by invoking the method and passing it the default NFCAdapter which would be the next thing we’d want to do.

Object oReturnedNFCExtras = null;
Method mReflectedMethods[] = cReflectedNFCExtras.getDeclaredMethods();
for (int i = 0; i < mReflectedMethods.length; i++){
   Log.d("NfcAdapterExtras METHOD:", mReflectedMethods[i].getName());
      //Standard default NFCAdapter... need to pass this in to get back the singleton
      NfcAdapter defaultAdapter = NfcAdapter.getDefaultAdapter(this);
      oReturnedNFCExtras = mReflectedMethods[i].invoke(cReflectedNFCExtras, defaultAdapter);

From here out, it’s smooth sailing as long as you take care of one more thing. Your application needs a special premission in order to use this framework, the one for “NFCEE_ADMIN“. The problem is this premission is declared with the protectionLevel of “signature” in the package. There’s a few ways to get around this, but as far as I know, they’ll all require that you have root on the device. Thus, even though we’re using reflection to access these classes, Android’s permissions are still enforced. My way of dealing with this was to resign the package with the same certificate I used to sign my newly created Android application, then adding the following line to my application’s AndroidManifest.xml

<uses-permission android:name=”” />

So there you go. We can now be NFCEE_ADMIN’s as well (on our own rooted devices) using reflection. I’m curious to try this out with other /system/framework packages as well. In most cases, the process should be more straight forward:

  1. Create a class using Class.forName(“package.class”)
  2. Find the method using  getClass().getMethod(“method”, paramTypes)
  3. Then invoke the method with the proper parameters


1 comment

How to respond to spam…

Posted: February 17, 2012 – 3:57 pm | Author: | Filed under: Uncategorized

This is a bit different from our usual blog content. When I need a break, I take a moment and do a bit of creative writing. This writing typically surfaces as a creative response to some targeted spam. This is one of those responses:

Please keep in mind I wrote this tongue in cheek and I don’t really feel this way about developers.


Hi Jeremy,


I’ve came across your company’s profile on LinkedIn and thought that you might be interested in hiring mobile software developers.

We have an Android developer available which is supposed to work remotely under your managerial control from our office in Ukraine.

Our company finds, employs and supports client’s own software development teams, which work under the client’s 100 % managerial control from our office.  Companies from the Netherlands, Norway, Germany, Belgium, Denmark and the USA already have their teams in our office (references on demand).

Is this something that might interest you?

P.S. PHP, C++, Microsoft .Net developers are available for hire (CVs are available).


Dear Jane,


My organization is involved with mobile security in very special way. We are, what you would call, ‘White hat hackers’. What this means is that we work with organizations that develop mobile applications. Mobile applications are new, but they are not terribly hard to develop. So I will now tell you a story.

This is a story about Joe. And he is a different kind of hacker from the typical Intrepidus Group hacker. He is a hacker in the more traditional sense of “one who hacks” or someone that writes code. Joe is an overworked developer at a large insurance company.

Joe was sitting at his desk waiting for his latest bug fixed to be reviewed by the QA team. Joe checked the clock in his computer task menu. Only 3:45, and already, he was falling asleep. He knew it was going to be tough to finish the day. There were a couple more blocking issues on his application that he knew had to be fixed before it could be released. He performed a quick mental calculus on the level of effort to fix those remaining bugs. He knew his manager would not be happy, he estimated over two days to fix the remaining bugs.

He got a little hot under the collar just thinking about the deadline, which was passed a week ago. His manager was under pressure to release the new mobile application. The executive management team was keen on “engaging” their customers in a mobile fashion. Joe had once worked with Objective-C and when the discussion of the insurance company’s mobile application came up; Joe figured he would get a chance to do some cool work. He dumbly volunteered to be an iOS developer.  His life was never quite the same since that moment. He has been straining to learn the framework and finish the application on time. He had to constantly fight feature creep and outlandish expectations about what a mobile application could do. The executive management team seemed to be under the impression that the heavens would shine down upon their mobile applications and that the damn thing would just fart rainbows and solve the company’s problems.

Joe ruminated on this a bit longer. 4:00PM. He pecked away at his keyboard slowly to appear productive. His mind was racing. He couldn’t wait to get home and see the latest episode of Jersey Shore. He reviewed his bug list one last time. He realized there were several security issues in the list. He changed their priority to low and justified this with the explanation that mobile applications were inherently insecure and unimportant so it would be silly to spend time working on security bugs.

Joe took a break and headed to the restroom. He knew he could kill ten minutes this way. He finished his business up and checked his complexion in the mirror. Damn, Joe thought, the male pattern balding was getting worse. His wife’s constant nagging was finally getting to him. He would have to go visit a hair loss center. He did not want to admit it, but a lot of his identity was tied up in vain things, such as his looks. He was legitimately afraid his wife might not love him as much if he didn’t lose a bit of weight and fix this hair condition. Maybe getting a Camaro SS, one of those new ones with 500 horse power, would make his wife think twice. Joe sighed and headed back to his desk. This was going to be a long 50 minutes. Eventually the time passed and he meekly filed out with everyone else. He hopped into his aging Toyota Corolla and battled it out for an hour with all the other poor citizens in the strangling traffic Utopia.



Developers like Joe are what keep us employed. They don’t care about security more than they have to.




1 comment

Google Wallet PIN Brute Forcing

Posted: February 9, 2012 – 10:46 am | Author: , and | Filed under: android, Mobile Security, NFC, Tools

Google Wallet is a project of great interest right now as it is a big shift in how we pay for goods and services in the US (Japan is quite far ahead of everyone on mobile payments). Some researchers have discovered that Google Wallet is storing the PIN for your wallet on the device in a relatively insecure format. Since this information was already released into the wild, we felt we should share our perspective and how we would approach this problem. The PIN data is stored in the application’s SQLite database.

The SQLite database is stored in the Google Wallet data directory. Google wallet stores the pin in the proto column of the metadata table. The data is encoded using the protobuf format (also by Google). The following SQL query retrieves the data:

select hex(proto) from metadata where id = "deviceInfo";

This query retrieves the protobuf data encoding a number of device and user specific information. Protobuf is a data serialization format, similar to JSON in concept. Next the data must be deserialized. The standard way to work with protobuf data is to define a .proto file, which acts as a key for deserialization. These .proto files get compiled down to application specific code and are not in their native human readable format. Raj decided to start to write a generic protobuf decoder (Protobuf Easy Decode) . This Python module can decode protobuf data without a .proto file. Some data is inevitably lost when reading raw protobuf data without a .proto file.

Recovering the PIN with the decoded data required some understanding of the specific .proto structure. Once the salt and the hash of the salted pin retrieved, brute forcing the PIN is a trivial matter: illustrates how to brute force the PIN.


@0xd1ab10 and @0xb3nn

1 comment

Excuse me, your clouds are leaking

Posted: January 18, 2012 – 10:31 am | Author: , and | Filed under: Articles

I recently started playing around with Gliffy, a nice online diagramming tool that has become quite popular. Gliffy makes sharing your diagrams with the world easy. Unfortunately, many Gliffy users do not realize that they are sharing their diagrams with the entire world. Some quick Google searches revealed a number of entertaining diagrams.

This data ranges from boring to concerning. I held back a few that I felt were not responsible to disclose. At any rate, this highlights the dangers of using “cloud services” and not educating employees about the inherent risks this involves. Also, some of this is just plain laziness from those who probably know better.

After assuring Google I was indeed a human about a dozen times, here are the highlights:

Also, SOPA and PIPA are bad. Please let your representatives know. See: for a nice write up.

@bitexploder, @sorcerer13 and @rossja




OWASP ATL: Mobile Application Assessment Presentation

Posted: November 29, 2011 – 4:04 pm | Author: | Filed under: iOS, Mallory, Mobile Security, OWASP, software security, ssl

I recently gave a presentation at OWASP ATL on the OWASP Mobile Top 10 and how to assess mobile applications. This was a light weight discussion of the OWASP Mobile Top 10 and some topical and technical concerns related to securing mobile applications.

Download the presentation here: [download id="276"]


These videos show various testing techniques on real applications. The applications targeted didn’t have any serious problems. In the case of the game, “WordFeud”, a Scrabble clone, the game maintained game state on the server and tampering with client side values did not yield any interesting results. The SoundCloud demonstration shows how it uses the iOS data protection API to avoid storing OAuth tokens in the applications file sandbox and instead uses KeyChain.

Video Demo Series Here:



iOS Application MiTM


Sound Cloud and Data Protection




Comments disabled

Protect your Apple Developer Certificates

Posted: October 11, 2011 – 5:21 pm | Author: | Filed under: iOS

A discussion of Apple Developer certificates came up. The conversation was focused on how a third party developer wanted access to an organizations certificate so they could build the application for the organization and (potentially) publish it to the Apple App Store. The developer’s request did not surprise me, but it did surprise a couple of people at our lunch table.

As a policy, third parties should never be granted access to your Apple Developer certs. Anyone that has that cert and private key can publish applications as your organization. This has huge implications. Please, don’t let anyone outside of your organization have access to your certs. In fact, don’t let more than a few people in a tightly controlled environment have access to them. If you deal with SOX and any sort of separation of duties you are probably familiar with separating developers from production. You may not be aware that having access to that Apple developer cert (issued to your organization as a whole) lets the possessor publish applications as you. If you have a third party developer, tell them no when they ask for access to your certs and handle it in house.

I also recommend any org building iOS apps create build environment and only publish binaries they build themselves to the app store. The best secure SDLC and developers in the world can be undermined by this one operational security mistake. Guard your developer certs very closely. A third party developer can slip in malicious code. A third party developer may not have the same security practices and constraints as you. The list goes on. The idea is simple: protect your Apple dev certs like a nuclear launch code.

Here are bad code signing things that have happened:


Note: Reader Karl observes that you can still have separation of duties from developers by not giving them the iTunes connect credentials required to upload to the store. Karl is likely correct on this point. It is certainly not quite as easy as I made it out to be getting things into the App Store with just a code signing cert.

Be wary though, production code signing certificates should likely be kept out of most development environments, as there are still risks with Ad-Hoc application publication and many other abilities Apple dev certs enable that should not be granted to a development team carte blanche.



Intrepidus hosting a Convergence notary

Posted: October 10, 2011 – 9:55 am | Author: and | Filed under: Privacy, ssl

Suffice to say, the Certificate Authority trust model seems to be fundamentally broken, and with increasing attention paid to it from numerous angles, it’s likely to need a massive overhaul before getting any better. However, there are efforts underway to change the way we think about trust in this capacity. Moxie Marlinspike, known for his contributions to (breaking) SSL and the CA system (among other things), recently developed an alternative to the traditional CA trust model. The project, called Convergence, pairs a Firefox add-on with a set of server-side components to help validate the authenticity and trustworthiness of a particular SSL-enabled site.

Although Moxie’s blog post (that led up to Convergence) and the video of his talk at BlackHat USA 2011 explain the rationale a bit more, the concept is simple: you visit a (SSL-enabled) site, let’s say, and the Convergence add-on sees a certificate with a fingerprint FOO. The add-on asks a set of Convergence “Notary servers” what they see. If they see FOO, you can reason that‘s cert is legit. If one or more of the notaries sees something that isn’t cert fingerprint FOO, something’s probably rotten (such as man-in-the-middling of your connection, or a notary’s connection, or some other network nastiness). Most importantly, you decide which notaries you want to trust, rather than relying on a browser-vendor defined list of Certificate Authorities. Convergence also attempts to anonymize inquiries to notaries so as to minimize the likelihood of a notary getting a bit too privy to your browsing habits.

Per the Convergence site, the installation process for the add-on is fairly straightforward: run Firefox, visit, click “Download”. After that, add any notaries you wish to trust — two Thoughtcrime notaries are enabled by default, and there’s an ever-growing list of additional notaries on the project’s Github wiki. As this project caught our eye, Intrepidus Group decided to spin up a notary server of our own, which can be added by loading our notary file (if you have Convergence installed, you can simply browse to “.notary” files/links to add the associated notary info).

And Intrepidus isn’t the only company to get on the Convergence notary server train. Late last month, Qualys announced their support of the project, as well as spinning up two notaries. We certainly hope to see more of this type of backing in the near future, and encourage others to run their own notaries as well.

Comments disabled


This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 24447 items have been purified.