# Coding

Work in progress
Friday, February 14, 2020

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.

Thursday, February 13, 2020

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.

Wednesday, February 5, 2020

Finally done! Raccoon v4.12 should solve the CAPTCHA issue. Next stop: rewriting/replacing DummyDroid.

Tuesday, February 4, 2020

Done! Bouncycastle does the trick. The rest is a diligent but routine piece of work. Should take only a few more days.

Sunday, February 2, 2020

Finally! Got past the login CAPTCHA - on Linux, this time

Yeah, I know, no blog updates in two months. Sorry about that, but there wasn't really anything to write about.

Saturday, November 30, 2019

Ha! Success. Got past the CAPTCHA prompt

Good news is, I managed to log into my test account. Bad news are, it doesn't work on a PC (yet). But by trying to lock non-droids out, Google might have told us more about the login internals than intended.

Thursday, November 21, 2019

This whole CAPTCHA nonsense might, of course, be (in part) IP address related. At least there’s https://accounts.google.com/DisplayUnlockCaptcha. Not sure how that is actually suppose to work, no useful documentation on it either (surprise!). Anyway, I decided to work on proxy support in the setup wizard.

HTTP(S) is fairly unproblematic. Just a ton of boilerplate code, but you can easily switch between proxy hosts on a per request basis (e.g. if you want to bypass geo blocking). What’s giving me headaches is SOCKS5 (Tor, SSH tunnel). For this one you basically have to reboot the entire network code when switching hosts (killing transfers). I guess, I’ll postpone that for now, though SSH tunneling could be real handy.

I’m not sure if the HTTP User-Agent header matters for the login service (it does matter for market service), in case it makes a difference, here’s how to come up with one:

  APPNAME/VERSION (DEVICE ID)

Use either “GoogleLoginService” (earlier Android versions) or “GoogleAuth” (later Android versions) as APPNAME. I don’t know exactly when it got renamed, but it must have happened after SDK 16 and before SDK 19. VERSION may be “1.2” or “1.3” for “GoogleLoginService” and “1.4” for “GoogleAuth”.

DEVICE and ID are ro.product.device and ro.build.id from your 🖿 /system/build.prop file.

Just a quick one for everybody wanting to have a go at the CAPTCHA problem, but lacks Java skills:

The whole login process is actually just good ol’ HTTP. So, if you know how to operate curl, you are good to go. You’ll also need this commandline tool (source code included in the jar) to generate encrypted passwords.

Monday, November 18, 2019