# Coding

I really wonder when Android is going to implode under all of the technical debt, it’s engineers have been diligently piling up. You can’t even write a simple “Hello World” app anymore that just runs on all versions of Android. Well, you probably can, but you can’t publish it on the Playstore unless you target at least SDK level X (changes every year). In order to do so, you are forced to bundle a giant compatibility library (congratz, wasn’t the whole idea of the DEX binary format and that idiotic resource system to squeeze every byte out of the APK files?) and half of your code will deal with figuring out on which OS version it is running and how it should behave.

There’s really no part in Android that’s not an awkward compatibility hack. Playstore included.

So, after being utterly pissed about what Google did with HttpClient v4, I spent yesterday on upgrading to HttpClient v5 (did not notice it coming out of beta in February). Good news is, my SSL spoofing code still works. Curious news is that Google changed something about the logging process (again). Previously, if they detected that you are not on Android, you’d be stuck in an endless CAPTCHA loop. Now you just get a plain HTTP 403 with a details message of “Bad authentication” (which is kinda accurate). Looks like what I initially thought to be a red herring was actually just a bug. Of course, this keeps me from properly testing the new CAPTCHA code path…

Anyway, no reason to be alarmed, this doesn’t affect Raccoon.

Is there any part in Android not fucked up beyond recognition?

Gotta vent, cover your ears.

DummyDroid won't download APK files when mocking a Lineage OS device (or any custom ROM for that matter)

With Android and Play, figuring out device compatibility is somewhat of a black art. Which really just is a nice way for saying 'the whole Android ecosystem is one giant compatibility hack'.

Ha! Fun! When you ask Google Play for anything, you get a binary blob in response which must be parsed, using the protobuf library. There are two version of that library available (v2.x and v3.x) that implement version 2 and 3 of the protocol buffer language respectively. Since the two languages are incompatible with each other, I always assumed that the libraries would be as well, but that’s not the case! Version 3.x of the library is actually backwards compatible and able to properly handle blobs created with v2.x!

Why is this so great? Well, Play is inherently tied to version 2 of the language, but the v2.x library lacks a lot of useful features, such as the ability to export a binary blob to JSON. You can only format a message as plain text which kinda looks like JSON, but won’t be parseable. For small stuff that’s sufficient, but you are completely at a loss when dealing with something bigger, such as search results.

So, here’s the same search result (“test”) in the plain text and in the json format. The later can easily be inspected in existing tools (Firefox for example).

Preview: Dummydroid 2.0 - The new app compatibility checker and GSF ID generator

We all know the problem: Google Play only allows us to download apps, compatible with our device and accessible from our current location. Well, that can be helped.

Hm, a lot of people come to the blog lately, looking for a split APK merge tool. I actually just had an idea how to make one. The stupid thing just is that it would not work on Android versions that don’t support App Bundles, so I don’t quite see the point.

Made a bit of progress on the bypass sms verification code when signing up for a new Google account. The whole system is breathtaking from a technical, legal as well as a psychological persepective.

At least on Android, the user is deliberately steered into a “sunk cost falacy” type of situation that suggests that s/he just wasted a couple hundred bucks on a toy that won’t work properly unless connected with a Google Account. Of course, the phone screen is too small to read the terms compfortably and the default is to skip reading your contract anyway. If you want to know what you actually agree to, you pretty much have to look at the wire protocol (it is a lot). How on earth is it that we don’t have laws against this?!

Of course, DummyDroid is pretty much unfixable for various reasons. It’s cheaper/faster to rewrite it from scratch. The main problem here is that in order to spoof an Android device, you need to supply 29 data points:

• From 🗋 /system/build.prop : manufacturer, brand, device, hardware, product, model, id, fingerprint, releaseversion, sdk version, bootloader, abi list.
• Open GL version and list of supported extensions.
• Supported locales
• Obsolete stuff: support for hardware keyboard, 5 way nav input and touchscreen type.
• Screen layout, size, density
• Installed libraries
• List of system available features (e.g. bluetooth, sensors, …)
• List of installes shared libraries
• Version information of certain important apps (com.android.vending).
• Other nonsense: timestamps, OTA installed

Some items (e.g. fingerprint, timestamps, locales) can be calculated or set to sane defaults, but that still leaves around 20 things that must be collected by the user. The challenge is coming up with a userfriendly interface for that.

K, Google came up with a new shitty idea to make sideloading difficult: uncompressed native libraries in the APK. The story here is that it will save space on the device if native libraries don’t have to be extracted, but can directly be mapped from inside the APK file. So now we are in the happy situation, that based on the SDK version (or more precisely: the version of the finsky app), we can get the very same app in three different variants:

• As a traditional, “contains everything and the kitchensink” APK.
• As an app bundle consisting of several APK modules
• As an app bundle consisting of several APK modules where the native code module contains uncompressed files.

Well, it’s not an immediate problem with Raccoon, but I should probably focus on fixing DummyDroid now.