• UberPeople.NET - Independent community of rideshare drivers. It's FREE to be a person and enjoy all the benefits of membership. JOIN US! CLICK HERE

Reverse engineer partner app

RedFox

Well-Known Member
Has anyone tried to reverse engineer the Uber Android app? I just started with apktool on Kali Linux. See what hidden gems are there. Of course, Uber probably has no gems....only poop.
 

RedFox

Well-Known Member
  • Thread Starter Thread Starter
  • #3
Yeah I have actually succeed and now I have my own "rideshare" app
I'm so happy for you....lol. Actually, I'm curious about how requests are given to drivers. They say it goes to the closest driver, I doubt it. I have got some nice trips after letting poops time out.
 

roadman

Well-Known Member
I'm so happy for you....lol. Actually, I'm curious about how requests are given to drivers. They say it goes to the closest driver, I doubt it. I have got some nice trips after letting poops time out.
proximity is a factor. in busy areas when they are distributing many pings per minute they get very crafty,
 

Disgusted Driver

Well-Known Member
It's unlikely that the dispatching algorithm would appear in the partner app, it's going to be on their servers. You need to understand the client server model and that reverse engineering am app is a long tedious process.
 

tirebiter

Well-Known Member
Are you saying there's no authentication to the server that the app is legitimate? That would prevent your app from successfully talking to the Uber servers?

I would have imagined that maybe there is a secure Android facility that returns an unforgable (e.g. signed) token corresponding to only the app's unique ID. Like, the system takes the app's code signature (which it knows) and signs it with some secret key, and gives you the result. Maybe the key would be the device's private key and the result is in effect a kind of certificate. It certifies that it was this secure API that signed the application's ID. Since it will never sign for anything other than the app that it knows for sure is the real app, and since the real Uber app will never disgorge this "certificate", that would work. (Assuming that debugging tools or other holes don't allow you to peek into the running Uber app and steal it or transmit it to a bogus server...not sure how that would work.)

Well, I've only thought about this for a minute here, but there must be something along those lines to allow a server to know that it is talking to the legitimate app. Otherwise, Facebook , for one, would have been hacked by now in the manner which you are attempting (fake app) and there would be third-party FB apps and stuff all over the place.
 

Disgusted Driver

Well-Known Member
Are you saying there's no authentication to the server that the app is legitimate? That would prevent your app from successfully talking to the Uber servers?

I would have imagined that maybe there is a secure Android facility that returns an unforgable (e.g. signed) token corresponding to only the app's unique ID. Like, the system takes the app's code signature (which it knows) and signs it with some secret key, and gives you the result. Maybe the key would be the device's private key and the result is in effect a kind of certificate. It certifies that it was this secure API that signed the application's ID. Since it will never sign for anything other than the app that it knows for sure is the real app, and since the real Uber app will never disgorge this "certificate", that would work. (Assuming that debugging tools or other holes don't allow you to peek into the running Uber app and steal it or transmit it to a bogus server...not sure how that would work.)

Well, I've only thought about this for a minute here, but there must be something along those lines to allow a server to know that it is talking to the legitimate app. Otherwise, Facebook , for one, would have been hacked by now in the manner which you are attempting (fake app) and there would be third-party FB apps and stuff all over the place.
Who are you questioning, my post? If so, what does authentication have to do with dispatching. Also, for those of you thinking about reverse engineering through a disassemble or something like that, you lose all variable names so it is very difficult to figure out what's going on, becomes a gigantic puzzle.
 

tirebiter

Well-Known Member
I'm just asking a question that appears to be a key (pun intended) problem to what you are trying to accomplish. I was hoping you would educate us. But apparently you don't have an answer, and judging from your hostile non-sequitor response, perhaps you don't even understand the question. Good luck, I guess!
 

Disgusted Driver

Well-Known Member
I'm just asking a question that appears to be a key (pun intended) problem to what you are trying to accomplish. I was hoping you would educate us. But apparently you don't have an answer, and judging from your hostile non-sequitor response, perhaps you don't even understand the question. Good luck, I guess!
You might want to consider using the reply function so we have some idea of who you are asking a question of.
 

TahoeAl

Well-Known Member
It's unlikely that the dispatching algorithm would appear in the partner app, it's going to be on their servers.
Very True

You need to understand the client server model
Not sure if understanding the model is that important. The key is the dispatching algorithm as you stated above.

that reverse engineering am app is a long tedious process.
Very true and it rarely results in something that is readable. To make it more readable, one method is to use hundreds of global search/replaces to remove the generic var/method names and replace them with understandable names. But again this would be a useless process if you are trying to understand the dispatching algorithm; the server has all of the most important code/algorithm.

In simple terms, the driver and PAX apps are secure data collectors for a much larger server app. My iPad shows the app is only about 68K but the data store about 800K
 
Last edited:

Similar threads


Top