Abusing COM for tightly coupled process interaction

Twice in my career, I had to deal with unreliable third party algorithm libraries in a server situation. There's a service type program that follows a general request/response pattern. Processing a request involves calling a third party library that I don't control and that crashes far too often for comfort. The service must survive the crash, log it, and emit an error response.

The saga continues

Remember, some time ago Google has removed the order amount in USD from their Merchant Console? Ever since, I've used the earnings report at the end of each month to capture that data item.

Two months in, starting with the March 2017 earnings report, that's not an option, either. The order amount is there, so is the transaction fee, but the order ID isn't.

At least the support representative seemed to agree that it was a bug.

UPDATE: they've fixed it without any announcements.

Defeating the IAP emulator

A few posts ago, I've mentioned a certain Android app that emulates valid in-app purchases on rooted Android devices. I also mentioned that this app goes as far as shorting out the digital signature check code, so that apps that do due diligence and check the IAP signature against the Google public key are fooled, too.

I've been suspecting all along that the IAP emulator does this by tapping into the Android system library, so that the built-in signature check function returns true regardless. That seems to be the case. The emulator struck again, but this time, my app had two signature checks - the system one and my homegrown version. And the latter check was the one that correctly reported a signature mismatch.

Normally, I'd be the first to recommend against reimplementing crypto primitives. But in this case, I do feel it's justified. Here's the code. SHA1 hashing is system provided, but the RSA signature check bits are custom. The function and its parameters are deliberately called vague names, just in case the pirate crowd goes through the trouble of introducing special-case processing for my case.

Meet the new boss, same as old boss

Google is full of surprises, aren't they?

Less than three months after they've unveiled the new, redesigned Payments Center, they've discontinued it and moved the functionality to the Play developer console. And it's not like they've moved the same pages to a different host; this is a redesign, both the internals and the UI are noticeably different, with some functionality removed, and some new bugs introduced.

On the brighter side, the new UI is more scrape friendly. It's still JavaScript-driven, with explicit protection against HTTP-only scraping. On the other hand, there's a very straightforward AJAX call that returns JSON with almost all I need to capture the order activity.

There's a glaring exception though. The November 2016 version of the Payments Center would expose a crucial number - estimated revenue in USD (more generally, the payout currency). Not anymore. Unless the order was in USD to begin with, there's no way of knowing what's my take until the end of the month.

Encoding? Compression? You tell me...

In HTTP, there are two ways to specify compression of the content:

• Content-Encoding:gzip
• Transfer-Encoding:gzip

Amazing discovery of the day: command-line cURL, as of v.7.21.6, recognizes both, while the cURL functions in PHP, as of PHP 5.3.3, only respect the former.

Strikes again

Just a few days after I wrote about the in-app purchase simulator, someone tried it again. Not that they've succeeded; the server-side order signature check caught it. But the device-side check didn't. I'm really wondering how'd they do that.

Here's the first step: I'm going to try reimplementing the signature check by hand, and see if the fake order passes that. I suspect the IAP simulator taps into Java's built-in Signature.verify() method, making it return a hard-coded true. It wouldn't know about my homegrown implementation, obviously.

The signature algorithm that Google Play uses is well known, it's SHA1 with RSA. Normally, I'd be the first one to recommend against building your own crypto primitives, but in this case, it's probably justified, at least as the first step to counteract the fraud. I can probably still use the built-in SHA1, just need to reimplement the RSA portion. The latter is a bunch of BigInteger arithmetic.

Google Play fraud

I have a freemium Android app on the Google Play store. It's free to download, but there's a paid subset of functionality. To unlock it, one may download a separate app ("The License App"), or pay with an in-app purchase (IAP).

Such a scheme is open to many avenues of abuse. I'll try to outline some of those, and discuss the ways to combat them.