Android | 逆向安卓版本McDonald应用

McDonald’s mobile app may not seem very interesting; at least, I never really cared about it. In December, however, my friends started using it in order to take advantage of the Winter Days promo, and I learned it might not be that boring after all. Out of curiosity, I decided to have a sneak peek inside and see how it works. ### A little bit of context McDonald’s has several country-specific apps, and since I’m in Italy I’ll talk about the only one available here. The app has bundle ID com.mcdonalds.mobileapp and is also available in Belgium, New Zeland, Netherlands and Norway among other countries. Its contents and functionality, however, widely vary from one country to the other, so I will only focus about how the app works when it’s set up in Italy. I should also point out that while the app is available for both iOS1 and Android2, I’m using the Android version for my research because the app uses certificate pinning and prevents me from using a proxy on my iPhone. Anyway, the iOS version of the app should be very similar. As I did when I played around with Trenitalia’s app3 – my Italian readers will certainly remember – I’m using JustTrustMe4, an Xposed module in order to bypass certificate pinning and capture the app’s network traffic. After some quick research, I discovered that McDonald’s app is developed by a company called Plexure5. While their website offers some minimal documentation about the API endpoints6, it’s unsurprising that they do not disclose any technical details about how apps actually work. But don’t worry, I will. ### App & offers The app itself looks pretty basic. As we’ll see in just a second, it is configured remotely as the server sends it almost everything it shows, including the main sections of the app (from top to bottom: News, Offers, Restaurants, Products, My account). Everybody can easily notice that basically everything is a web view, either loaded from local files or downloaded from the server. Of course the most interesting section of the app is probably the one about offers, which by the way is also the only one that requires an account. <img src="https://open.appscan.io/pic/154/762/cd67f96bd95a2098a326245859e51891a0.png"> The app shows different offers for each user, and that’s pretty intriguing once you notice that they are not randomly chosen. It appears that several factors determine which offers you get, such as how long you’ve had the app for, how many offers you’ve redeemed, which products you like most. Each offer expires on a certain date (usually within 1-3 months) and can be only redeemed once. Once you redeem an offer you get a QR code and you have to apply the coupon to an order within 20 minutes. Two times a year these “standard” offers are disabled and replaced with some special ones. This happens from December 1st to December 25th (Winter Days) and for the whole month of July (Summer Days); during these periods a calendar is set up with a different offer for each day and everybody gets the same offer instead of the “custom” ones.7 ### Remote configuration As I mentioned earlier, the app itself doesn’t do much. The server tells it what to show, how to show it and how to behave under several circumstances. As soon as you open the app, it fetches an extensive configuration file from its backend which looks like this: ```json { "home": "gmalite://gmalite-news", "dateFormats": { "dateFormat": "yyyy-MM-dd" }, "menu": { "main": [ { "title": "gmal_menu_news", "image": "icon_menu_home", "link": "gmalite://gmalite-news" }, { "title": "gmal_menu_offers", "image": "icon_menu_offers", "link": "gmalite://gmalite-offers" }, { "title": "gmal_menu_restaurant", "image": "icon_menu_restaurant", "link": "gmalite://gmalite-restaurant" }, { "title": "gmal_menu_food", "image": "icon_menu_food", "appBarTitle": "gmal_menu_food", "link": "gmalite://gmalite-smartweb?weburl=https://nutrition-web-dot-prd-euw-gmal-mcdonalds.appspot.com/it/it-it/home" }, { "title": "gmal_menu_account", "image": "icon_menu_account", "link": "gmalite://gmalite-account" } ], "sub": [ { "title": "Termini e Condizioni", "image": "icon_menu_about_italic", "link": "gmalite://gmalite-smartweb?weburl=http://www.mcdonalds.it/static/app/termini-condizioni.html" }, { "title": "Privacy Policy", "image": "icon_menu_about_italic", "link": "gmalite://gmalite-smartweb?weburl=http://www.mcdonalds.it/static/app/privacy-policy.html" }, { "title": "Ristoranti aderenti alle offerte", "image": "icon_menu_about_italic", "link": "gmalite://gmalite-smartweb?weburl=http://www.mcdonalds.it/static/app/ristoranti-aderenti.html" }, { "title": "Lingua e Paese", "image": "icon_menu_region", "link": "gmalite://gmalite-marketpicker" } ] }, "theme": { "main": "green", "appIcon": "white" }, "smartWeb": { "isWKWebView": true, "whitelist": [ "www.mcdonalds.it", "www.mcdonalds.com", "nutrition-web-dot-prd-euw-gmal-mcdonalds.appspot.com", "nutrition-web-dot-stg-euw-gmal-mcdonalds.appspot.com", "nutrition-web-dot-dev-euw-gmal-mcdonalds.appspot.com", "mcdonaldswinterdays.adattivo.com", "www.youtube.com", "m.mcdonalds.it", "mcdonaldssummerdays.adattivo.com", "mcdonaldswinterdays.adattivo.com" ] }, "news": { "maximumNewsItemsLoadingLimit": 100 }, "offers": { "enableServerTimeValidation": false, "serverTimeToleranceMinute": 5, "offerActiveDuration": "PT20M", "offerActiveDurationText": "20 minuti", "maximumOfferItemsLoadingLimit": 1000, "claimType": "scanAndGoQR", "enableNumericCode": false }, "loyalty": { "enableServerTimeValidation": false, "serverTimeToleranceMinute": 5, "offerActiveDuration": "PT20M", "offerActiveDurationText": "20 minuti", "maximumOfferItemsLoadingLimit": 1000, "claimType": "scanAndGoQR", "enableNumericCode": false }, "forceUpdate": { "enabled": true, "appStoreAddress": "https://play.google.com/store/apps/details?id=com.mcdonalds.mobileapp", "iOSAppStoreAddress": "https://itunes.apple.com/us/app/mcdonalds/id1217507712", "minAndroidVersion": 2150, "minIOSBuild": 2390 }, "restaurant": { "hideOpenHours": false, "hideContact": false, "hideFacilities": false, "hideDirectionButton": false }, "account": { "migrationType": "resetPassword", "termsAndConditionsVersion": "2018-05-25", "showLogoutDialog": true, "showPreregistrationView": true, "deregisterUrl": "https://mcdonaldsapps.com/account", "privacyStateUrl": "http://www.mcdonalds.it/static/app/privacy-policy.html", "termsConsent": "it_terms_20180525", "fields": [ { "type": "firstName", "showInAccount": true, "required": false }, { "type": "lastName", "showInAccount": true, "required": false }, { "type": "email", "showInAccount": true, "required": true }, { "type": "password", "showInAccount": true, "required": true, "minLength": 8, "containsDigit": true, "containsUpperCase": true, "containsLowerCase": false }, { "type": "gender", "showInAccount": true, "required": false, "genders": [ "male", "female" ] }, { "type": "birthDay", "showInAccount": true, "required": false, "minimumDate": "1900-01-01", "startDate": "2000-01-01", "minimumAge": 16 }, { "type": "confirmTCPP", "required": true, "text": "Ho letto e accettato <a href=\"http://www.mcdonalds.it/static/app/termini-condizioni.html\">Termini e Condizioni</a> (obbligatorio)." }, { "type": "consentTag", "showInAccount": true, "required": false, "initialStatus": false, "date": "2017-09-25", "tagName": "marketing_IT_accepted", "text": "Sì, grazie. Vorrei ricevere notizie, aggiornamenti e promozioni da McDonald’s via email. " }, { "type": "consentTag", "showInAccount": true, "required": false, "initialStatus": false, "date": "2017-09-25", "tagName": "italy_family", "text": "Hai figli con età inferiore a nove anni? (facoltativo)" }, { "type": "consentAPI", "showInAccount": true, "required": false, "initialStatus": false, "consentName": "email_consent", "text": "Sì, grazie. Vorrei ricevere notizie, aggiornamenti e promozioni da McDonald’s via email. " }, { "type": "tagSwitch", "showInAccount": true, "required": false, "initialStatus": false, "tagName": "italy_family", "text": "Hai figli con età inferiore a nove anni? (facoltativo)" }, { "type": "consentAPI", "showInAccount": false, "required": true, "initialStatus": false, "consentName": "it_terms_20180525", "text": "Ho più di 16 anni e accetto i <a href=\"http://www.mcdonalds.it/static/app/termini-condizioni.html\">termini del servizio</a>" } ] }, "connectors": { "digits": { "consumerKey": "", "consumerSecret": "" }, "vMob": { "siteId": "West-Europe-GMA", "authKey": "", "authKeyAndroid": "", "merchantId": 587 }, "google": { "mapsDirection": "https://maps.googleapis.com/maps/api/directions/json", "nearbySearch": "https://maps.googleapis.com/maps/api/place/nearbysearch/json", "geoCodeService": "http://maps.googleapis.com/maps/api/geocode/json", "browserKey": "", "geoCodeRegion": "it", "geoCodeLanguage": "it", "directionLanguage": "it", "geoCodeClientId": "", "geoCodeSignatureKey": "" } }, "analytic": { "kochava": { "enabled": true, "androidGUID": "", "iosGUID": "" } } } ``` It’s worth noting that, among other things, this file determines the app’s main menu items and each one of them can be configured to either show a local view (hardcoded into the app) or to open a web view at a custom web address. Web views can only load pages whose domain is present on a whitelist. ### Accounts & authentication When you open the app for the first fime you have three options: register a new McDonald’s account, login into your existing account, or proceed without an account. The registration and login processes are nothing special both on the user side and behind the scenes, although it’s interesting to note that the registration form is described in the remote configuration file. After a successful login or registration, the app obtains an access token from the server. The token is tied to your account and it does never change or expire (if you log out and log back into the same account you’ll get the same access token). It’s used to identify you in all requests with an Authorization HTTP header. What if an user decides to use the app without an account? Then the app will silently create one tied to your device (instead of your e-mail address and personal data). That’s right: the app generates a username and a password based on information about your device and it performs registration by itself. If we look at the request under the hood, we can see that username and password are strings which encode some data in base64. In order to find out how they are generated, however, we necessarily have to decompile the app. ### Into the app’s code First of all I downloaded the .apk file from Google Play Store, I unzipped it and I used dex2jar8 in order to obtain a Java executable from the classes.dex file. I then used JD-GUI9 to decompile it and browse the (pseudo) Java code. When the app registers a “device account” it uses an endpoint called DeviceRegistration, so that was my first search term which brought this result: ```java public class a extends c<AccessToken> { public a() { super(1, a.a.c, "/DeviceRegistration", AccessToken.class); c("grant_type", "password"); c("username", i.c()); c("password", i.d()); } } ``` From here you can easily see that username and password are generated by the c() and d() methods of the i class, so I jumped to the declaration in order to learn more about them. ```java public class i { private static String a; private static String b; private static String c; public static String a() { if (a == null) { Object localObject = b.b(); String str = Settings.Secure.getString(((Context)localObject).getContentResolver(), "android_id"); if (!TextUtils.isEmpty(str)) { a = str; } else { if (!f.c()) { throw new RuntimeException("Required permission \"android.permission.READ_PHONE_STATE\" has not been declared..."); } localObject = ((TelephonyManager)((Context)localObject).getSystemService("phone")).getDeviceId(); if (!TextUtils.isEmpty((CharSequence)localObject)) { a = (String)localObject; } else { throw new RuntimeException("Unable to obtain device ID..."); } } } return a; } private static String a(String paramString) { try { localObject = new DESKeySpec("co.vmob.sdk.android.encrypt.key".getBytes("UTF8")); localObject = SecretKeyFactory.getInstance("DES").generateSecret((KeySpec)localObject); paramString = paramString.getBytes("UTF8"); Cipher localCipher = Cipher.getInstance("DES"); localCipher.init(1, (Key)localObject); paramString = Base64.encodeToString(localCipher.doFinal(paramString), 8).replace('\n', '_'); return paramString; } catch (Exception paramString) { Object localObject = new StringBuilder("Error performing encoding: "); ((StringBuilder)localObject).append(paramString.getMessage()); throw new RuntimeException(((StringBuilder)localObject).toString()); } } public static String c() { if (b == null) { StringBuilder localStringBuilder = new StringBuilder("DeviceUsernamePrefix"); localStringBuilder.append(a()); return a(localStringBuilder.toString()); } return b; } public static String d() { if (c == null) { StringBuilder localStringBuilder = new StringBuilder("DevicePasswordPrefix"); localStringBuilder.append(a()); return a(localStringBuilder.toString()); } return c; } } ``` Here we have some more complex code, but still nothing too scary. Let’s analyze it step by step. As I said before, the username is generated by c() while the password is generated by d(). If you look closely you’ll see that these two methods are actually identical except for one string. What they do is basically ```java a("[prefix]" + a()); ``` where [prefix] is either DeviceUsernamePrefix or DevicePasswordPrefix and + represents string concatenation. Let’s now turn our attention to the a() method when it’s called with no arguments. From a quick glance at the code we can deduce that the method attempts to get the ANDROID_ID10 of the device, and if it fails it attempts to read the phone’s IMEI number as a backup. So the previous line of pseudo-code can be further simplified into: ```java a("[prefix]" + "[android_id]"); ``` and we just need to look at the a() method when called with a String argument in order to complete the puzzle. That method sets up a DES cipher with co.vmob. as the key, since the full string co.vmob.sdk.android.encrypt.key you can read in the code gets truncated after 8 bytes (the maximum length of a DES key) when the DESKeySpec object is initialized. The input string is then encrypted and encoded into base64. Notice that Base64.encodeToString() is given two arguments, the second of which is 8. That represents a flag with further instructions about how to do the encoding. In order to understand what that means I looked at the code of that method11 and found this comment near the statement URL_SAFE = 8;: ```java Encoder/decoder flag bit to indicate using the “URL and filename safe” variant of Base64 (see RFC 3548 section 4) where - and _ are used in place of + and /. ``` which is pretty self-explanatory. Before returning the result, the method also replaces newline characters with an underscore, so the final base64 string will have a trailing _. And that’s it, this is how the app generates credentials and registers a device if someone decides not to create or use a McDonald’s account. This way they can still track users and do analytics instead of just having a bunch of anonymous users around. This also allows to enforce authentication on the server side, so that unauthorized requests can still be refused while allowing access to all users of the app. Fun fact: the server doesn’t actually check the validity of these credentials. This means that we can send any (valid) string as username and password and the server will still accept them, create a “device account” and return an access token. ### More headers As I have already said, most of the requests must have a valid Authorization header in order to succeed. However, there is a number of other headers that are also required and are sent by the app with every request: ```java x-vmob-device_network_type – specifies if the device is connected via Wi-Fi or cellular data; x-vmob-location_latitude – can be empty; x-vmob-device_utc_offset; x-vmob-application_version; x-vmob-location_longitude – can be empty; x-vmob-location_accuracy – can be empty; x-vmob-mobile_operator; x-vmob-cost-center – an ID based on your country/region; x-vmob-device_timezone_id; x-vmob-device_type – may specify if you’re using a smartphone or a tablet; x-vmob-device – device model name; x-vmob-sdk_version; x-vmob-uid – a (random?) UID in the URL-safe base64 format I talked about above; x-vmob-device_os_version; x-vmob-authorization – a static authorization key; x-vmob-beacons – can be empty; x-vmob-device_screen_resolution. ``` ### Offers Let’s finally talk about offers. Retrieving them is just a matter of fetching a JSON file with a list of offers and their properties, whereas redemption consists of a POST request with the ID of the offer of your choice. The app receives a redemptionCode and generates the QR you can use at the restaurants. As expected everything is done server-side, so there is no chance of generating custom discounts, offers for custom products or anything like that. If you aren’t logged into a McDonald’s account and you’re authenticated with a “device account”, you get a special treatment: the app doesn’t allow you to redeem offers, but that limitation is not enforced on the server-side. Anyway you only get a very basic list of offers to choose from (in my case, the three of them you can see in the screenshot above) and they aren’t tailored to you. This means that, without a proper account, everything I’m going to explain about tags doesn’t work. There is, however, one interesting “feature” I found: whether you are logged in or not, you can always redeem an offer if you know its ID. Of course the app won’t show it or allow you to use it, but the server will. ### Tags: your McReputation At this point, a few questions remain: how does the app decide which offers I get? Is it determined server-side or client-side? Why on Earth did my friend just get an 80% discount on a Big Mac while I only get to choose between a stupid salad and some apple slices? It turns out, it’s all about your reputation. Let me explain. Each McDonald’s account is associated with some tags which specify some attributes. For example, if you’re a new user who has just downloaded the app and has created a new account, your tags may be: - New_Account; - No_Offers_Redeemed; - App_Opened_Recently. The app may show you a few offers for different kind of products. Let’s say you keep the app for a week, you redeem a couple of offers for some burgers and you keep checking for new offers. Chances are your tags will become: - Registered_Within_7_Days; - Redeemed_1_to_3_Offers_in_7_Days; - App_Opened_5_to_10_Times_in_7_Days; - Likes_Burgers. At this point the app may show several burger offers. Then let’s say you suddently stop using the app, maybe because you go for a long holiday. You come back after a month and you open it back. Your tags may become: - Registered_Within_30_Days; - Redeemed_1_to_3_Offers_in_30_Days; - Low_Redemptions; - App_Opened_5_to_10_Times_in_30_Days; - Likes_Burgers. The app may now show you more, better burger offers in order to get you back on track and have you stop by the nearest McDrive as soon as possible. Of course these are just silly examples. In reality there are hundreds of tags and even new users have tens of them. Some of them aren’t as clear as the ones I wrote, while others are almost impossible to understand if you’re not an insider. Anyway, what’s important is that the app regularly downloads your list of tags, updates it, and sends it back to the server. The server then uses the combination of tags of each user to show him pertinent offers about food he may like. This looks like a good strategy in order to reduce the amount of computational power required on the backend (the app itself analyzes what the user does) while still collecting data about users. However, this also gives anyone the power to cheat by telling the server whatever they want about their habits and their tastes. ### Winter & Summer Days ast but not least, let’s talk about Winter Days and Summer Days I described at the beginning. I haven’t found any information about the countries where these kind of promotions are available, so they may be an exclusive of Italy. What’s interesting here is the app isn’t actually capable of managing these kind of offers, probably because they work differently, they are only available for a few days, and they aren’t globally available. Instead, during Winter & Summer Days the app connects to https://mcdonaldswinterdays.adattivo.com or to https://mcdonaldssummerdays.adattivo.com and displays those pages in a simple web view. The pages themselves do all the magic of displaying today’s offer and allowing users to redeem it, of course using both client-side and server-side code. The app does not perform any sort of authentication when displaying the page, which can also be opened on any normal browser since there are no checks on the user agent or anything like that. This also means that the server cannot know if a certain user has already redeemed its daily offer, so it must store this information in cookies. It goes without saying that you can delete cookies whenever you want… just don’t be evil :) ### Conclusion This post is the result of my personal research, done for fun and shared for educational purposes. I do not expect it to be fully accurate or exhaustive. I encourage anybody reading this post to contact me with futher information they might want to share, with error reports or even with just a feedback. ### Disclaimer This post is not endorsed by, affiliated with, maintained, authorized, or sponsored by McDonald’s Corporation or any other company mentioned in it. All product and company names are the registered trademarks of their original owners. The use of any trade name or trademark is for identification and reference purposes only and does not imply any association with the trademark holder of their product brand. Information provided here is for informational and educational purposes only. This post does not promote, encourage, support or excite any illegal activity or any activity which violates End-User License Agreements (EULAs). The website owner cannot be held responsible for any misuse of the given information. ### Notes ``` https://itunes.apple.com/us/app/mcdonalds/id1217507712 ↩ https://play.google.com/store/apps/details?id=com.mcdonalds.mobileapp ↩ https://blog.jacopojannone.com/2018/09/24/trenitalia-app-reversed.html ↩ https://github.com/Fuzion24/JustTrustMe ↩ https://www.plexure.com ↩ https://support.plexure.com/hc/en-us/categories/201191636-API-Documentation ↩ Fun fact: at the beginning of Winter Days 2018 the calendar was leaked and everybody knew in advance which offer would be available on each day. ↩ https://github.com/pxb1988/dex2jar ↩ http://jd.benow.ca ↩ https://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID ↩ https://github.com/aosp-mirror/platform_frameworks_base/blob/c78240df195ed8bb89799057c81f5aec53ec8c35/core/java/android/util/Base64.java#L59 ↩ ```