Archive for the other Category
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!

It’s been a while, but I’m still alive

It’s been quiet a while since I’ve posted anything on my blog. It’s hard to always post information, though I felt I’ve done a good job posting relevant information I’ve researched over the past two years. It’s about time I start getting back into it – though in the mean time it’s time for a little life update. So if your here for a technical blurb – read no further since this won’t have any source code embedded in it, or post-mortems of any applications.

For the past year I’ve had an awesome job at Amadeus North America, working on an excellent new cutting edge product for the travel industry. It was a great learning experience, getting to delve into the world of rapid agile development and learn new tools such a Google Web Toolkit (GWT). I developed countless strong relationships with many coworkers, picking up plenty of coding ‘style’ and quirks. Things that I directly contribute to my coding style today, and definitely something that I’m proud of. Most importantly, I have a real issue making code without writing unit tests (Thanks @RyanNorris!) and feel sick to my stomach if I ever try to check in code without JavaDocs. Looking back, I can honestly say I loved my time at Amadeus. The long days, even the stressful ones, helped me prepare for being a real software engineer – learning more than I ever had in school.

Then I meet the Lookout team…

Lookout” is right, because these guys were insane. I grabbed some food with them while at a conference in San Francisco. Never in my life had I had such an awesome nerd-fest day. Conventions where always interesting, and you always meet interesting people – but these guys where real. They didn’t just talk the talk – they actually did very impressive things day in and day out. Much to my surprise, I had things to actually add to the many interesting talks the evolved through the night. Even more shocking to me, I was asked if I’d ever considered relocating to the west coast for a job.

I remember thinking, “Yikes, these guys are just being nice, it’d never happen”. I talked it over with my girlfriend the next morning after arriving on the red-eye. Lots of words where thrown back and forth using with “it’s probably never going to happen, but…” We agreed I’d go along with the process, like the many other times I’d been approached by companies. It never worked out before, so I wasn’t going to make a big deal of it, or even think of it as anything but a remote possibility.

Then came the phone interview… I always hated these things, they’re worse than face to face interviews because you can’t see the other person expressions. Are you talking to in-depth? Not in-depth enough? Does this person just not believe you? It’s just hard sometimes to gauge peoples reactions without being in the same room. I remember walking away from the phone interview thinking, “Damn… That either really sucked, or went really well.” Luckily, it went well and I got an email asking if I could come out to San Francisco for an interview. This is when everything really started to him me, could I really be getting the dream job I’ve always wanted?

To shorten this post, since I’ve already babbled along for too long – I came in for the interview and ended up doing well. Some of the most interesting interview questions I’ve ever heard where asked, like “How would you exploit this code?” from Anthony Lineberry. After the interview, I actually ended up getting an offer that blew my mind away. It was settled, there was no question in my mind that I wanted this job. My family kept reminding me, sometimes your favorite hobby isn’t the best job… Thank god that didn’t hold true :)

So I up and moved to San Francisco, got an awesome apartment with some killer roommates. Now i’ve been a part of the Lookout Mobile Security team for almost a month now. Officially I’m a “Security Response Engineer” (I know, that’s bad ass, never thought I’d have that title..) and getting to learn more and do more thing with Android and other mobile systems than I thought I’d get too. I know get to do for work, what I did in my off hours, it’s quiet possibly the greatest adventure I’ve gotten a chance to take on yet. In the short time I’ve been here I got to even goto Defcon for my first hacker convention. I got to take in tons of great talks with many smart people, and even help with some of my coworkers presentations; “App Attack: Surviving the mobile application explosion”, “These aren’t the permissions you’re looking for”.

Anyway, just figured I’d use this as a kick off post as I get back into the gear with blogging again. For now though, I’m going to get back to doing my part with this awesome team in keeping mobile safe and developers smart.

Protect from viking killer! Wait, what?

Much similar to a previous post I had, “Brutal” Google coding humor…, I was perusing over some code in the AOSP and found an interesting comment:


Below is the full snippet from the file, logwrapper.c.

I’m not sure if “Viking Killer” is an inside joke, an actual good comment or what. Though read allowed – it sounds like a badly named european adult film…

Revisiting the “full stealth” mobile spy from Retina-X
Wait - who is john doe?!

Wait - who is john doe?!

I’ve gotten a few emails regarding my previous post, “Full Stealth” just isn’t what it used to be!, asking for a more depth on the subject. I’ve covered just about everything I found in the first posting – but I did go back and re-read the documentation provided on the web site. Looks sort of like a boo-boo on the architecture of the product.

6. After the installation completes, power down the phone. Then, power the phone back up and bring up the Dialer. Enter the digits *12345# and then press the SEND button. The login screen should then appear. Enter your username/password EXACTLY as you did when you created it. Then click LOGIN.

Wait, what?! I guess we’re really going to rely on the fact notion that this application is very secure and stealthy. Sure hope someone whose being spied on doesn’t have root and just snag the username and password. That could be embarrassing, spying on someone only to have them turn the tables on you since they now have your credentials. It honestly can’t be that hard to implement a unique identifier for these phones to send that would link them to this account, could it? Oh well, just another reason to not purchase this product :)

For anyone who is rooted and might be worried about this application, you can go ahead and add the following line to your hosts file to block their server.

On a side note – keep an eye out for spyAware – it should be on the Android Market soon, a nifty little proof of concept tool I’ll be using to show how to detect/prevent abuse of your phone.

Getting “Verizon” Skype… without being on verizon
Hello there, Mr. hidden skype apk

Hello there, Mr. hidden skype apk

So I’ve been reading all the hype about the new Skype application released on Verizon. Sadly I neither have a droid or any friends with a rooted droid. As one would assume, the apk is located in /data/app-private so I needed access to a rooted droid to get this app… Or do I?

Silly me, I forgot all the research I had done for Market Enabler! After a friend sent me their getprop I was off spoofing my values, no more than two minutes went by and ta-da! Got myself the new Skype application.

The following setprop commands must be run to gain access to the Verizon only part of the market.

setprop gsm.sim.operator.numeric 310004
setprop gsm.operator.numeric 31000
setprop gsm.operator.alpha “Verizon Wireless”
setprop gsm.sim.operator.alpha Verizon
setprop gsm.sim.operator.iso-country us
setprop gsm.operator.iso-country us

Note that you will need to restart your Vending (Market) application to have these values take affect, you can do that by running the following commands via a terminal:

# ps | grep vending
app_5     2699  75    181176 26384 ffffffff afe0dca4 S
# kill 2699

Your process id may not be 2699, so fill in whatever it actually is to kill the right process.
Now, running the Skype application is going to take more work than a few simple getprop and setprop commands… Well at least thats what I think so far, I haven’t actually looked at the apk file. Until that’s figured out, your phone is just going to return the following error screen:
Pffhh, yea right...

Pffhh, yea right...

Adjacking… Where did my ad revenue go?
Make money, money...

Make money, money...

It’s been a while since I’ve posted any article, sadly between work, contracts after work, spam, having a life and volleyball I don’t have much time to spend on my blog. Research is still going strong – but very little has trickled out from me over the past few months.

Something I’d like to finally post has come to my attention. Approximately a year ago when I first started looking into the mobile ad networks, I thought of something sinister. While I never intend to do anything evil, since I’m always looking for ways to protect myself, my first thoughts always seem to be, “how do I abuse this?” It all started when people started trying to think of ways to monetize their application. Do we charge up front, or do we try to make a few bucks off a huge user-base using ads?

My first question is, how are the ads secured? Much like other applications that are tracked by application, most use a “application id” or “publisher id”. This is a super-secret code that is used for identifying traffic from you, right? Alright, well unlike a website advertisement, which has a referrer – mobile ads have no actual way to differentiate traffic other than this “unique” id.

So what? Whats the issue with that? Well, there is a big issue with this. There is a coined term, “adjacking”, that essentially means “falsified” clicks. Originally this term meant you hijacked the javascript of google adsense, and made a click anywhere on your website appear to be a click on your adsense ad. Though, I’m “word-jacking” this term, because I feel my definition is a little more appropriate. Essentially, with the ability to easily decompile/modify an apk file – someone can quiet easily steal your ad traffic, this hi-jacking your ads… Adjacking.

Is this something new? No – but beware of it. I’ve had this article lying around for a bit, more uninterested in publishing for the idea that people would actually attempt to do this if I brought it up. Upon first writing this, I quickly made a program that attempted to make a database of signatures of programs. This program downloaded legit (free) applications and grabbed the signature from the META-INF folder of the apk. Then it attempted to find versions available for download on the internet…. For the most part, the version where always the same – with a rare instance of someone resigning it with little modification to the file, often to help localize it. Though now, I’ve seen and heard of an increase of people downloading their application, replacing the ID in the apk, and replacing it with their own.

Keep your code secure!

Protection from adjacking?

What to do about this? Well, hopefully the ad networks figure something out, though I’m not sure they honestly care much. I’ve sent emails to a few of the big providers with no responses and a few “we’ll look into it” replies. I don’t see a big downside for them – maybe if more people complain they’ll get the hint. I’m sure right now they’ll just get the traffic, for traffic’s sake. Most applications that have been modified probably don’t drive in much or take away much from other people. Though if they do, they could “act” upon these and actually shut people down… Will the correct developer ever see this money? Probably not… Though if your try hard enough you might see something.

The sad part is, most of the people modifying the applications are now no better than a scripting kiddie. There are enough tools available now to make this an easy job. Maybe if people start looking into this, these people will be rooted out – since they must fill in “legit” information to open an account.

Anyways, I’ve been looking at some protection schemes for this, hopefully I’ll have time to post some soon. I’ll post a little tutorial on obfuscating (manually) your adsense/admob/blah code to protect yourself :)

ADC2 and Downloading Apps

Finding the assetId...

Finding the assetId...

So recently I’ve been having quiet an experience with downloading apk files from the android market and through the ADC2 review application. The ADC2 application actually just uses the same downloader that the market does — so that’s a quick reason as to why so many other people are also having this trouble.

Anyway the fix that I have been using is the downloading snippet I posted previously in conjunction with the authtoken snippet.

The one thing I needed to find was the assetId, which conviently was located in an xml file of the currently being reviewed application. This makes it so you don’t have to fire up wireshark or tcpdump to grab the assetId.

Simple load up adb or the terminal on your phone and navigate to, /data/data/ and view the file, the contents will look something like this:

We can easily see above that the string value of is the assetId we need. This will let you easily download the apk files to your computer and install them to your phone in no time :) Hopefully this will help some people who are having the same trouble I was!

Also, just a little note – this will let you obviously save the apk files opposed to not retaining them after submitting a review. This could also be accomplished by doing the old method of a pull from /data/app used for backing up normal applications – since the ADC2 apps are saved to the same location. Enjoy!

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!

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 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!

Cash in on Android – make “stealth” applications!

Make money, money...

Make money, money...

Ah, so you want to make money fast and do little work, while charging a boat load of money? Well, welcome to the bandwagon! First, you need to throw together a hastily made scam product, something to slurp up all your phones information and let it be viewable from a website… Something that just uses all the android permissions you can wrap your mind around;


This is just a small list of “useful” things people seem to well, deem “useful” in knowing. Next set up a simple method to dump all this data onto the device and prepare it for transfer. <sarcasm>One would assume you’d encrypt this information and send it securely, though – that might take development time so why bother wasting your resources? </sarcasm> Hardcode values into your product for “securely” connecting to your server and have it dump information off.

Next to make your claim of application being “stealth” be correct, change your manifest from:


This makes the application not appear on the launcher, also known as the tray. People tend to associate this with “stealth”. <sarcasm> Most people know stealth equates to, no icon! Just because it still registers as an application under application management doesn’t mean people will find it! </sarcasm>

For your web page and server, simply chose a small host – like the one I use for my blog. Dirt cheap, plenty of space and plenty of bandwidth – it’s probably against the TOS to do such a thing, but who cares? Bluehost is only $6.95 a month – if you get one customer you could cover your server costs!

Next set up a simple web interface that displays this data being dumped onto the servers. That will let you cull the data for your users – what they’re going to be paying for of course. Next thing is to spiff up your web site and make it look flashy. Put things like “ONLY $99.99 PER YEAR”, because by adding “only” it somehow makes it seem like a deal. Then throw some banners saying “guaranteed” and “uptime certified” without references to what this actually means – it just makes it seem more legit. Obviously you should add some things stating to “protect children” or catch your “cheating spouse” because well, those sound like valid uses to such an application. Try to stay away from words like “over-protective”, “spying” or “snooping” as it may make a potential user realize the reasons they might really use this product. Another great thing to add to the website is pictures of phones which potentially will exist or haven’t come out yet. Just assume that all Android Software will be the same and all devices will work prior to testing on them, simple say they are supported. By supporting more phones, you look more important and appear to be trustworthy since you’ve claimed you phone works on Hero models. Most average people don’t have a Hero phone, if you have one, well — you must not be average! Oh, don’t forget to write up a quick and easy EULA, saying essentially:

We’re not evil, we don’t sell your information, we just use it for you!

If you have an issue with the functionality of our program, we’ll work to fix it. If we can’t fix it, we’ll give you a refund.

Don’t do this if it’s illegal. If you do something illegal – then it’s your fault, not ours.

While this obviously isn’t much of a EULA, you can’t say you didn’t say so! Besides, this type of “guarantee” is perfect and bulletproof. If there is a bug – then you fix it, if it’s simply “I don’t like this product”, well – sorry? That’s not a problem with the software, that’s a problem with your outlook of our software… Silly customer!

There you go, that’s a pretty straight forward tutorial on how to make tons of cash with an everyday program that does little to no work. Simply market this tool to people of ages 16 to 30, and you’ll get plenty of people who won’t read your “fine print” (all two sentences of it) and you’ll cash in! Last but not least, once you grab the money – you haven’t guarenteed functionality beyond seven days of people purchase, so take your money, close your server and go to your next scam application</sarcasm>

Note: I hope people could detect my sarcasm tags…

1 2 >