The plan was to rewrite DummyDroid from scratch, get rid of the ugly code and make it more userfriendly (ideally let it clone a device via USB) while I’m at it. Unfortunately, that would have taken several weeks (yes, the code rot is that bad) and in the meantime, no one would have been able to generate GSF IDs for mock devices (there are/were alternatives to DummyDroid, but I don’t think their respective authors bothered adapting to Google’s changed login procedure, yet). So, hack job time!
DummyDroid v1.2 is a case of “it compiles, ship it”. Cobbled together by merging in some code from Raccoon, compiled by guessing how the build process was suppose to work, using a source tree that’s in disarray. I’m not proud of it. I probably won’t bother cleaning things up, so no source code at the moment, either. This is only a temporary solution anyways.
Sometimes you find really funny stuff in your junkmail folder…
We are the Team Xball and we have chosen your website/network as target for our next DDoS attack.
Unfortunately your data was leaked in the recent hacking of the web site and we now have your information.
We have DataBase tax forms, DOB, Names, Addresses, Credit card details, bank account full details and more sensitive data.
Now, we can publish your details and your clients online who would damage the rating of the company
and would create many problems for you.
On Friday 16_06_2017_7:00p.m. GMT !!! We begin to attack your network servers and computers
We will produce a powerful DDoS attack – up to 250 Gbps
All data will be encrypted on computers Crypto-Ransomware
You can stop the attack beginning, if payment 1 bitcoin (2900 $).
Do you have time to pay. If you do not pay before the attack 1 bitcoin the price will increase to 10 bitcoins
Please send the bitcoin to the following Bitcoin address:
Once you have paid we will automatically get informed that it was your payment.
What if I don’t pay?
If you decide not to pay, we will start the attack at the indicated date and uphold it until you do, there’s no counter measure to this, you will only end up wasting more money trying to find a solution. We will completely destroy your reputation amongst google and your customers and make sure your website will remain offline until you pay. We can publish your DataBase.
This is not a hoax, do not reply to this email, don’t try to reason or negotiate, we will not read any replies. Once you have paid we won’t start the attack and you will never hear from us again!
Please note that Bitcoin is anonymous and no one will find out that you have complied.
The noteworthy thing: this went to a burner address I used years ago. So I’m not particularly worried about team goofball following up on their threat (or even being capable of operating anything more complicated than their junkmail script for that matter).
Today I log into Play to check on my apps. I am greeted by an updated design, twice as slow as the previous one, but hey, at least it’s material design now and I can waste some additional time on getting my bearings. What do I find after stumbling around for a bit? A menu item named Release Management|App Signing, where I can upload my APK signing key! Are you freaking kidding me?!
APK signing is already utterly broken with Android. The only reason for still bothering with it was so that no government could tell Google: “We want to wiretap user X. We know he uses app Y for communication. Here is a trojaned version of Y, push it to him as an update.” As long as Google didn’t have the signing key, they could simply tell any government: “not possible” and that would be it. Now they can (at least for those apps, where developers are stupid enough to relinquish their keys).
I can kinda see why Google added that feature to Play. Key management is a hassle and most Android “developers” are gold diggers with inferior technical skill who don’t understand cryptography. Those developers who actually do understand how app signing works, rather don’t want to bother with a broken by design system. The sensible solution here would have been to slowly phase out app signing, not to break the system even more!
Just so there’s no confusion: The same issue that has been preventing APK downloaders from logging in to Play lately also affects DummyDroid. I didn’t have the time to port the fix over from Raccoon, yet.
The unfortunate thing about DummyDroid is that it’s codebase is about as horrible as it’s usability. So it’s probably the right time now to finally start with that long since overdue rewrite of the application.
What you can do in the meantime:
Yes, pummeling me with your wallet actually is the way to get me to work for you.
As probably everyone has noticed by now, pretty much all APK downloaders (not just Raccoon) have been started to fail lately. I don’t want to go into the technical details, but the reason for this is a recent change by Google to how apps have to log in to Play.
Figuring out how the “secret handshake” must be done now took me about one rather stressful week. Android, under the hood, simply isn’t pretty or easy to debug.
I’d like to thank everyone who decided to fund research and development of the Raccoon by buying a premium key. I’d also like to encourage everyone, who hasn’t done so far (the majority of users) to reconsider and upgrade as well.
Let me make one thing perfectly clear: Android is a moving target. This isn’t the first time, Google breaks Raccoon. It won’t be the last time either. However, my ability to fix things in a timely manner is limited by what is economically feasible. Making and distributing a software, such as Raccoon, is anything but trivial and it can only be done with the financial backup of paying customers. Even if you only need the basic features, buying premium is money well spent.
PS: Yes, I know, Paypal isn’t an option for everyone. In fact, I was working on adding credit card payment and bank wire transfer when Google decided to break things.
Still in the middle of figuring out how exactly Google wants things to be done now. Seems like the issue is bigger than I originally thought. (Re)Discovered a curious tidbit, though, which I’ll have to look into, once I have everything up and running again. In FDFE urls, the following two url parameters are supported:
I think, the idea here is that if you are, let’s say a japanese user on vacation in some other part of the world, you should still be able to download apps only available in Japan.
Well, anyway, that just came up while digging around. Not important now. I just don’t want to forget it (again).
I’m getting a lot of email at the moment about Raccoon suddenly being unable to log into Play, so instead of answering them individually, I’ll just address the issue here.
What happened? Well, in a nutshell, the same thing that always happens once or twice a year: Google got it in their head that something must be done differently from now on and everyone is screwed. More concretely, they changed the way in which clients must request their Auth token (put simply: a cookie that is used instead of username and password). Clients already having a token (being authenticated) are not (yet) affected. That is, if you set up Raccoon before around a week or so, everything is peachy (for the moment). Just don’t change your password/account settings, or you won’t be able to log in again.
So far, I have spent the better half on the weekend on the issue (thanks Google, did you really have to pull this off during the pentecostal holiday?), a fairly good idea what’s broken and a also halfway working solution. I still have to do additional research (hope, everyone else is having a fine holiday) and then spend a day or so on making a clean implementation.
In the meantime, here’s what you can do:
Wait! Whoah! What? Why spent money on something that’s broken?!
Look at it this way: you are not spending money on something that is broken, you are spending money on getting it fixed (over the holidays – did I already mention Pentecost, by the way?) Think of it as Kickstarter, with the difference being that I have been doing this for about 4 years now and have always delivered so far!
Back in the v3 days, I used to have this idiot discussion about handling passwords every other week. Some weisenheimer would notice that Raccoon only prompts for a password during setup. Then, dug through the config file, just to find the password stored there in plain text. Five minutes later, an angry email would hit my inbox, explaining to me that passwords are sensitive information and therefore must be encrypted before storing them on disk. Read more ›
I’m torn on implementing this feature. Raccoon v3 had it, it was pretty popular with power users. It was suppose to be reintroduced in Raccoon v4.1 (Google’s latest protocol changes forced an early release), but I don’t really want to do it.
The problem with the commandline is it being a quick and dirty way to implement features for power users: fairly isolated code and almost no UI bloat. Takes a fraction of the time you’d have to spend on creating a dialog window and you always end up regret doing it afterwards because eventually regular users will want to use the feature, too and then you have to explain to them how to use the commandline. You initially save time on coding, then waste it all again on email support.
The next problem with adding a commandline mode is that Raccoon v3 kept everything in the filesystem, so running multiple instances of the software wasn’t an issue. With v4, however, it is, since all meta data is now kept in an embedded SQL database, which can only be opened by one process at a time.
The choice here is either running the database as a background daemon for multiplexing access or risking that GUI and a CLI instances will block each other. Neither is particularly appealing! Both will be a cause of later regret.
The solution I currently fancy is to temporarily implement a command line switch for updating apps that will be deprecated from the beginning and have “here be dragons” as its sole description. Then eventually have Raccoon run as a servlet as well as a desktop application (see TradeTrax for an example).