SafetyNet API

[seanrand]

As of version 0.37 Pokemon Go uses GMS's safetynet feature and I for one can't get past login. What is the implementation status on safetynet, is this out of scope for microg?

[ArchangeGabriel]

So that was it. Can’t get past the login too.

[mid-kid]

Same problem here. Would love to see stubs around the SafetyNet thing.

[ClearlyClaire]

Unfortunately, just stubs wouldn't do it, as SafetyNet has a part that is done server-side and is signed: https://koz.io/inside-safetynet/

[mid-kid]

@ThibG Does the app check the signature of what is returned with some static library? If there's no way to spoof the signature by modifying some file in the system, I guess this feature is out of the scope of microg and should be handled by patching the app itself.

[ClearlyClaire]

@mid-kid If it is done correctly, the response should be forwarded to Niantic's servers to be checked there. Thus, modifying the game won't help you. You would need to reimplement SafetyNet closely enough to “fool” Google into issuing a correct reply. That's quite involved, but might be within the scope of microg (can't talk for @mar-v-in)

[mid-kid]

I should read the blog you linked. Thanks for responding.

[Lanchon]

IMHO this is not in the scope of microg. safetynet was designed to be unhackable in the long run. any success will quickely be squashed by google. fooling safetynet is applicable outside of microg and is a different effort. microg cannot implement safetynet unless a hacking solution already exists. IMHO, apps that use safetynet should be shunned and thats it. a successful hack of safetynet probably requiers a server running secret code (same as the google approach) to doctor measurements in a secret way, so that google cannot immediately see how to detect the hack. this runs contrary to free software ideals. i believe that microg's support of safetynet should involve (if possible) denying the transaction and informing the user that SN is being used (maybe even killing the app) so that the user can uninstall it. in the long run, SN will help free software users get rid of propietary services via the learnt pain of loss functionality caused by updates.

[mid-kid]

Imho, any apps relying on google play services (and thus, microg) should be shunned if possible. Microg is there to allow you to run them anyway if you so desire, while still being a bit more free than when having gapps installed. As such, I think this includes SafetyNet as well as everything else google play services might include in the future. Whether it's possible for anyone who wants and has time to implement it in a convenient timeframe is another question. However, google's captcha v2 has been broken (allowing for bots to bypass captchas) for example. I don't think it's impossible, just hard to figure out the specifics of what the server expects. EDIT: By the way, for this game in particular, depending on how they implemented the jailbreak check on iPhones, it could very well be possible to bypass SafetyNet by modifying the game to login as an iPhone. I have no idea on the specifics of the API however so this is just a random thought.

[mar-v-in]

SafetyNet is not a problem itself, the problem is that it depends on DroidGuard, which is based on a native binary blob.

[nyanpasu64]

I don't really understand how SafetyNet works, but it's it possible to build an emulated clean Android VM (EDIT: or Java/execution/chroot environment) and run SafetyNet in there?

At this point I think I will quit Pokemon Go. They deserve to lose all their users.

[Lanchon]

@mid-kid, i don't agree with you at all, and your overly simplified way of thinking (safetynet is part of gapps) makes you confuse stuff:

Microg is there to allow you to run [apps relying on google play services] anyway if you so desire, while still being a bit more free than when having gapps installed. As such, I think this includes SafetyNet as well as everything else google play services might include in the future.

correct: microg is a gapps replacement. wrong: having pristine gapps installed WILL NOT make you pass safetynet!

a perfect reimplementation of SN, including contacting google and running the downloaded 'spy' code, should always return NOT PASS, as this is by definition the correct behavior of the SN API in any case in which microg is running. in fact, with this in mind, implementing SN in microg is entirely feasible.

the problem is confusing implementing SN with tampering or defeating SN, which is whole different ball game, and applicable to any case where SN is used. in particular, the same hypothetical attack to SN could be used with any implementation of SN, be it gapps, microg, or you-name-it.

gapps is a set of APIs. SN is a tamper-proof authenticated service that can and will be upgraded the second it is exploited. this is one big difference.

clients of gapps just want some services rendered, and presumably don't care who renders them at all. clients of SN want a particular tamper-proof attestation service and very much care who renders the service, as they have to trust the attestator. this is the other big difference.

these big differences are what puts defeating SN outside the scope of microg. your "i want it to work" simplifying train of thought is the only argument you put forward to the contrary and does not hold scrutiny.

if somebody ever defeats SN (IMHO wont happen), then by all means, distribute microg with that hack integrated already. but putting that project under the microg umbrella is nonsense for obvious reasons.

[Lanchon]

@jimbo1qaz,

I don't really understand how SafetyNet works, but it's it possible to build an emulated clean Android VM (EDIT: or Java/execution/chroot environment) and run SafetyNet in there?

in theory, yes. but you would have to run Pokemon there too! and Pokemon should see the same restricted environment (no interaction with anything in the "real" android).

in practice, no. red pill/blue pill research has shown so far that it is a practical impossibility to emulate a complex machine to the point that is indistinguishable from the real thing to ANY AND ALL possible software running on it. make a successful emulator and the other camp will create new detection code. in SN terms, distribute the emulator and google will upgrade SN within hours to kill it.

finally, the emulator having network links to untrusted systems means that simple timing detection solutions can be used to spot the emu.

At this point I think I will quit Pokemon Go. They deserve to lose all their users.

absolutely.

but eff pokemon! the real problem will be for instance, banks. and the solution would be the same: ditch the bank because it doesnt provide functional online access.

[Lanchon]

SN is a horrible can of worms and may be too hard to crack. it is an anti-competitive measure and should IMHO be banned by law, but most surely won't.

it seems that the only correct solution to SN is to attack the force behind it, Google.

some technologically viable solutions could be illegal: for example, constantly and sucessfully DDoSing SN would naturally force all clients to refrain from using it; problem solved.

other legal solutions may not be viable: recognizing google as an attacker to you and your community justifies boycotting google. if everybody thought this way and stopped using goog's services, their revenue would plummet and they would swiftly give in and kill SN. of course expecting people to act this way is delusional.

[hawken93]

As I heard, the snet.jar downloadable is not obfuscated so if you were to implement the part that downloads and checks it, (hopefully with some url/cert overrides in dev options) someone else could make a blob that would just return what google wants to hear.. (SafetyNet does send a checksum of itself.. Solution: Return the checksum of the safetynet you are supposed to be running instead..)

Also, when it comes to dependencies, it should always be simpler to return a static result rather than iterating the file system and so on.. I'm sure google will try to run some intelligent analysis on their answers.. In the end I suppose tamper detection could be fooled while more innocent analytics were kept real so that google couldn't fingerprint it as easily.. This would have to be optional because I still don't want that spy :( To keep ahead I think eventually we would have to refuse to run if google made a new version (downloaded) and then the fake snet would have to be updated to match versions. Otherwise google could detect people lagging behind (returning old data).

When it comes to the idea of running it in a fake environment, the idea is somewhat flawed because usually it''s easy to detect a fake environment and hard to mask the signs

real cat and mouse game.. But I think some of us actually want to play it

What do you think?

I'm considering replacing gms with your version (microg) because I'm tired of having the snet spy in my system.. The darn thing actually tracks and transmits any changes you make in /system

[hawken93]

Of course, playing the game is not an end game, but when you piss off programmers & hackers, you deserve to get both boycotting and spoofing attempts thrown at you. This can make them waste lots of money keeping up with the fake version, as well as understanding that people are boycotting your stuff..

I did come here because I realized that to tamper with safetynet, one would have to tamper with GMS first ;) And you guys have come a very long way

[mar-v-in]

Please note there are two distinct things in play services that are relevant here: SafetyNet and DroidGuard.

SafetyNet is a considerable well-documented system that checks the system for root binaries etc. It is what is used by Pokemon Go and several banking apps. However there is one part of SafetyNet that is neither documented nor analyzed properly (afaik) and that is its dependency on DroidGuard. b33e43c already provides a very basic implementation of SafetyNet (without downloading blob updates from Google servers), which does not work for now because of its dependency on DroidGuard (possible other reasons.

DroidGuard is a highly obfuscated system (including string encryption, stack validation, etc) that uses a native, device-specific binary. I don't know of any proper public documentation of what DroidGuard actually does (which might also be because you just can't Google that term). But for now it seems impossible to implement DroidGuard without using the device-specific binary. I am currently working on running the binary in an isolated process, so that you can optionally use DroidGuard with microG, but I can't say how good this is going to work.

[hawken93]

Wow, that is awesome! Do you know where in my device I can find the droidguard binaries?

[mar-v-in]

When using original Google Play Services they will be placed in /data/data/com.google.android.gms/app_dg_cache/. There usually are multiple versions present there, the relevant native file is in /data/data/com.google.android.gms/app_dg_cache/*/lib/.

[hawken93]

OK so they download some package. Then they do dex2oat --runtime-arg -classpath --runtime-arg ... --dex-file=/data/ ... /the.apk --oat-file=/data/ ... /opt/the.dex`

This file looks like encrypted instructions. At least they need some kind of post processing.

It contains two symbols: oatexec, oatlastword. Apparently this is normal for oat files. Should be possible to get deeper into this

It looks like a library loader that just takes care to load and return the library so file. It seems to contain these java functions: com.google.ccc.abuse.droidguard.DroidGuard.runNative/ssNative/closeNative/entryHelperNative

I'll try to get back with more but now I'm really curious how the file ended up on my phone, and what information google used to decide which binary I was sent...

[mar-v-in]

The play services does a request to https://www.googleapis.com/androidantiabuse/v1/x/create?alt=PROTO&key=AIzaSyBofcZsgLSS7BOnBjZPEkk4rYwzOIz-lTI with some information in POST (play services version, system architecture and fields from android.os.Build in some protobuf format). The response (protobuf again) contains some link where the file is downloaded (or the file is embedded in the protobuf) as well as some binary blob of meta information that is passed to the binary.

I have a working implementation of both systems and just got a valid SafetyNet response on my test environment (no isolated process yet). Expect an implementation in microG soon™

[hawken93]

I think it merely needs the information to compile it serverside. Apparently the oat file is java compiled to native code. But I think I know enough assembly to recover something meaningful...

[Lanchon]

As I heard, the snet.jar downloadable is not obfuscated so if you were to implement the part that downloads and checks it, (hopefully with some url/cert overrides in dev options) someone else could make a blob that would just return what google wants to hear..

you cant. the whole point is that analisis is done server side and you dont know what google is looking at. plus its a moving target: google can up their checks any time you successfully fool them. and only if they need to grab more raw info to up the checks, they will upgrade the client spying code.

To keep ahead I think eventually we would have to refuse to run if google made a new version (downloaded)

but you automate google's work! now they just need to bump the spy code version instead of actually playing cat and mouse with us.

to win you actually need to run googles code in a sandbox that spoonfeeds lies. but it will be a very very short lived win.

This can make them waste lots of money keeping up with the fake version,

they HAVE lots of money. we ve given it to them, and now they are using it against us.

the real solution is having most phones fail the check so that developers wont use it. how? well CM is not big enough to matter. also chinese non-google phones are not big enough. DoS is illegal. a virus hacking phones to trip SN is worse than the evil itself.

maybe the only solution is microg: companies selling google free android compatible phones with microg that fail SN. would companies want? yes! they want the search and market revenue. would they be able? not likely because of the anticompetitive all or nothing deal with google to license playstore (u cant make any non playstore device if you want to make any plsystore device at all). note that even samsung and amazon tried this and they lost.

it seems like google will win this one unless hackers go illegal at google, but how long can they keep it up?

then our only remaining chance is EEF.org: can they fight SN in court on antitrust grounds for being essentially a competitor lockout system?

[hawken93]

@Lanchon Of course the analysis is done on server side, but it is done with data provided from the client. If you fool them, of course they will up their checks, but you can figure out what the checks are before even running them. You'll be able to stay ahead in this game.. The thing with replacing the snet binary itself is that they can't easily check for it because you'll just tell them that things are okay..

[hawken93]

And "now they just need to bump the spy code version instead of actually playing cat and mouse with as." Unless they do start obfuscating, this will be really easy to detect. I'm curious if they are willing to abandon the small amount of principles they still have left :P

[hawken93]

Anyway when this cat and mouse game is over, yeah I will abandon any apps that require safetynet and are hard to bypass

[Lanchon]

that was my initial recommendation. abandon apps. services like banks will be harder to tackle though...

[hawken93]

I'm just curious for how long faking snet will be feasible ;) Currently I think it totally can be done

[mar-v-in]

The relevant point I think will be something else: microG has not a relevant number of users. As long as this is the case, they probably do not really care. This is already the reason why we can implement microG at all and especially things like cloud messaging etc. and I don't see why it should be different for SafetyNet.

The way microG is about to spoof SafetyNet is probably completely different from Xposed modules and malware, so even if they block out some tools, it might be that microG will still continue to run.

We are not going to play a cat and mouse game a long time. If Google wants to stop us, they can. If they add a feature like SafetyNet they probably don't have microG or alike in mind, they care about security of "regular" users. I don't think it's a problem for them if we bypass SafetyNet on our devices.

[Lanchon]

this is a good insight indeed.

yes, they can block some features like GCM if they wanted, but not the rest of microg: to do that they need to enlist app dev help (check signatures etc) and app devs are not interested in blocking microg.

but they havent blocked GCM, ok.

but will they block SN? i think so. first, any solution in microg can be generalized to exposed, etc. but most of all, SN's very selling point is its tamper proof nature. allowing some tampering undermines their market position. google wants a portable KNOX competitor with this, and being able to sell to many customers, including corp IT departments.

google has incentives to block SN that does not exist for GCM.

unfortunately i think google will swiftly and mercilessly crack down on this effort here. let's see...

oh and by the way, kudos for trying. actually forcing google to take a step here is an important prerequisite to any later social and legal battle.

[mar-v-in]

yes, they can block some features like GCM if they wanted, but not the rest of microg: to do that they need to enlist app dev help (check signatures etc) and app devs are not interested in blocking microg.

That's not correct. The signature spoofing as implemented for microG could be easily bypassed to a level where it is extremely hard to reimplement something similar. Google does not require app developers to change their code, they can just release a new version of the Play Services client library. After time, all apps that are still maintained will be updated to this version. Through Android Studio Google is constantly nagging devs to update libraries and if some new features are added to Play Services, devs will have a good reason to update. As majority of devs do not really care about non-Google Android systems, this will block out microG completely.

But I guess, Google is not interested in a public debate about them misusing their market power that could be caused by such a obvious attack against users that use Android without Google, especially as they are not loosing anything relevant because of microG (most microG users would go without Google if microG was not there). EU is already investigating possible misues of market power by Google and this would certainly weaken their position...

[Lanchon]

not to cause debate, i agree with you on the political views but not the technical assesment on this one. yes, they can make the lib try to verify stuff, but we can 1) fake the lib inputs, or 2) just hack the lib code. the client side nature of the lib means we easily win. this is exactly why SN is server side on attestation and should be on action too: google knows how easy client side would be for us to own so they dont even try; they know they would loose.

[hawken93]

So I ended up making an x86_64 vm for having fun with this droidguard stuff, and wouldn't you imagine it, I ended up with the x86_64 droidguard library! Nice! We'll see what becomes of this. I think x86 (32 bit) is even easier to work with so I may get my hand on that later as well :) Honestly though, I think one could just use snet as a black box and just note down whatever pops out of it. Correct it if it looks wrong. Would probably make droidguard irrelevant..

I understand it if you feel like this is not the place to discuss it. I'm open to suggestions on where we could discuss further :D

[BedHead911]

@FoxP Microg is a replacement for Google Play Services. You can use one or the other but not both. This issue is discussing how to get pokemon go 0.37 and other apps that use safetynet working with microg. As of right now, if you want to play Go with microg... only v 0.35 is working.

[hawken93]

So, I'm still working on libdroidguard, but at least here is the java wrapper: http://sprunge.us/dZAZ?java the native side is still a 3.4MB big text file.. But initNative is coming along.. There is very little obfuscation actually..

[mar-v-in]

@hawken93

1. it's probably waste of time if we do mostly the same stuff the same time, I will clean up my stuff and put it on GitHub later.
2. No offence, but I have the strong feeling that the java file you linked is basically the decompiled java class (maybe cleaned up a bit). Automatic or semi-automatic decompiled source code can't be used in microG for legal reasons (currently all our code is legal open source code and I am not gonna change this for droidguard).
3. Implementing the java wrapper is basically a bad idea, because we can't use it once Google changes it (which they can do every minute). The native library is probably not full reversible and as such we won't be able to not use it - again, Google could update it everyday, so putting it statically in microG is not a choice. As such, I consider all of droidguard (native library and java wrapper) a blackbox to be run in a controlled environment. This is the approach I am currently developing
4. Either you did not stumble upon it until now, or I was not very well in analyzing the native library. As far as I noticed, it uses string encryption and wx memory pages (probably caused by code decryption or code received over network). The input (the byte array put into init/ss method) and output is encrypted as well (output being protobuf with encrypted fields to be precise) and usage of BoringSSL without network usage (atleast no visible network traffic) leads to probable use of encryption as well. It's probably better to do a dynamic analysis instead of static analysis...

[hawken93]

Ah, sorry.. I didn't mean to ask you to include directly reversed code in the project. I'm just trying to understand what the library is and how it works. I thought you meant that the binary was packed in some way, which it isn't.. but I still don't know as much as you about what it does on a higher level. I think it can be possible to reverse it at this point in time, to understand exactly how it works right now, but not necessarily in the future. This will be all we need to understand how snet depends on it. Maybe more.. I guess droidguard might be making some kind of fancy hash from a low level, which means that we would always have to stay on top of it to recreate the hash. If it starts gathering information about the system and adding it to some sort of hash, then a good start would be to understand how it works now, and try to do some binary diffs to understand how it changes in the future..

I'm doing this for my own entertainment as much as anything, so if nothing will get reused, that's fine with me (And yes, the java file is the decompiled class)

[mar-v-in]

Upcoming.

[mid-kid]

I never thought anybody would care enough to achieve this. Great work, @mar-v-in! I assume this runs snet in an isolated environment? Would love to hear the details whenever you're done.

[mar-v-in]

I reimplemented SafetyNet, so no need to put it in an isolated environment.

DroidGuard implementation is based on the original binaries and will be shipped in a separate apk. The DroidGuard implementation is currently restricted to arm32/64 systems running ART (Android 5.0+), maybe I'll add support for other architectures and older android versions later.

And by the way: I don't really care about Pokémon Go, this was mainly done for things like banking apps.

[ale5000-git]

I can not wait to try it :)

[tcmaps]

KitKat support would be soo great!

[ghost]

Just make it work for Pokemon Go. Also add older android versions 4.0.x-4.3.x

[xDragonZ]

You are allowing public to easily bypass SN, furthermore creating problem for legit app that used SN to prevent tampering or spoofing

[mar-v-in]

@xDragonZ and why is it a problem to allow users to bypass SafetyNet?

The relevant feature of SafetyNet is to provide security against malware, blocking out users from using their device how they want to is or should not be the prospective of any tool and if it is, there is no reason why I should not give back users freedom.

Of course the fact that my SafetyNet implementation does not come with root detection can be considered a problem, but bypassing SafetyNet's root detection is already possible using multiple ways that are often easier to deploy than microG.

Please consider that while it might allow users to bypass tampering/spoofing detection, the main reason to develop this is to allow legit users to use apps as intended without the Google tracking required by the original SafetyNet implementation. If Google would provide SafetyNet as an open source solution without tracking for those that do not use GAPPS, this implementation would not be necessary. So if there is someone to blame, it's not me but Google.

[ale5000-git]

@xDragonZ: Don't take it personally but a legit app that use SafetyNet should really fail. SafetyNet limit liberty to use your own phone as you want and people that think like this should really change job.

[ghost]

waiting for these changes impatiently ^_^ great job

[Lanchon]

amazing, kudos!!!

the worst thing about SN and all its abuse (SN is THE reason for me to have chosen to abandon google services ASAP), is that you can't opt out of it. not to mention that it really should be an opt-in feature!

if you have a fully stock and unrooted device, you can't choose to not have google attestate about you: you can't choose to have all inherently abusive apps that use SN fail to run on your phone, or even notify you of their intrusion. more than passing SN, i am more interested in the right to fail it, to immediately distance myself from all the psychos out there that believe they can dictate what computing environments i choose to run.

[mar-v-in]

Interested users, please try the following steps:

• Update microG Services Core to 0.2.4-20
• Install microG DroidGuard Helper from the f-droid repository or this direct link
• Install https://play.google.com/store/apps/details?id=com.scottyab.safetynet.sample to check functionality

Please use GitHub's reaction feature :+1: on this post if it worked for you, and report details if it didn't

[mar-v-in]

@BedHead911 can you provide a logcat? Pokemon Go works on my test device (OmniROM 6.0)

[seanrand]

Confirmed working on 5.0.2 (ARHD 93.0), SafetyNet Helper reports successful SafetyNet validation and CTS profile match with Magisk v6/phh's SuperUser/Xposed 86.5 and root toggled off (and CTS profile match false with root toggled on). Successfully logged in with Pokemon GO 0.39.0.

You are amazing, Marvin - great work, thank you very much!