Hacker News new | past | comments | ask | show | jobs | submit login
Reverse engineering and removing Pokémon GO’s certificate pinning (eaton-works.com)
145 points by mkane848 on Aug 1, 2016 | hide | past | favorite | 58 comments

Pretty much how I started cracking game copy protections in the late 80's/early 90's. I already owned the games I was cracking, it just became more interesting to me how these protections were implemented and how I'd defeat them. Sometimes I think that was more fun than the game itself. I just didn't want to have to look up pages in manuals or read maroon colored paper with dark blue ink.

I didn't have the luxury of Ida Pro back then, but I did find a disassembler. Using that I'd read through the game code until I found the conditional jumps and then patched the original file with 0xE8 (JEZ?), 0xEB (JMP?), or 0xCD 0x90 (NOP?). At one time I used to be able to recognize just the Opcodes in hex, so I might have those wrong today.

When I started working at Egghead, I was granted time by my manger to crack games for our demo station, so we wouldn't have to jump through hoops on the sales floor. For various professional reasons I've had the pleasure of bypassing my company's own protections. Most recently I used Smali/Baksmali to demonstrate how our company's Android beta timebomb was pretty easy to circumvent.

Once a hacker, always a hacker. I have no doubt that this low level tinkering was why I got into computers in the first place and why they still hold my fascination.

Seems to be down, Google webcache version: http://webcache.googleusercontent.com/search?q=cache:https:/...

Thanks! Here's a copy on archive.is as well: http://archive.is/gjgYx

And here the archive.org version for the people in the countries where archive.is is unavailable[1]: https://web.archive.org/web/20160801021520/https://eaton-wor...

[1] The author of archive.is blocked entire countries in a fit of rage

Can you elaborate on [1]?

Things are stabilizing, was not expecting the article to get this many hits!

Patching an APK like this would break parts of the app, specifically the parts that are arguably the most crucial to be followed by pinned API calls. For example, in-app purchases via Google Play that validate the app's signing would all fail. Similarly restoring any previous in app purchases would also fail. Finally, you wouldn't be able to install this APK without uninstalling the valid production APK first, again due to signature/signing mismatch.

A normal user wouldn't do this, someone who cared more about examining the network traffic than in app purchases would do this.

Agreed. I was commenting on this workaround's viability to be used by a bad actor attempting to compromise the game and other players of it.

Would patching it using Cydia Substrate keep the app's signature intact?

Cydia performs dynamic hooking, and patches the function in the runtime. In theory app's signature should be intact (I have never come across this scenario in practice, so might be wrong). Generally, application implement additional checks for function hooking and dynamic library injections to prevent such attacks.

Very cool workaround in the article, but it feels like it's just another hole that is going to be closed off. It's impossible to balance because on the one hand we want these fortresses to protect us from prying eyes (see apple vs fbi), but manufacturers are also using these fortresses to keep out owners who just want to hack on their own things.

I'm glad Apple is working to keep backdoors out of iOS, but I still prefer Android because I can get into it anyway I want, and do things like the OP without having to resort to backdooring my own device.

> It's impossible to balance because on the one hand we want these fortresses to protect us from prying eyes (see apple vs fbi), but manufacturers are also using these fortresses to keep out owners who just want to hack on their own things.

I think it's very easy to balance: it's my fortress, because I bought it; I should therefor be allowed and enabled to make it do anything I like. The recent changes which Google have announced — which mean that apps will no longer respect the keys I have installed on my devices — are a move in exactly the wrong direction.

How do you prove to the device that you are the one who bought it? You don't want e.g. an FBI agent to be able to root your device.

> How do you prove to the device that you are the one who bought it?

An arbitrarily-complex passphrase of my choosing plus a fingerprint seem reasonable.

Plus a set of long and complex commands to type to stop normal people being tricked into enabling it

Y'know, I honestly don't care all that much if normal people can screw up: learning not to screw up should be part of the public school education all our taxes pay for. We trust normal people not to stab themselves in the eye, not to shoot themselves through the head, not to crash their cars into others: we should trust them not to do stupid stuff on their computing devices.

And when they do, we should hold them liable for any damage their actions have caused to others, just as we do with all those other tools. Yes, I think liability for allowing one's computer to become part of a botnet is a Good Idea™. Car crashes aren't accidents, and allowing one's computer to become infected isn't accidental either.

We ban guns, have extensive driving courses, and let anyone do anything with computers.

Of course if your car crashed because you were driving down a street that a criminal was standing on you'd probably take it back for being terrible.

> We ban guns

Not in civilised countries.

> have extensive driving courses

That's what I'm arguing for. In this country the public pays for 12-13 years of education and subsidises another four; I'm arguing that among the subjects we should cover with that massive investment is 'don't be an idiot with computers,' much as we have drivers' ed.

> which mean that apps will no longer respect the keys I have installed on my devices

Wow, that sounds bad. Where can I read about this change?

> but manufacturers are also using these fortresses to keep out owners who just want to hack on their own things.

I'll play the devils advocate:

1. From manufacturers perspective, it is very difficult to differentiate if the modification are being intentionally done by the owner of the device, or if the owner is being attacked by a 3rd party (e.g. via malware or JTAG)

2. Ownership ends with the device and the app - you cannot 'own' a service that Google/Niantic/Apple/Steam are providing. They can dictate the terms for providing that service and for an online game like Pokemon, not having access to the service makes the ownership the app and the device pointless.

I think 98% of people are really better off in a closed system (excluding piracy). The real issue IMO is getting developer access to any Android or iOS device should be a straightforward and free process.

They're not better off - that's a bit like saying people would be better off if hairdryers were DRMed by magic to heat up only hair. Those closed systems are significantly limiting the usefulness of computing devices. Hell, it's getting hard to call modern mobile platforms "computing devices" - they're becoming glorified TV screens / pretty interfaces to your credit card.

Also, that remaining 2% has to come from somewhere. People learn to make next-gen tech by playing with and reverse-engineering today's tech.

Considering how many people download and install software that harms their PC, where tablets and phones are 'safe' it's complicated. People just don't ask others to come and fix my tablet which really is a vast improvement.

In iOS though, SSLKillSwitch v2 does the job well.

This seems like overly complicated. He could have made the public key extremely small by just placing 0x00s in it so that he could crack it. Easy patching.

He patches two instructions, or 4 bytes, removing the check entirely. No need to "crack" anything. Seems like a pretty simple solution to me.

You'll also notice that the code checks for the certificate length so I'm not sure replacing it with zeroes would have worked.

the key is still the same length, it just has a lot of zeroes.

it could also be done pretty trivially using an xposed module, such as: http://repo.xposed.info/module/mobi.acpm.sslunpinning

i haven't personally tried this route yet though

Xposed module patching only works when SSLPinning is performed in the Java code of the application, as Xposed provides a mechanism for intercepting Java method calls only. Unlike in this case, the code is in C/C++ layer, hence can't be used.

It needs rooted android phone. OP has done it without even needing a rooted device.

is this cert in the update the reason apps like pokevision stopped working?

I think it's a combination of a quite large IP ban wave and sternly-worded letters to the developers of said tools.

I don't know for sure, but I'm going to say 'not entirely'.

Certificate pinning would prevent you from sniffing the requests, and if they made API changes, you would be unable to analyze them.

So I think the reason Pokevision stopped working is because they may have made API changes, but they've been unable to see what the changes were.

Pokevision stopped working because they banned the whole ec2 IP range.

I believe you, so please don't take this is a challenge. It's pure curiosity that prompts me to ask: Do you have a source for more info on this IP range ban?

The pokemongo dev forums on reddit have been compiling a list of known hosts that will result in a 403 response code when an api call is requested.


One source is a GitHub issue for one of the popular open source Pokémon Maps -- https://github.com/AHAAAAAAA/PokemonGo-Map/issues/2777 . AWS/Heroku/Azure/DigitalOcean (mostly) seem to be banned.

And added scanning rate limits.

What's the added value of using imgur's embed code rather than a good ol' <img>? Is this a trend? I would understand it for albums, but why would you do it for individual images? </rant>

Direct links are against imgurs TOS (http://imgur.com/tos):

"Also, don't use Imgur to host image libraries you link to from elsewhere, content for your website, advertising, avatars, or anything else that turns us into your content delivery network."

Funny how not long ago that was one of their selling point.

Seems as though they don't want to be a CDN, not that they don't want direct linking from forum users? Anyway I went for a dig through Alan's old reddit posts because I thought I recalled him saying he's fine with direct links


> Nothing has changed in regards to direct linking. I'm not sure what you're seeing exactly, but we'll always allow you to direct link to any image you want.


> Yes, but you can also look at it as a marketing budget. When people share links, direct or not, the other person now knows about Imgur.


> People linking to the page rather than the image is what keeps imgur going. If everyone linked to the direct image then imgur would have no source of revenue. However, I want people to use the service however they want, and by no means would I ever force anyone to do it one certain way. So, I like it when people link to the page because that's how imgur makes money, but you don't have to do it if you don't want to. I'm just happy that you like the service.

Yeah, but then massive gifs became a thing.

but then serving animated gifs as mp4 became a thing. Of course then using it as a video host became a thing

> Also, don't use Imgur to host image libraries you link to from elsewhere,

what can that possibly mean? there's no way to use imgur at all without linking to it from elsewhere, except if you visit imgur.com as a destination site (which is fine, but not how imgur has been promoting itself for years)

The rest of the sentence means that <a href="http://imgur.com/foo.jpg" >linking to imgur image</a> is fine but don't directly hotlink <img src="http://imgur.com/foo.jpg "> on your site.

Well, sorry to say but website owners should start opening their wallets and host their own images to protect the free web.

The people who most want hotlink-embedding are precisely the people who don't "own" a website, but rather are posting content on someone else's services (forums, blog hosts, etc.) that allow semi-arbitrary HTML embedding (so you can write an <img> tag) but don't support attachment uploading or auto-rehosting.

Hey guys, author here. I used the embed code because some of the images are large and WordPress wasn't resizing them correctly for some reason. I also was unaware of the policy in Imgur's ToS. I will look into these issues and update the article accordingly.

Well it might or might not be against the ToS. I personally just think it's bad practice to use resources you don't have to.

People just want to share a funny picture and that's okay. But if you already own web space somewhere, use it and pay those extra few cents (if anything) to host your own images.

> What's the added value of using imgur's embed code rather than a good ol' <img>?

Well, you can shaft users who browse without JavaScript turned on and help destroy the Web, all in one fell swoop!

I particularly hate how imgur requires JavaScript to use. We have had images in HTML for over twenty years now, and for some reason imgur has decided that they are above all that.

They could easily write a <noscript> section but probably don't to reduce bandwidth. Anyway they use React pretty heavily which is why they "need" JS support

Definitely not my intention. )-: Embeds will be gone soon.

No worries — I don't blame you personally. FWIW, I loved the article.

But it does sadden me to see the once-promising Web turned into what it has.

As mentioned in the comments, this doesn't work when you try to sign in via Google because it checks the signature of the app. The PTC signon doesn't do this so it's currently allowed, but I'm sure Niantic will patch it soon.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact