Category Archives: Mobile Security
Changes to Apple MDM for iOS 5.x
Last Saturday (January 28), I presented an updated talk on Apple’s iOS MDM system at ShmooCon 8. I had a great time, and really enjoyed all the questions and nice comments I received afterwards. I thought I’d mention a couple of the changes that iOS 5 provide.
First, the devices support some additional restrictions and controls. These controls should be available in most commercial MDM solutions, and can also be found in the iPhone Configuration Utility (IPCU). Among these new controls are the ability to:
- Disable Siri
- Selectively disable iCloud features: Backup, Document Sync, Photo Stream
- Reject SSL sites with untrusted certificates
- Prevent moving messages out of an email account into another
- Prevent use of an email account from 3rd party applications
Additions to the MDM service as a whole include:
- Ability to ask a device to “Check Out” when removed from MDM
- Installing and removing applications (custom and App Store apps)
- Listing managed applications
- Configuration of some settings (Voice and Data Roaming)
- Applying iTunes redemption codes to installation of apps (for Volume Purchase Plan)
I’ve updated my experimental MDM server to support most of these features. I’ve also added some better documentation for the server code, and scripts to help create the necessary server and CA certificates.
Slides from the presentation, as well as the code and the Black Hat white paper and slides, are all available at Github. Enjoy!
“Voight-Kampff’ing The BlackBerry PlayBook” at INFILTRATE 2012
Last week, we gave a talk at Immunity’s awesome INFILTRATE conference in Miami Beach, FL. Our presentation, “Voight-Kampff’ing The BlackBerry PlayBook”, discussed some of the black-box style, independent research we performed on the BlackBerry PlayBook. Although some content was similar to our PlayBook talk at SecTor 2011, there were some very notable additions. In particular, we discussed reverse engineering of PlayBook firmware images; flaws in authorization of AppWorld downloads; and exposure of an authorization token used for BlackBerry Bridge (the PlayBook’s PIM and email sync component).
The lattermost point has stirred up a bit of press post-INFILTRATE, so we’d like to clarify a few things:
1. The exposure of the authorization token is facilitated by a bug in the Persistent Publish/Subscribe (PPS) facility of the QNX operating system. This bug causes the contents of otherwise-inaccessible files to be readable from a special file in the same directory. RIM was made aware of this PPS bug as a result of our SecTor talk, as well as notification from others, and again by us prior to INFILTRATE (with special emphasis on disclosure of the Bridge token) — they have fixed this PPS bug in Tablet OS 2.0 (beta).
2. This token exposure effectively renders the BlackBerry handset password moot. The exposed authorization token is accessible after the user has “unlocked” BlackBerry Bridge (where “unlocking” would entail entering the paired BlackBerry device’s password if one is set). Unlocking Bridge is an expected behavior/process for Bridge users. After all, if you’re using Bridge on your device, you’re going to do this. In the case where a BB handset password has not been set, a malicious actor could just request this token from the Bridge service directly.
3. This isn’t “sniffing”. Some highly misinformed comments on news articles have suggested things like “a bad guy would have to be within 10 meters to exploit this.” This issue is not, I repeat not related to Bluetooth (which is used by BlackBerry Bridge). As an aside, despite the title of the article, threatpost has one of the best (press) write-ups so far.
4. The pervasiveness of malicious mobile applications exacerbates this flaw. Unless you’ve been living under a rock, you know that even “savvy” users are frequently duped by seemingly legitimate applications which later turn out to be doing Bad Things. The downplaying of this as an attack vector is nonsense, and the “if dumb users install malicious apps, they deserve whatever’s coming to them” argument is silly. Note that client-side browser or document reader vulnerability could even render this vector moot in the end.
In upcoming posts, we’ll dive a bit deeper into the meat of our research, so stay tuned. For those interested, we have posted the slides at SlideShare, and uploaded some initial code to the Intrepidus Group GitHub page.
Android Backdoor Fail – The Kindle Fire Easter Egg
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 com.android.server package you would expect to see in the service framework file, you’ll also notice there’s a “com.lab126.services” 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 “com.amazon.internal.E_COMMAND” 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.
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.
Man-in-the-Middle (MiTM) and certificate setup on Android 4.0
The Nexus Galaxy and Android’s Ice Cream Sandwich (ICS) are finally here. If you’ve done Android application testing in the past, you’ve probably have tried to install your own Certificate Authority (CA) cert on to an Android device or emulator. This process was somewhat painful and required root level access on physical devices. We have an old blog post here on that process, but that all changes now with ICS.
Installing a certificate can now be done in the Settings->Security menu of an Android 4.0 device and handled in the “Credential Storage” section. This does not require the device to be rooted (at least on the builds we’ve seen so far). The “Trusted Credentials” setting will list both the system wide installed certificates as well as any user added ones. An additional feature is now with a few simple clicks, the end user can disable any CA certificate on their device. Is your vendor still hanging with DigiNotar? Now you can disable that yourself without having to pull files from the device. Just click on the certificate, scroll down to the bottom of the pop-up message, then click the “Disable” button on the right.
Android 4.0 Credential Storage menu
Installing your own certificate is almost as easy. Here was my process. I needed the CA cert I generated in Mallory loaded onto to my Nexus. Mallory creates a unique CA certificate per-installation and stores it in Mallory’s “ca” directory. To move this onto the phone, I started up Python’s SimpleHTTPServer in that directory.
~/mallory/current/src/ca$ python -m SimpleHTTPServer
Now on the phone, I pointed the browser to that server on port 8000 in order to download the “ca.cer” file (adjust your IP address/port/filename as necessary).
http://192.168.90.1:8000/ca.cer
On my device, this dropped the CA certificate to the SD card. Back in Settings->Security screen, find the “Install from storage” option. Click that and your “ca.cer” file gets loaded into the “Trusted Credentials” store under the “User” tab. No bouncing castles or root needed. This will require you to set a passcode on your device (if there is not one already). Face unlock doesn’t appear to cut it just yet.
Mallory's CA Cert loaded on the device
~benn
OWASP ATL: Mobile Application Assessment Presentation
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:
iPad SSL MiTM
- http://www.youtube.com/watch?v=0453HDZYdGU
- http://www.youtube.com/watch?v=kZ1pKShrKyk
- http://www.youtube.com/watch?v=NvyM1wzwT2o
- http://www.youtube.com/watch?v=HRRqL7IAkJw
- http://www.youtube.com/watch?v=24FT-plmjAs
iOS Application MiTM
- http://www.youtube.com/watch?v=Hgk310uUdjI
- http://www.youtube.com/watch?v=x1T6kjtcpLw
- http://www.youtube.com/watch?v=0VwJ1bss5wA
- http://www.youtube.com/watch?v=50NAa324WC0
- http://www.youtube.com/watch?v=btl147-ioKQ
- http://www.youtube.com/watch?v=5YFC2L0vapM
- http://www.youtube.com/watch?v=UL6mjywzBwU
Sound Cloud and Data Protection
Manitree: AndroidManifest.xml Auditor
Part of my presentation at this year’s Rochester Security Summit on Android security, included a reference to a tool that would help automate the process of detecting insecure app’s on Android devices. This was basically my research into how effective analyzing the AndroidManifest.xml file was at detecting insecurities in an app.
AndroidManifest.xml Insecurities:
It turns out that if you think about it, there’s probably a lot of ways you can screw up an app by putting wrong values in the the manifest file. Hopefully you remember that the AndroidManifest.xml is the file included inside of all APK’s that defines what permissions the app requires along with defining some of the operating parameters. For instance, if you wanted to create a content provider, you would make something like this:
<provider android:name=".provider.DropboxProvider"
android:authorities="com.dropbox.android.Dropbox">
<grant-uri-permission android:pathPrefix="/" />
</provider>
But what is that grant-uri-permission gibberish, right? In this case, it means that anything that is located in a path that starts with “/” is able to access the provider. Probably not so good if you’re storing sensitive information in it like DropBox was doing.
That’s just one example but here are some others to consider:
- Leaving debug mode enabled
- Granting incorrect read or write permissions to a service, receiver, or provider
- Setting a high intent priority (read also malware)
- Setting a hidden dialer using the “android_secret_code” feature
How effective is this:
This isn’t a complete way of analyzing an Android device by any means, but here’s a few examples where it could have helped. Do you remember the DropBox post I made a couple months ago? That flaw that was caused by incorrect permissions in the AndroidManifest.xml was a good example that’s very easy to detect.
How about the HTCLogger hub bub. Could we have detected these problems by analyzing the manifest file? No – not really. But it would have picked up the fact that it was registering a hidden dialer code so when you would dial *#*#482564#*#* a hidden menu would appear giving you access to its settings.
In summary, we’ve found that analyzing Android’s manifest file is effective to give you a summary of items that need to be reviewed, and it’s very effective when you need to analyze a large quantity of apps in a short period of time. It isn’t very good at truly performing a vulnerability scan on an app, but it will pull up some items of interest. When you’re testing a device for app’s that are insecure, there may be hundreds installed and this technique is pretty good at flagging ones that you should pay attention to and then allow you to follow up with some of the manual techniques.
Manitree: AndroidManifest.xml Device Auditing Tool
Manitree is a tool that will review an AndroidManifest.xml file, APK package, or an entire device(or devices) for insecure values in the AndroidManifest.xml file.
Usage: manitree.py -f [MANIFESTFILE | APKFILE] | -D
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-f INPUTFILE path to AndroidManifest.xml or APK (e.g.
/home/user/com.something.apk, ./
Device Mode Options:
-D Device Mode: Perform a full test on a device
-d Download from a physical device.(Device mode only)
-e Download from an emulated device.(Device mode only)
--path=TMPPATH Set path of where files are temporarily downloaded.
(Default /tmp/AT)
-u Test only user apps
Output Options:
-T OUTPUTTXT Save results to a text file (defaults to console)
-H OUTPUTHTML Save results to HTML (defaults to console)
Debug Options:
-v Display verbose output
-q Quiet mode
-t Test mode. Check to see that environment has been setupDevice Test Mode:
Look for connected devices and download all of the APK’s for processing:
./manitree.py -D
Test only the emulators:
./manitree.py -D -e
Test only user apps:
./manitree.py -D -u
Test multiple devices:
./manitree.py -D -u
1: HT12345688
2: emulator-5554
3: emulator-5556
4: emulator-5558More than one device found.
Select which device to use or A to test all the devices: A
Individual File Mode:
If you’re already extracted the manifest file, you can review it like so:
./manitree.py -f AndroidManifest.xml
If you haven’t extracted it, you can just give it an APK and it will extract if for you:
./manitree.py -f com.intrepidusgroup.app.apk
Directory Mode:
Same idea as above but if you’ve already downloaded a large pile of APK’s, you can analyze them at once:
./manitree.py -f apks/
Reporting:
run a report on a previous test:
./reporter.py
run a report on a specific device:
./reporter.py -D HTCS000001
run a report on a specific package and filter only high findings:
./reporter.py -P com.intrepidusgroup.app -r high
Requirements:
- Linux (soon MacOSX)
- Python 2.6+
- adb (included)
- AXMLPrinter2.jar (included)
Get It:
The tool is open source and hosted on GitHub: https://github.com/antitree/manitree
You can also just download the latest tar ball from here: [download id="275"]
NFC Intent Filters in Android 4.0 – Don’t forget the AAR
If you were developing a NFC application on Gingerbread for Android and were using intent filters, you had to be concerned about other applications on the device trying to intercept those intent messages. We did a blog post about this in May titled “Hijacking NFC Intents on Android“. Well with Ice Cream Sandwich, you now have a new NDEF record which you can add to specify that your app should handle the NFC intent (and if your app isn’t installed, the user should then get prompted to download it from the market). This new tag is being called an Android Application Record (AAR).
In our past blog example, if you were writing your NDEF message using an application on Android, you would want to include a second NDEF record into your NDEF message. Here’s how that code would look:
NdefMessage msg = new NdefMessage(
new NdefRecord[] { rtdUriRecord, NdefRecord.createApplicationRecord(“com.google.android.apps.maps”) });
Google has a good example of a full “Beam” application which supports AAR in the latest SDK (or you can view it online here). You’ll see the AAR is commented out in the code example, but you get the picture. This ends up being a great compromise for developers creating NFC applications. If you want to leave around generic NFC tags where it doesn’t matter what application handles the data, you don’t need to change a thing. However, if you need to launch a particular app, include one extra record. We’re not sure how well this will carry over to other platforms besides Android, but at least for now, our Blackberry Bold 9930 with NFC just ignores the extra NDEF record and handles the URL in the tag as expected.
Now the rest of this post is just so we can geek out about what an AAR actually is when written to a tag. We used an Ultralight-C and then read the tag data with libnfc. Here’s a screenshot of the values.
We’ve highlighted the AAR information. This appears to be using a Text Record Type Definition which follows the RTD external name format. If I’m reading the specs right, here’s what some of those values mean:
54 – RTD_TEXT
0F – Length of EXT tag (“android.com:pkg”)
1C – Length of Text data (“com.google.android.apps.maps”)
After that is our ASCII values for that record until our end of NDEF message marker “FE” (you can also see the Well Known URI record in the tag before the AAR data).
~benn
Mutual Authentication in Android and iOS
This is a post on implementing mutual authentication while programming for Android and iOS. For the sake of brevity and focusing on the technical side of things, I’m assuming here that:
1. You know what client authentication is
2. You know how to issue certificates to your clients
3. You know how to configure IIS/Apache/webserver_that_floats_your_boat for client authentication
4. You know what I’m doing if I say “R.raw.resourceName” in Android, OR if I say I’m implementing a delegate in iOS
5. You have a DER-encoded certificate for the root issuer of your SSL certificate (rootCert.cer), and a PKCS#12 object containing the client authentication certificate with the private key and chain of issuing certificates (clientCert.p12).
You’ll notice that the title says “Mutual Authentication”, not “Client Authentication” – our goal here is to implement both strong client authentication using certificates, and verify that the server certificate presented to us is issued by a CA we trust explicitly. For example, if my server certificate is obtained from Verisign, I would like to verify that the SSL certificate chains up to the Verisign root, instead of say the Comodo or DigiNotar roots, or any other root stored in the system certificate store.
Now that we have our logistics out of the way:
Android
For Android, we’ll be using the SSLSocketFactory class to implement client authentication. Place all your trusted root issuer certificates into a Bouncy Castle store (BKS). You can create a Bouncy Castle store by doing the following:
keytool -import -alias "rootCert" -file rootCert.cer -keystore myApp.truststore
For the application below, I’m assuming that the trust store and the client certificate are added as resources to the application. In an actual application, the client certificate is probably something that is enrolled for and obtained after the application has been distributed.
KeyStore serverRootCert = KeyStore.getInstance("BKS");
serverRootCert.load(getResources().openRawResource(R.raw.sslapptruststore), "password".toCharArray());
KeyStore clientCert = KeyStore.getInstance("pkcs12");
clientCert.load(getResources().openRawResource(R.raw.clientpass), "password".toCharArray());This loads the truststore containing the trusted root certificates, and the client certificate we need to use for authentication.
HttpClient httpClient = null;
HttpParams httpParams = new BasicHttpParams();
SSLSocketFactory sslSocketFactory = new SSLSocketFactory(clientCert, null, serverRootCert);
SchemeRegistry registry = new SchemeRegistry();
registry.register(new Scheme("https", sslSocketFactory, 443));
httpClient = new DefaultHttpClient(new ThreadSafeClientConnManager(httpParams, registry), httpParams);The code above creates a standard SSLSocketFactory object, setting our trust store as the certificate store we want to compare against, and adding the client certificate we want to use for authentication. The HttpClient object can then be used as you normally would in an application – i.e. set the URL we want to access, execute the request, as shown below:
HttpGet request = new HttpGet("https://example.com/clientAuthRequired.html");
HttpResponse response = httpClient.execute(request);
iOS
iOS follows a slightly different paradigm then Android. To implement client authentication, you need to override/implement specific NSURLConnection delegates.
There are a few basic steps to be kept in mind:
- Define the URL resource you want to retrieve
- Specify the authentication methods you want to handle
- Create security objects for the authentication method
- Handle the authentication challenge
NSURL *url = [NSURL URLWithString:@”https://example.com/clientAuthRequired.html”];
if(nil == url)
// handle errorThat completes the complex process of defining a URL
- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust])
return YES;
if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodClientCertificate])
return YES;
return NO;
}This tells iOS that we would like to handle the Server Trust and Client Authentication events. If you want only client authentication, and want iOS to handle your trust, the server trust part can be skipped.
NSData *rootCertData = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@”rootCert” ofType:@”cer”]];
SecCertificateRef rootCertRef = SecCertificateCreateWithData(kCFAllocatorDefault, (CFDataRef) rootCertData);
NSData *p12Data = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@“clientCert" ofType:@"p12"]];
NSArray *item = nil;
NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys:@“password", kSecImportExportPassphrase, nil];
SecPKCS12Import((CFDataRef) p12Data , (CFDictionaryRef)dict, (CFArrayRef *)item);
SecIdentityRef identity = (SecIdentityRef)[[item objectAtIndex:0] objectForKey:(id)kSecImportItemIdentity];Analogous to the Android code, we first load the resources we need to authenticate and verify identity.
-(void) connection:didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust]) { // Verify method
SecTrustRef trust = [[challenge protectionSpace] serverTrust]; // Create trust object
NSArray *trustArray = [NSArray arrayWithObjects:rootCertRef, nil]; // Add as many certificates as needed
SecTrustSetAnchorCertificates(trust, (CFArrayRef) trustArray ); // Set trust anchors
SecTrustResultType trustResult; // Store trust result in this
SecTrustEvaluate(trust, trustResult); // Evaluate server trust
if(trust_result == kSecTrustResultUnspecified) {
NSURLCredential *credential = [NSURLCredential credentialForTrust:trust];
[[challenge sender] useCredential:credential forAuthenticationChallenge:challenge];
} else {
// handle error;
}
if([[challenge protectionSpace] authenticationMethod] isEqualToString:NSURLAuthenticationMethodClientCertificate]) {
NSURLCredential *credential = [NSURLCredential credentialWithIdentity:identity certificates:nil persistence:NSURLCredentialPersistenceNone];
[[challenge sender] useCredential:credential forAuthenticationChallenge:challenge];
}
}For limiting server trust, the list of root certificates we explicitly trust is set as the trust store to compare against. SecTrustSetAnchorCertificates overrides the system settings for making trust decisions, and replaces them with your own. For client authentication, the client certificate we loaded previously needs to be added as an NSURLCredential to the connection, and then let the networking do it’s thing.
OWASP Mobile – Top 10 Risks at AppSec USA
As one of the project leaders for the OWASP Mobile Security Project, it behooved me to help present, nay unveil the Release Candidate of the OWASP Top 10 Mobile Risks at OWASP AppSec USA 2011. Along with two of the other project leaders — Jack Mannino, of nVisium Security, and Mike Zusman, of Carve Systems — we discussed the general goals of the OWASP Mobile Security Project, its history, and finally the Top 10 Risks themselves. For each entry, we tried to provide an example of bad design or insecure coding practice that would give rise to such a risk, and/or a real world news story resultant of the associated risk item. We received great feedback from attendees, and it seemed some were very charged and passionate about the “top 10″ presented there. As mentioned in the slide deck, there is a 60-day window (from the unveiling) in which the RC Top 10 can be refuted or changed before we push it up to “Final” (that window ends on November 22).
The slide deck is available over at SlideShare.
We encourage anyone who’s interested to get involved in the OWASP Mobile Security Project (visit the OWASP wiki for information on mailing lists and other ways to help). With the Top 10 Risks and Top 10 Controls finally seeing the light of day, we’ve made some headway, but we’ve still got a long way to go.
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
