A Brave New Wallet – First look at decompiling Google Wallet

For the record, I welcome our new contactless payment overlords. I truly see the value in having the ability to make a payment transaction with our mobile devices. This opens up an opportunity to make these transactions more secure, give customers a better user experience, and also give them more control over payment options. Sure there are risks involved with this new technology and everyone should do their own weighing of the risk versus benefits, but I imagine a good number of you already have done this with deciding to use a current payment system over cash (or gold). However, a first (and rather quick as I’m supposed to be on vacation) look at the new Google Wallet code makes me wonder if this first release might need a bit of polish.

If you would like to follow along even without a Nexus S 4G, you can grab the new over-the-air (OTA) update from Google here. You can find the main parts of the new Wallet application in the “\system\app” directory of the update, but it will need some deodexing.

I typically start going through an app with the AndroidManifest.xml file. One thing that jumped out at me with the six “debug” and five “fakes” activities listed in the manifest. As a general best practice, debugging code should be removed from production releases. However, you do have to appreciate the humor of the “BsBankManagerActivity”. Yup, sign up with “BS” bank by calling “6501111111″ or visiting “http://bsbank.com” (BS Bank heard there was a BEAST breaking TLS this week, so they dropped it). Going through the BS code leads to some more fun “bsness” later on as well, such the revelation that “something is seriously wrong with this image URL” (which they were working on back in January?)

Additionally, there’s a handful of test related phone numbers left in “DebugMenuHelper” and “DemoDataPopulator”. Here they are in the format found:

4155589991
(415) 626-9682
(510) 351-0108

You will notice there are a few obfuscated classes in the wallet application. These appear to be related to the OTA proxy parts of the application. While not extremely complex in its functionality, I do think it’s appropriate to obfuscate this. Unfortunately, it appears that a great deal of logging can take place here and the default level is set to “FULL_LOGGING” (although it appears this level can be dynamically changed).

We haven’t yet seen what data gets logged by this, but the obvious concern would be a malicious log reading application as described over a year ago by the Lookout team. There also appears code that will send some log messages to “gtec.skcc@gmail.com“.

Continuing with the testing related code in the production application, lets pull out the number of test/demo/uat URLs (which don’t seem totally bogus but still could be). “CodeConfiguration” has a number of these:

private static final DEFAULT_CITI_SOAP_URL_CAT:Ljava/lang/String; = https://systemtest.citibankonline.citibank.com/MSMOTA Personalization/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTAPersonalization ServicePortTypeEndpoint1

private static final DEFAULT_CITI_SOAP_URL_DEMO:Ljava/lang/String; = https://systemtest.citibankonline.citibank.com/MSMOTA Personalization/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTA PersonalizationServicePortTypeEndpoint1

private static final DEFAULT_CITI_SOAP_URL_PROD:Ljava/lang/String; = https://test.mobileservices.accountonline.com/MSMOTAPersonalization_ FUT/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTAPersonalizationServicePortTypeEndpoint1

private static final DEFAULT_FDCML_PROD_URL:Ljava/lang/String; = "https://www.fdmobileservices.com/mAccountsWeb/MbankingService"

private static final DEFAULT_FDCML_TEST_URL:Ljava/lang/String; = "https://cat.fdmobileservices.com/mAccountsWeb/MbankingService"

private static final DEFAULT_TSM_URL_CAT:Ljava/lang/String; = "https://uat.skcctsm.com:8443"

private static final DEFAULT_TSM_URL_PROD:Ljava/lang/String; = "https://pip.skcctsm.com:8443"

const-string v1, "DEVELOPMENT"

const-string v2, "https://jmt0.google.com/cm"

const-string v1, "SANDBOX"

const-string v2, "https://cream.sandbox.google.com"

const-string v1, "PROD"

const-string v2, "https://clients5.google.com/cm"

Finally, with each point release of Gingerbread (2.3) we’ve see code around the NFC components changing greatly. Generally adding new functionality, but at times deprecating older ones. In the wallet code, there appears to be over 50 classes with at least one deprecated method.

I’m sure many others are looking at this code as well and have some intersting finds. We are looking forward to making a payment soon with our Nexus S. Maybe we’ll use it to buy a pair of shoes.

Update 11/18/2011

Its been a while now and there’s been quite a bit of good work on Google Wallet done on XDA Developers. To clear a few things up, the email address appears to be for Android Cloud to Device Messaging (C2DM) and a lot of the debug code was removed from the wallet updates which have been pushed. That said, you can flip on the “Debug” menu in the orginal code. If you want to get this to run on a device though, you’ll need to resign a few other packages or fix permissions.

-b3nn

Post a comment or leave a trackback: Trackback URL.