Posts Tagged with vending.apk
19
Conquering the mysterious userId (Fixing Android Market downloading)

Originally I found the easiest way to download applications was just spoofing the final request. This worked – and worked well for the entire time I had been using it. Though it bugged me that I couldn’t find out where the actual userId was coming from. So I keep digging and digging and finally came up with the solution which is posted below. I never really shared this though, since as I said – other people just used the hack and didn’t seem to care much. The main concern people had was “how do I get it faster” – which to that I always replied “learn whats going on”. Plenty of people figured it out, though now, according to the the emails I’ve been getting recently and the ones on the Android-Market-Api Google Group, this stopped old hack has working. So, I guess it’s about time to spill the rest of the mysery.

The requests originally looked like this when being sniffed over the wire;

http://android.clients.google.com/market/download/Download?userId=###&deviceId=###&assetId=###

Though recently they started looking like this;

http://android.clients.google.com/market/download/Download?packageName=com.package.name&versionCode=##&token=###

Well – this didn’t matter much to me since I don’t use that project, but I’ve helped enough people through side channels that I figured the information is as good as public. So I’ve decided to write up a little “what is actually going on”.

Just a little while ago I committed an updated market.proto with the necessary fields to request downloads from the Android Market. Essentially I’ve added the GetAssetRequest and the GetAssetRequest which was previously missing. I also fixed the unknown field which is known as the isSecure field. This boolean field lets the market know what type of request is coming in and which token will be used.

In the order versions of the vending apk, not everything was send over HTTPS. When most normal requests (get application info, queries, etc) where over unsecured HTTP, the GetAssetsRequest was considered “secure” and only went over HTTPS. This meant the isSecure field had to be set and a new authtoken would be used. Instead of the android service authtoken being sent, the androidsecure token would be sent. This is probably done so that if someone was sniffing requests, they couldn’t just reuse your android token and get away with it, though it may have been done for other reasons.

So what was the mystery of the userId? Well – it was never found on the device, because it was never actually stored on the device. It was only stored sometimes inside of URLS which had been cached or saved to databases. If properly using the protobuf, this relieves the person from needing to find these values, since the market themselves provide them! It was a bit annoying to figure this out finally, but also a huge relief since I wasn’t going crazy not finding the userId anymore.

So let’s sum this all up;

1. Get the android secure token for your account, use this as the authtoken for your next request
2. Build proper request protobuf; Use authtoken from above, set isSecure to true and add the assetId to a GetAssetRequest
3. Receive the GetAssetResponse and build an HTTP request from it using the; blobUrl as the URL and set a cookie using the downloadAuthCookieName/downloadAuthCookieValue pair.

Lastly, I’d like the apologize for the delay in this information. I feel a bit bad since I’ve known this for a while, but most people who ask me questions where just using the hack, which — until very recently worked fine. Also, it has always been possible to just reverse the apk yourself and figure out what was going on ;)

3
Back to the basics

It’s been a fun and interesting ride on my Android reversing adventure. Nothing explicit to post now, but I just did want to touch on a few things I’ve seen over the past few days. I’ve been doing some research in the anti-piracy field and seen a few different interesting things. One interesting thing I came across is direct memory access, while it’s not possible to inject dalvik opcodes – we could in theory do this with root access. I know, not much help – huh? Still some pretty interesting things we might be able to do with the /proc/pid/mem address spaces if we did have root. An interesting application that uses this is GameCIH, interesting use-case and even more interesting UI for it! Either way I’ll hopefully post a few proof of concepts projects that I have been dabbling with off and on for a while.

Another thing I’ve come to realize as I delve more into Android protection schemes, is that your binaries are never truly protected. While I know it’s never safe to assume that your binaries are a safe asset, as they almost never are on any operating system – for some reason I was under the assumption that they would be more protected with user based permissions on Android. Though this just seems to not be true – as even “protected” applications have their /lib directory world-readable, and even loadable by any other application. This isn’t really a security break by any means, but something I found interesting as I look deeper into things.

On a side rant, I’ve become increasingly frustrated with the amount of people demanding support for open source code. It’s quiet annoying to see people ranting on and on about issues they have with code, when they honestly don’t take the time to debug any of their issues. I guess it boils down to the same issues you find day after day on a forum, people don’t want to search for an answer – they just want to be given the answer. It tends to get even more maddening when you know these people are just trying to turn a buck off the open source project and never even thank people for their help! Shuck — rant mode off for now.

A better note to end on though – I’ve gotten back into my Android Market (Vending) reversing roots. It’s been a little bit since I last looked at some of the dalvik code – but it appears Google has done some interesting things with it. The protobuf has evolved for sure, as well as the Market itself. There are suggestion feedback while searching, many more application shelfs for carriers and tons of extra fields I never really traversed. It’s an awesome thing to have seen evolve and exceptionally interesting to have worked on since day one. I’m sure I’ll be blogging more about it at time goes on. So stay tuned for it if your interested, as I’m sure I’ll be working on it all week. I’ve also just gotten my hands on a G2, so it’s the first time I’ve been using a non-rooted phone – another thing to distract me from doing work :) – hopefully I’ll be posting more on Market data though. It’s always been interesting stuff, I guess I’ll have to finally finish some of the projects of mine!

10
Disable SSL Certificate Checking for Android Market/Vending.apk

Changing the properties..

Changing the properties..


Note: This might be well, a little low level for some people to understand -
though I’m sure this will end up finding the right people. If you understand this post -
then you’ll understand the significance of what the purposes of doing this would be
for
:)

Just randomly looking to do specific things with the Market, I finally figured out a way
to force the Market into accepting any certificate. It turns out there is actually a little bit
of code (leftover from testing?) that if special parameters are set, will allow you to
disable ssl certificate checking. This essentially allows us to well, do lots of things we
otherwise wouldn’t be able to do!

Obviously your going to need root to enable this – and I’m going to provide you the
way I’ve enabled it; using adb. Again like I’ve stated countless times, anything you do
via ADB you should be able to do via a console on the device, I’m not sure why people
always repaste everything and say just do it via a console thinking it’s some big news…
The two variables we’re going to have to set are ro.secure and
vending.disable_ssl_cert_check. Personally, my devices both have ro.secure
already set (properly) to 0. Vending.disable_ssl_cert_check is a new variable that we
will be creating, setting it to “TRUE”. Simply fire up adb and run the following
commands (as root);

setprop ro.secure 0
setprop vending.disable_ssl_cert_check TRUE

You can quickly run a “getprop” to verify you typed everything correctly; ro.secure
should be located as the first variable and the vending one is the last (since it is new).
You can verify that these settings are correct and working by watching your console
log for the Vending.apk via DDMS. The following string should appear while loading
the Market: “Turning off SSL certification check.” This can be seen below:

"Turning off SSL Check"

Also as a final reminder, every reboot these variables must be reset, since there is no program actually setting them already. You must reinitialize these variables (in my case, I only have to initialize vending.disable_ssl_cert_check) if you would like to use this mode.

Hopefully this will be of use to someone other than myself!

50
Downloading market applications without the vending app
Mmmmm... Market Data...

Mmmmm... Market Data...

It turns out downloading a free application is actually pretty easy to reproduce. The things required by the google android servers are just four variables. The server needs to know your userId, authToken, deviceId and the applications assetId.
The userId is a unique number that is associated only with your gmail account, the one that is currently linked to the phone. I’m working on getting a generic way to grab this number, though I believe the request is buried in an ssl request to the google servers. So for now, you can obtain your own userId by doing a tcpdump of your market traffic, just do a download of an application and look for a “GET” request in wireshark. There does not appear to be a “hard” maximum character on this, I’ve seen userIds as low as 8 in length and as high as 13. A bad userId will return a 403 forbidden response.
The authToken is sent in cookie form to the server, to authenticate that the user is using a valid and non-expired token and well, is who they say they are! This is linked to the userId and must match the account that the userId is taken from. Expired tokens will return a 403 forbidden response.
The deviceId is simply your Android_ID, and is linked in anyway to the authtoken or user-id, so feel free to spoof this.
The assetId is a number (negative or positive) that identifies the current stream of the application you wish to download. More on this later when I cover how to get live market data. Note that this number is not always the same – it (appears) to change when something from the application is changed. Originally I referred to this in my research as a “cacheAppID” for just that purpose.

Hopefully someone will find this stuff useful ;) Better than me just sitting on it forever!

11
Getting the Android Market Token (for use in getting live data)

Mmmmm... Market Data...

Mmmmm... Market Data...


I’ve been sitting on this code for a while now. I had been tooling around with it mostly about a year ago when I was collecting live market data – it actually took a long time to figure out what the actual token was. Not sure if this method will be changed since there is apparently a big update for the market coming up, I’m assuming it won’t change though – otherwise older versions of the market would break. For people who don’t know – the http requests the vending apk is sending holds a “token” which there was no link to how it was obtained or formed. It turns out to just be a simple token requested like any other google service. The “service” name just turned out to be “android”. Other “services” that the market uses are “androidsecure” and “sierra” – the latter being the codename for google-checkout.

The main reason this was a pain to figure out was because it’s being handled by the com.google.android.googleapps package, not the vending.apk package.

Hopefully this snippet will be useful for some people, like the MyMarket creators or anyone else trying to do market data analysis. I’ll try to post later how to actually send data and receive it using this token. Enjoy for now!

3
“VENDING_REQUIRE_SIM_FOR_PURCHASE”… Interesting…

So I was skimming through some code looking for some specifics when I ran across the following stuff in Settings;

I located a few more interesting snippets – mainly about vending and requiring a sim card.

If there is anyone who is interested in testing some stuff out and has a dev/adp phone without a sim card – let me know. I’d be interested to see if a few patches I worked up would work :)

1
Newer Vending.odex dump (RC33)


Mmmmm... Market Data...

Mmmmm... Market Data...


Here is a dump using Gabors tool of the newest Vending.odex file. Mainly I’m dumping this here for my own purposes, but I’ve seen plenty of people download the last dump I posted – so here is the newest one!

Newer features as I can see:

- report spam
- detect updates
- few minor fixes

Enjoy!

New-vending.rar

5
Vending.odex dumped


Mmmmm... Market Data...

Mmmmm... Market Data...


Well it’s really late right now, and I’ve been working on a ton of thing, though I thought I’d release this.

This is a decompile version of Vending.odex (Vending.apk/Market.apk) for the G1. It was done using a slightly modified DeDexer by Gabor, mentioned in previous posts.

Enjoy — I’ll post more on it later!

Vending.rar

5
Vending.apk reversing and getting live market data…


Mmmmm... Market Data...

Mmmmm... Market Data...


So I’m not sure why I didn’t think to try to get live market data? For some reason I just *figured* it would be done with SSL or something so I just didn’t try it. Long story short, after building a market-cache parser – I realized, DOH! You can just get the market data live using certain requests! Luckily the parser I made worked fine with the data that I was getting sent back.

It took a little reversing of Vending.apk to see exactly what type of encoding was being used – I sort of guessed right just by looking at what the phone was sending via a Cain&Abel and Wireshark dump. Though google just happened to have some data in there that would through errors if you tried decoding the data directly or certain ways.

I’ll post come up some of the reversing I did on Vending.apk – more specifically the .buildPostParameters routine which is where everything was created for post. It’s actually pretty interesting stuff, and it helped find some routines online that google has publicly available through apache… Though I didn’t find them in the Android libraries :) (nice of them, no? haha)

Anyway, tournament tomorrow followed by a snowboarding trip tomorrow – so I’ll probably post that data on monday!

3
Android Market Place and Vending…


Ok so I got an email inquiring about Vending.apk on an emulator, and I sort of forgot about it for a while. What I was originally attempting to do was repackage the apk – with the optimized odex, in dex format into the Vending.apk. Sadly it hasn’t been working too well and I haven’t had loads of time to work on this.

What I’ve attempted to do thus far is strip the odex header from Vending.odex and resign it as a normal dex file, then repackage the whole Vending.apk. Though my console has been sitting at this screen for the past few hours now;

C:\eclipse\android-sdk-windows-1.0_r1\tools>adb install Vending.apk
370 KB/s (0 bytes in 349452.000s)
pkg: /data/local/tmp/Vending.apk

No error, no failure – it just doesn’t seem to be doing anything, strange, though I might not have correctly stripped the file from odex to dex especially since I’m sort of guessing at this point. Anyway here are a link the files I’ve been toying with in this little experiment, maybe it will help someone else.

Vending.dex (stripped Vending.odex)
Vending.apk (resigned and repackaged with Vending.dex)

1