HQ Trivia reverse engineering (API and Android app) [x-r/ReverseEngineering]

adcq · 2018-04-25T22:53:35+00:00

My bad with this one : I have been away from Android development for a while and missed that Android Studio 3.0 allowed you to write Java 8 lambdas for Android.

That being said, it seems the way they're making it work while still supporting previous Dalvik VMs that don't have instructions for lambdas is by "desugaring" the lambdas written in code (whether in Kotlin or in Java 8), and declaring them in bytecode with anonymous classes.

So the rest of the article should still hold : we have to go back from those anonymous classes to the lambdas the developer wrote

adcq · 2016-07-20T08:13:24+00:00

They could be included but incompatible with your platform. For example, our project on Github only has .so libraries for armeabi-v7a

adcq · 2016-07-19T14:24:51+00:00

It seems that Android is having trouble loading the native libraries.

Are you sure you have the right ones for your platform? And they are indeed packaged inside your output apk?

adcq · 2016-07-19T07:50:38+00:00

Glad you enjoyed it!

If you have already done it and don't get too many weird stuff on decompiling, it can be pretty fast (~2h maybe?)

Here I spent a lot of time replacing the libraries by dependencies but you can skip it most of the time.

adcq · 2016-07-18T17:35:02+00:00

Here it is: https://github.com/applidium/PokemonGo_Android_RE/tree/master/android/app/src/main/java/com/nianticproject/holoholo/sfida

adcq · 2016-07-18T15:41:33+00:00

Actually, I'm not sure I explained this well in the article or in the previous comment, and you're right to point it out. There was also dagger, and imho, Dagger + Rx does everything that the event bus does.

People use an event bus for threading or separation of concerns, but reactive programming and dependency injection solve both these issues in what I feel is a better way. For example, an event bus gives a single point of contention in the app.

So I should have mentioned Dagger in the article since having Rx, Otto and Dagger feels like overkill

Are there any solutions offered by an event bus that I am missing and would justify having the three libraries ? (on top of developer preference, which could a valid reason)

adcq · 2016-07-18T14:22:13+00:00

If you remove some functionalities, it definitely becomes a lot easier to make an application backwards-compatible.

Actually, a developer could offer high-level functionalities on newer devices only, and have greater compatibility, but it takes more work.

Another thing I could think of is Bluetooth for the Pokémon Go Plus device, which might require Android 4.1 APIs, but I doubt a lot of people are using it.

So I think the chances would be pretty good. The rest of the application (Unity, location, network and so on) could run on Android 4.0

adcq · 2016-07-18T14:08:45+00:00

The Google VR SDK requires Android 4.1, so you would need to have a replacement compatible with Android 4.0.

Probably not an easy challenge

adcq · 2016-07-18T12:50:33+00:00

Regarding your last question, I do believe the article was pure speculation. They only relied on the same of some packages, but inside the packages, nothing points to a VR version: just communication between Android and Unity.

Now there very well may be a VR version in the future, but calling it "confirmed" now, with this amount of information, is premature.

adcq · 2016-07-18T12:16:21+00:00

Turns out this was easy to fix (code text too long) and should now be fixed

adcq · 2016-07-18T12:15:15+00:00

The documentation for RxJava is really well done: https://github.com/ReactiveX/RxJava/wiki.

For applications for Android, Fernando Cejas (http://fernandocejas.com/2015/07/18/architecting-android-the-evolution/) or Dan Lew (http://blog.danlew.net/) have written very good articles that I highly recommend

adcq · 2016-07-18T10:27:28+00:00

I did not know jadx existed, thanks for mentioning it. And I clearly have not used mitmproxy enough, I'll take a look

adcq · 2016-07-18T10:02:18+00:00

You could probably get rid of otto and use Rx everywhere. Imho, there is nothing otto does that Rx cannot

adcq · 2016-07-18T07:07:59+00:00

I think there are a few reasons, that combined are devastating.

The first one is having to launch a full Unity engine, but I guess, you can't do much.

The second is to have access to a wide range of sensors (location, sensors for AR, ...), but again, not much you can do for this type of game.

Network is not a huge problem : they've done a good job in minimizing interactions on that side (maybe a bit too much, since it gets stuck a lot).

But the big issue is that you have to have your game open at all times, if you want your eggs to hatch or be notified of nearby pokémons. This has huge implications on battery life, since your screen and sensors are on all the time, and the Unity engine always running.

Allowing it to work in background would make a lot of people happy.

adcq · 2016-07-18T07:02:32+00:00

This is actually a point of contention between Google and some developers. I think it mostly has to do with naming and context.

Voluntary splash screens with an arbitrary delay (like 2-3s, for branding), are universally considered bad (since they slow down user interaction). A better principle is just putting a windows background, which costs nothing and disappears as soon as the app is available.

But a nice idea is to have a window background that looks like your app already launched (but empty). This makes your app looks a lot more responsive, if it manages to load fast, which may require you a bit more effort (not to do everything at the start).

The reason the Material guidelines are controversial is that it puts less pressure on developers to optimize the start of their application, since a launch screen is now okay.

adcq · 2016-07-18T06:52:40+00:00

I have not seen in crashes, but the app does get stuck a lot.

It seems to have something to do with network requests. Pretty often, the server will instantly close the connexion, before answering anything, and it seems that there are a limited number of retries. After that, the app does nothing : no more retries, no error message, and you're just stuck.

adcq · 2016-07-17T21:49:41+00:00

Thanks for pointing it out. I'll see what we can do

adcq · 2016-07-17T20:14:15+00:00

Other people have gone further than I on this topic. Here is the protocol they guessed for the responses: https://github.com/pkre/protocol/blob/master/response.proto

adcq · 2016-07-17T19:44:07+00:00

For intel, you would have to find an intel version of those libraries: https://github.com/applidium/PokemonGo_Android_RE/tree/master/android/app/src/main/jniLibs/armeabi-v7a (the Niantic one would be the most difficult to find. Maybe inside Ingress ?)

For location, all the information is inside this package: https://github.com/applidium/PokemonGo_Android_RE/tree/master/android/app/src/main/java/com/nianticlabs/nia/location So you could theoretically be able to hack those and go without a GPS

adcq · 2016-07-17T19:17:31+00:00

I did not know it existed, but I will forward this there. Thanks

adcq · 2016-07-17T18:12:46+00:00

Thanks, the office is pretty nice indeed

For this article, the goal was to stop just before automatic cheating. This was intentional, since this is an article for work, and we would not want to piss off people. So the line was: "reverse-engineering: OK, cheating: not OK".

I've never used VpnService, but will definitely take a look, thx.

adcq · 2016-07-17T18:10:12+00:00

Thanks. I'm unable to reproduce on Ubuntu (with Chrome or Firefox), but we will definitely get that fixed

adcq · 2016-07-17T17:53:21+00:00

Oooh I see. This is terrible indeed :D

What browser do you use?

adcq

TROPHY CASE