Intrepidus Group

Author Archives: benn

APKTool, make me a logcat sandwich

Posted: March 8, 2013 – 2:57 pm | Author: | Filed under: android, Mobile Device Management, Mobile Security, Reverse Engineering, Tools

I recently turned a few friends on to Zed Shaw’s “learn python the hard way” course and it reminded me how bad of a programmer I can be. In fact, I’m that guy how litters his code with print statements. So it’s probably no shock then that a lot of times when I’m trying to figure out what’s going on in an Android app we’re reversing, that I’ll want to drop in some print statements. I use to do this by adding a few lines of smali directly into a class file, but there were a few things I needed to deal with for that to work how I wanted it. For example, here is what the default “debug” log call looks like in smali.
invoke-static {v0, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I
If you were going to drop this line into the code somewhere, you would need to make sure both v0 and v1 are Strings. I would typically want “v1″ to be the string I wanted logged out, and “v0″ (in this example) to be the log “Tag” value so I knew where I was in the code when it was dumped to the log (I may have a dozen or so values getting logged out, so this helps to keep things straight when you see them in the logs). Setting up this Tag string and not stomping on things sometimes meant I needed to increase the local variable count and add some more lines for setting the string and then making sure I got the register/variables correct in that previous logging line. This worked alright if it wasn’t too late in the night or I had enough caffeine in me, but I typically would screw something up and would end up recompiling a bunch of times. I wanted an easier way and something that could deal with logging out things that weren’t already strings.

Thus I created this simple class file I can drop into the root of any application (yes, this is not as good as a real debugger using JDWP, but sometimes doing things quick and dirty gets the job done quicker for me). I wanted to stay with Android log utility syntax, but simplified a few things. I overloaded the logging object’s “d” method so that it could take just about any variable type I was dealing with. One handy example of this is a byte arrays (which is often what we find decryption keys stored in). The wrapper in IGLogger will convert the byte array into a hex string and dump that to the logs. All you need to add is one statement to the code. If “v0″ contained a byte array we wanted printed out, just drop this line of code.
invoke-static {v0}, Liglogger;->d([B)I
Since “iglogger.smali” is in the root of the recompiled APK, we can statically invoke it from any other class in the project. In this case, we need to tell the “d” method v0 is a byte array “[B” and sticking with the standard Android logging utility class, we’re returning an Integer (although I’ve thought about just making that a Void… I never check it). You may notice we’re not passing a log Tag variable with this statement. IGLogger supports that if you want, but we’ve added a trick to IGLogger that I find works pretty well. In IGLogger, we’ll create a new Throwable object, get the getStackTrace method to find out the last class and method we were in, and put that in our log Tag. If the APK is not obfuscated, this will even include a line number. This same trick allows for a very simple “hey, I got here and this is how” stack trace method to be dumped by placing this one line of code anywhere.
invoke-static {}, Liglogger;->d()I
You might have heard a lot of us here are fans of Virtuous Ten Studio for working with smali. I have a bunch of these IGLogger print statements in  Extras->Smali->CodeSnippets. Makes it really simple to just click and drop in a log statement.

But that wasn’t good enough for Niko here when we had a massively huge app that was obfuscated. He talked me into automating the process of logging out each class and method that was entered so we could watch the logs and know what code paths were being taken. I ended up rolling this into a Python script I had written to “fix strings” in decompiled Android apps. You are probably aware that proper Android apps will have their strings placed into XML files so that it’s easier to internationalize the application. While this might be nice for developers, it means when we’re reversing an application, we may end up with some strange hex value instead of a readable string. “” would loop through the decompiled code and add these strings back in as a comment tag when ever they showed up in the smali code. Your mileage may vary with how well this works, but in some apps, it helped us find things easier.

Adding on to that code base, I started to include some code to automatically add IGLogger statements around things I thought could be interesting. This includes a log statement after the “prologue” of any method. Also, any time we see two strings being compared, we’ll log both strings (this is always fun for watching a password being checked or when the app pulls up device info to see if it’s running on the right hardware). We plan to add a few more things for dumping Intent messages and URLs, but this is a start for now.

This of course will make the app run hella slow, fill up logcat, and in some cases break the application. I’ve tried to avoid that last one as best I can for now, but it is possible this script will massacre an APK so badly it will be unrunnable. If you run into that issue, you can turn off the lines that will add these automatic logging statements to the code (ie, JonestownThisAPK = False).

The last thing we added to the Python script was some searches to pull out info we may find interesting when assessing an APK file. We dump this into a file called “apk-ig-info.txt” and review it after decompiling the APK. Again, this is something we’re continuing to refine. You can find the code on the Intrepidus Group github repo:


Comments disabled

Unlocking NFC deadbolts with Androids

Posted: September 26, 2012 – 6:42 pm | Author: | Filed under: android, Conferences, Mobile Security, NFC, RFID

Program the EZon NFC lock to work with your Nexus

At Shmoocon  this last year, there was a vendor who caught my eye with the Samsung SHS-3121 Digital Keypad Keyless Deadbolt “EZon” Lock. They endorsed the lock for the unique digital keypad, which randomly displays two extra digits that must entered before pressing the actual unlock code. A fairly nice way to ensure extra smudge prints on the keypad and even wearing. What got my attention though was the NFC cards which could also be used to unlock the deadbolt. At Shmoocon, I scanned the sample card with my Galaxy Nexus and realized it was a Mifare Classic card… with no protected sectors or data on it (not that it would have mattered too much since the Mifare Classic encryption can be fairly easily broken at this point). We ordered one for the office to play with even though there were some warnings that the RFID side of things might not have the best security.

I don’t want to turn this into a full product review (or video overview), but I’ll just focus on the NFC side of things. The lock ships with 5 branded “Access Cards” which are Mifare Classics. The lock only appears to be checking the 4 byte UID of the card and if the UID has been previously registered with the lock, it allows access. The UID is like a unique serial number for each card and should be impossible to change after the card is manufactured. None of the cards that are shipped with the lock  are pre-registered, thus they must be manually added for access.

One thought of attack would be to similar to the HID card enumeration attacks (where if you know the ID from one card, it makes it pretty easy to find other values). Scanning the cards that were sent with the lock, the UIDs are not within close numerical range although some parts a similar (the UIDs were: 3e8700b1, be37feb0, eed2ffb0, fe2701b1, and… oops, I lost the last card). Additionally, the lock ships with brute-force detection enabled, which is refereed to as “prank” detection in the manual. Scan five invalid NFC cards in a row, the lock sounds an alarm and requires an administrator to unlock the device (or the door to be unlocked form the inside). Thumbs up for shipping with brute-force protection turned on by default. Unfortunately, we also noticed there’s a reset button hidden on the outside of the lock, so bring a paper clip and reset it after four attempts to avoid triggering the brute-force alarm and time-out.

That said, brute-forcing UIDs right now is a bit complicated. We haven’t seen a way to do this directly on a mobile device yet. A great whitepaper (PDF) on the current state of things was done by Michael Roland a few months ago. So while we can’t do this directly on our devices yet, we were able to purchase a knock-off “Mifare Classic” card from a contact in China which allows us to set the UID on a physical card using a non-standard command. At EUSecWest 2012, Max and I demonstrated using a Nexus S to read the UID off someone’s access card, then program onto this KIRF card in order to unlock the EZon.

So if you use one of these locks, you might want to keep your card in a shield when it’s not needed. However, you could also enroll your mobile phone to be your access key. This would then allow you to control when your card is active and when it is not. If you have an Android device that supports Google Wallet, you’re all set. The trick is to have Google Wallet installed with at least one “Loyalty Card” setup in the wallet, then make sure the card is enabled. Doing this enables NFC card emulation on your device which will present a UID to the EZon when it is within range. This type of card emulation is different from your payment information (so you don’t have to worry about the lock charging your bank account each time you unlock it). You can then enroll your phone just like a physical access card to the EZon and use your phone to unlock the device. The added benefit is that when your phone’s screen is turned off, card emulation is off as well which makes things a lot harder to tap and then clone.


Comments disabled

UltraReset – Bypassing NFC access control with your smartphone

Posted: September 21, 2012 – 8:24 pm | Author: and | Filed under: android, bugs, Conferences, Mobile Security, NFC, RFID, Tools

We were just in Amsterdam to present our research on uses of NFC for physical access control. The two main industries we focused on were transit and hotel systems. Ever since Intrepidus got us Nexus S phones with NFC early last year, we’ve been looking for real world uses of NFC on our trips. We discovered the flaw with the SF Muni Ultralight cards last year on a trip there and followed up with informing them of the issue in December. At the time, we had to take the cards home and use an NFC reader connected to a laptop to do testing. Since then, things have changed; the Android API supports reading from and writing to most Mifare NFC cards, Ultralights included.

Some of the coverage of this has confused all NFC transit systems with those using the Mifare Ultralight cards incorrectly. In our presentation, we listed several cities that we know have NFC transit systems as an example of how widespread the technology is becoming. We listed two cities using Mifare Ultralight cards incorrectly that we have 1) tested and 2) contacted with remediation details.

For those of you that missed the video, we have it posted here:

UltraReset Screenshot

UltraReset resetting an Ultralight transit card

This was a NJ Path 10 trip Ultralight card in the video. When we tap the card to the phone, our application reads all the data in pages 4 to 15 from the card and stores the data to the phone (we also store the card’s UID which we’ll write about more next week on hotel card issues). We then tap the card between two turn styles (which is why the count jumps by two). Once the 10 trips on card have been used up, touching it back to the phone causes the application to write the data back to the card. And with that, the card looks to be back in its original state when it was purchased with 10 rides remaining.

While these Ultralight cards don’t have access control features which are found in more expensive NFC cards, they do support a feature called a “One Way Counter” (which was named One Time Programmable or “OTP” in previous documents). These bits are in page 3 of the card’s data and once a bit is turned on, it can never be turned back off. This way, a card could be limited to being used only a limited number of times. These bits are left unchanged by the two transit systems we looked at which used Ultralight cards.

Ultralight Card OTP values

The one way counter (OTP) values of of the NJ Path card (top) and SF Muni (bottom). Neither system changes these bits when the card is used.

We know a number of cities are looking to roll out contactless technology and hope we can bring light to this issue so that it is implemented correctly in the future. One of the items we also raised in our talk is that full card emulation on smartphones is likely to happen soon. When this does, it could cause a number of NFC based access control  systems to be re-evaluated.

If you think your system might be vulnerable to this issue, we have put an Android application in the Play store which will read and compare the one way counter (“OTP”) on Ultralight cards. Note, the standard cards that you might get from transit systems typically are not Ultralights. Ultralights are typically only used for  “disposable” or “limited use” type tickets.

We have been reading lots of insightful comments on the articles we’ve seen. Please feel free to post questions or comments here and we will do our best to answer them (and no, we’re not planning to release the full UltraReset application). Last but not least, we would like to thank dragos and crew for having us at another one of the SecWest events — it’s always a great to catch up with folks in the industry and hear talks in the single track format. Thanks!

~Corey and Max

Comments disabled

Android’s BuildConfig.DEBUG

Posted: July 15, 2012 – 9:55 pm | Author: | Filed under: android, Mobile Security, Reverse Engineering, software security

Verbose logging in Android applications is both a problem we frequently see in production builds, as well as something we’ll try to enable if we’re pentesting an app. In revision 17 of Android’s SDK Tools and ADT, the release notes mentioned a feature which could help developers with this issue:

Added a feature that allows you to run some code only in debug mode. Builds now generate a class called BuildConfig containing a DEBUG constant that is automatically set according to your build type. You can check the (BuildConfig.DEBUG) constant in your code to run debug-only functions such as outputting debug logs.

There appeared to be a few bugs in this working as expected in the original releases (Issue 297940), but that appears to have been worked out now. Running a few tests with revision 20, here’s an example of how it could be used and what it looks like in a built APK.

In our java code for our sample application, we included the following line:

 Log.e("HelloJB", "I am in the Debug");
 Log.e("HelloJB", "I am NOT Debug");
Log.d("HelloJB", "Debug value is: " + BuildConfig.DEBUG);

We then cleaned, built, then exported our application as a signed package from Eclipse. As expected, logcat showed “I am NOT Debug” and “Debug value is: false”. However, decompiling the application using Dex2Jar showed that these values had been set at build time and not simply at execution. With the new update, the Dex2Jar output for those several lines was now just two:

Log.e("HelloJB", "I am NOT Debug");
Log.d("HelloJB", "Debug value is: false");

This looks like a pretty clean way to strip out any code you don’t want making it into your release builds (an issue we’ve seen many times in assessments).

Now for pentesters of Android applications, we often look to enable verbose application logging. I will typically look for a debug flag in the application and try setting it to TRUE at run-time or by recompiling the application. If a developer uses this method to remove debug logging though, this means switching setting the DEBUG boolean to true in the BuildConfig class on a released application will probably not make a difference. Instead, look for an empty logging class and add back in calls to Android’s log methods. There’s a few ways to skin that cat, but often some well placed smali code will do the trick. For example, if you see an empty d method taking two strings, try dropping in the following line to see the debug messages again.

invoke-static {p0, p1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I

Comments disabled

Google Wallet – Last Four Digits Revealed to Malware Vulnerability

Posted: April 20, 2012 – 10:22 am | Author: | Filed under: android, bugs, Mobile Security

If you’re using Google Wallet, please check your version number and ensure you’re up-to-date (1.1-R57v5 as of this post). This post describes an issue we discovered and reported to Google a few weeks ago. It has now been patched in the latest version of Google Wallet. We think it’s an interesting concern for both end users of Google Wallet and other application developers. While not the most earth shattering vulnerability, it’s probably not something you would want malware collecting about you or your credit cards.

To start, there has been a lot of great research into Google Wallet recently, including the ability to brute force the account PIN and viaForensics dive into application data storage. Both of those attacks required root level access to the device. However, in this attack, the heart of the issue involves the ability to send a specially formatted intent message to Google Wallet. This is something any Android application can do, once installed, without any additional permissions. The specially formatted intent message essentially tells Google Wallet to turn on verbose logging. Data which gets logged includes the last four digits of any credit cards that have been associated with your Google Checkout account (since Google Checkout is now rebranded/merged with Google Wallet). While the full card number is not shown, this data (along with other information that might get collected as well), could be used to target you for a fairly believable social engineering attack. Additionally, the inclusion of Google Checkout information means card numbers which I never thought of as part of my mobile phone’s digital wallet, were included as well (you’ll see these as “UNPROVISIONED” listings in the logs).

Google Wallet Last 4 Card Numbers in the Logs

Last 4 digits of credit card numbers from Google Wallet/Checkout in the Android Logs

We’ve put together a short video which shows our “malware” application sending this intent message and collecting data on a non-rooted Galaxy Nexus (running version 1.1-R52v7 of Google Wallet) . You’ll notice the application does require the one permission, the ability to read the device logs. For the technical details, please see the our security advisory.

As for the fix, Google has stated they’ve reviewed all of Wallet’s logging features and have added the android:exported=”false” attribute to the LoggingPriorityChangeReceiver to prevent third party applications from enabling this feature.

Video: Google Wallet – Verbose Log Capture Malware Example


Comments disabled

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

Google Wallet coming for iOS?

Posted: March 15, 2012 – 11:42 am | Author: , and | Filed under: android, iOS, Mobile Security, NFC, RFID

The list of two OS types in WalletShared: ANDROID and IOS (click to enlarge)

Let’s start by saying this is no smoking gun, but a pretty interesting case of information leakage through an application. For our regular blog readers, you’ll know we’ve been looking into NFC based applications over the past year. The jewel of all NFC apps is easily Google Wallet and thus we’ve spent a large amount of time trying to understand it. When you decompile an Android application, which isn’t obfuscated, you’re able to see the same class names, method names, variable names, and other identifiers as in the developer’s source code. In this case, Google Wallet includes a package called “wallet.proto” which contains parsers for any “Protocol Buffer” formatted data the application uses. While the name “Protocol Buffers” sounds generic, it’s actually Google’s well-documented mechanism for serializing data (think of it as their version of XML or PLists). If you followed the Google Wallet PIN hashing issue, you’ll remember that the PIN hash is stored in a protocol buffer.

The “WalletShared” protocol buffers package in the current version of Google Wallet contains hints of iOS within the parsers definitions. This includes defining the “DeviceContext -> HardwareType” field with only two values: “ANDROID” and “IOS”. iOS strings are also found in two additional protocol buffers called “IosDevice” and “IosWallet”. The classes only leak a little detail about the information being collected which include items named “appId”, “appVersion”, “walletUuid”, and a few “model” and “version” items.

Function names with "iOS" in the string

Function names with

Now you might ask why anything about an iOS application, written in Objective C, would get compiled into an Android application, written in Java. This could happen because of how a Protocol Buffer structured data definition file is created. A developer typically creates a “.proto” file, which is a programming language independent file which defines the data structure. This “.proto” file is then compiled using the “protoc” application and creates the appropriate files for the language you are programming in. Thus, it’s simple to use the same “.proto” file to create a Java object or an Objective C object if they are both going to use the same data structure. While Objective C is not in the official protocol buffers package, there is an add-on for that language available. Thus it is quite likely if there was a “shared” data structure which both clients and the server would need to parse, the same “.proto” file would be used regardless of the application’s programming language.

Of course, if Google is developing Google Wallet for iOS, it raises numerous questions. Since iOS devices do not currently include an NFC radio or secure element, is Google planning to release a case, or “sleeve,” with these components? Or do they know something about the next iPhone we don’t? And if the next iPhone does have NFC and a Secure Element, would Apple allow Google access to those components? In any case, if Google is working on developing their wallet for iOS, this could be a sign of strong commitment by Google to contactless payment technology. And that’s a win for everyone regardless of which device is in your pocket right now.

Comments disabled

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

Shmootime: Shmoocon 2012

Posted: January 27, 2012 – 6:05 pm | Author: | Filed under: Conferences

It’s time for one of our favorite security conference, Shmoocon. The Intrepidus Group will be there both on stage and in the booth (…and maybe in the hotel bar from time to time). If you’ve got a barcode, please drop by and say hello. The team has busy putting together a fairly crazy, yet shmooball free, booth for this year (apologies in advance to our neighbors). Just looking for the punching bag. We also plan to setup a tent and camp out in the Break It track where you can catch some of us (past and present) speaking.

Say hello to our booth babe at Intrepidus Group

Say hello to our booth babe

Comments disabled

Android Backdoor Fail – The Kindle Fire Easter Egg

Posted: January 3, 2012 – 10:09 am | Author: | Filed under: android, bugs, jailbreak, Mobile Security, Reverse Engineering

Happy New Year! And for all you Kindle Fire owners, happy early Easter as well. TeamAndIRC released their code and write-up for BurritoRoot which restores root level ADB access on the Kindle Fire. There were other ways to root the Fire before the latest update from Amazon, but this one is attention deserving because of how blatantly the developers left this back door wide open.

You can follow along even without a Fire by grabbing the 6.2.1 software update from Amazon’s site. Download the “bin” file, extract it, then find the “service.jar” framework file. This jar will be in the Android format, so to view this in jd-gui, you’ll want to convert it first (dex2jar works well).

Besides the standard package you would expect to see in the service framework file, you’ll also notice there’s a “” package (Lab126 appears to have done work for a number of Kindle releases). At that point, it’s pretty hard to ignore a class called “EasterEggReceiver”.  There’s not much to this class and nothing has been obfuscated to make it hard to follow. Any application which broadcasts an intent message to the “” service with the correct extra data can enable the ADB daemon to restart as root. No permissions are needed to send that intent and there are no checks in the framework to see who sent the intent message (like maybe try to limit this to only apps with a certain signature) — simply any Android app on the device can call this backdoor feature.

Easter Egg

Dex2Jar view of Kindle Fire's Services framework file

The means of data passing and the severity of this “feature” are different from the HTCLoggers.apk issue from October of last year, but I think they are both signs of the same trend. Mobile developers writing any sort of inter-process communication call or service need to ensure they are communicating only with other trusted apps. Android already gives you a way to do this, if your apps are signed with the same certificate. I’m a fan of Easter Eggs, but sometimes you want to make sure to limit who can walk away with your tasty burrito.


Comments disabled


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