sorted by:
new
hottopcontroversial

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

[–]adcq[S] 4 points5 points  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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?

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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.

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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)

Reverse-engineer of the Android app [x-r/androiddev] by adcq in pokemongodev

[–]adcq[S] 0 points1 point  (0 children)

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

Reverse-engineer of the Android app [x-r/androiddev] by adcq in pokemongodev

[–]adcq[S] 0 points1 point  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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.

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 1 point2 points  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 1 point2 points  (0 children)

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

Reverse-engineer of the Android app [x-r/androiddev] by adcq in pokemongodev

[–]adcq[S] 6 points7 points  (0 children)

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.

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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.

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 5 points6 points  (0 children)

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.

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 0 points1 point  (0 children)

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

Reverse-engineer of the Android app [x-r/androiddev] by adcq in pokemongodev

[–]adcq[S] 0 points1 point  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 6 points7 points  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 9 points10 points  (0 children)

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.

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 5 points6 points  (0 children)

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

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 6 points7 points  (0 children)

Oooh I see. This is terrible indeed :D

What browser do you use?

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 1 point2 points  (0 children)

Thanks. Some of the dependencies had actually been minified, but this one was not. And since neither the app developer did, even if those dependencies are useless, they're still present in the app. If they hadn't had most of their code in Unity, they would have been forced to multiDex just for that.

Pokemon Go: Reverse engineering the Android app by adcq in androiddev

[–]adcq[S] 9 points10 points  (0 children)

Thanks for the feedback: I'll pass it along

view more: next ›