A few weeks back a company named DLP Mobile got some press about a “new spy app”, which well – it just very similar to all the other ones we’ve seen. It “hides” itself and forwards its text messages to other numbers. Very sneaky and genius, no? Wait, let me rephrase that, no – not very sneaky or genius 
Anyway, that’s not really what I want to blog about. Shortly after the application was removed from the Android Market by Google [link], another interesting one appeared – “Reveal: Anti SMS Spy”.
Not only has the company published a spyware application, but they decided to sell a program to remove it too. Interesting move by them, I guess? Seems like an attempt a FUD and trying to make some quick cash. While I have no idea the true intentions of the creators, I do find it interesting that the price of the application keep increasing that the price of the application kept increasing which each press grab. A nice little article actually brought this up again early this week at the Register.
On top of all this nice news – there where quiet a few tear downs of the application. A good one, written by Axelle Apvrille of Fortinet, highlights the “backdoor” inside it. It’s also interesting to note that this backdoor can be found in all variants/rebrands of the application, SMSNanny and SMSReplicator (non-secret). It reminds me of the old “Remote Administration Tools” like SubSeven which often contained “master passwords” for people to take over with.
I’d like to end this short post by quoting Axelle, as I feel she’s completely correct in this statement:
Seriously, it is very lucky SMS Replicator Secret is not remotely configurable, otherwise attackers could have randomly scanned the networks for infected phones and spy their incoming messages…
Wise words crypto girl, though sadly I fear that people making these applications for a quick buck will never want to take the time write secure programs.
So recently I got an email asking about spoofing your Android ID, normally I just redirect people to my other articles, but I guess this one was different. The person specifically was looking to test applications on their emulator, and needed to avoid “emulator detection”. It didn’t seem like anything tricky – but I googled quick with not many results returned. The things that where returned where pretty… Well – overcomplicated. My first thought was that this should just be located in one of the many sqlite3 db’s – and it turns out it was. Simple little work around yet again, have to love those!
First off, lets see how most applications detect emulators. It’s done using a simple call to Secure.getString() using Secure.ANDROID_ID (previously this was done using System.getString() and System.ANDROID_ID, though these methods are now deprecated). The “detection” often relies on this returning null when it is read inside an emulator. With this said, below is a normal emulator detection snippet;
|
1 2 3 4 5 6 |
String android_id = Secure.getString(getContentResolver(), Secure.ANDROID_ID); if (android_id == null) { // This was run inside an emulator, don't let the user continue! } else { // Oh ok, everythings normal, lets keep going } |
Very simple, doesn’t do anything to complicated, just checks for null being returned. So how can we get this to not return null in an emulator? Easy — just a simple sqlite3 insert command!
Open a shell to your emulator, and navigate to /data/data/com.android.providers.settings/databases/, open up the db in sqlite3 and insert a value using ‘androidid’ as the key, like the following;
|
1 2 3 4 5 6 7 |
# cd /data/data/com.android.providers.settings/databases # sqlite3 settings.db SQLite version 3.6.22 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> insert into secure ('name', 'value' ) values ('android_id','deadbeef4badcafe'); sqlite> .exit |
That’s all you need to do. Now all programs that use that method for detecting if it is an emulator will be returned the value you’ve entered as the Android_id.
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.
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
Lately I’ve been receiving a bunch of emails regarding Android Market data and the Archos 5 IT. So I figured maybe a blog post would be the most appropriate place to attempt to address all the repeat questions, and heck – maybe answer a few before they are emailed to me!
Recently I’ve been working on numerous projects, my focus has mainly been on the Archos 5 IT as it’s my new toy! If you’ve been following me on , you’ve seen my little picture showing I’ve gotten root (yay!).
Archos 5 IT Rooted
Regarding root on the Archos 5 IT, I’m currently running the firmware 1.1.01, the root method appears to work fine on the newest 1.2.03(?) though I have not updated my device yet. No, not out of fear of loosing the root method, more from the advice of other people saying more things are broken in this new upgrade – so I’d like to keep my device running smoothly for what I do until I can fully root it. What do I mean by that? Well essentially we have root on the device, but on reboot we loose root. I’m currently working with einstein_ to modify the bootloader to accept any android img. This will allow us to modify the android image, and keep root after a reboot. It’s posing trickier than we’d hoped so, people will just have to wait. Why are we waiting? Without a changable android image, no current android programs requiring root will function properly (there is no ‘su’ command to run) – so there is no reason to release it unless we want to see people brick their devices.
AppsLibrary - a cheesy alternative
One of the other projects I’ve been working on is a web based version of AppsLib for the Archos 5 IT. This is essential a “cyrket”/”androlib” for the Archos library. The reason I’m doing this is because the current AppsLib application is garbage, there appear to be updates just about each week, yet each release appear to only cause more crashes… Maybe just for me, but I doubt that. Anyway I’ve posted some screen shots for what it’s going to look like on some forums and I’m relatively close to releasing it. It’s almost at the process of just being migrated from my developement machine to this server. Also note that it’s never probably going to be the most functional thing in the world, but it works – more than I can say for the application version right now. The features on release will most likely be, list ten applications in the date of release, give the information available for the item and a link to download it. I’ll add searching and category sorting later on hopefully.
A word on the Android Market data. I’ve not yet had time to write up all my posts on how to collect, spoof and do what not with the data. This will come, though maybe not in the most timely fashion. I know many people are emailing me saying they want to make an open source market client that downloads stuff, well I highly doubt that will happen. Yes we can download applications, yes we can get all the data. The problem lies with some SSL chatter that we cannot and probably will not decrypt.
Lastly, I want to remind people that I do have a paying job, a loving girlfriend and other activities I love doing outside of the computer/android realm. Please hang in there while I take care of my own things first and then work on these as I see fit. People have been telling me that certain ones are more important than the others, but it comes down to this is a hobby and not my real job. I do it in spare time and I’ve been making time for it enough lately. So try not to be too hard on me when I don’t release information you want immediately, when you want it. So, thats my appology on that — and that was my little State of the Archos (Android)
Make money, money...
<sarcasm>
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
android.permission.Access_Fine_location
android.permission.Access_Network_State
android.permission.Battery_Stats
android.permission.Camera
android.permission.Read_Calendar
android.permission.Read_Contacts
android.permission.Read_owner_Data
android.permission.Read_Phone_State
android.permission.Read_SMS
android.permission.Receive_MMS
android.permission.Receive_SMS
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:
|
1 |
<category android:name="android.intent.category.LAUNCHER" /> |
To
|
1 |
<category android:name="android.intent.category.INFO" /> |
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…
Some definite interesting stuff over at the purebasic forums, I found it quiet funny slash hillarious since I’ve had a chance to talk to some of the TEAM RESURRECTiON members before. The primary link is someone named utopiamania who is claiming he the following
“antipiracy code inside the program is meant to be obfuscated and nearly uncrackable”
Some, well, I guess you could say, “memorable” quotes I find sort of funny are the following:
You just need to accept this fact: SND, Resurrection, ARTEAM, and others WILL unpack your software.
Another is well put by locomotion;
1) Uninstall Tool. ExeCryptor, full protection, and Sunbeam over at {RES} has nailed it EVERY build, EVERY Time.
2) Smart Diary Suite. Themidia, Full SDK protection, and quesago unpacked it and nailed it.
3) Any FlexM protected App. Black Riders, LineZero, or Crude shred these apps.
4) SND Request board. Almost all the tough apps usually end up there, and there is no shortage of talent and drive to crack them.
I’m telling you. If you think you can outsmart {RES} BRD, CRD, Lz0, SND, CORE, SSG, FFF – you are dreaming.
Your protection would probably stop quite alot of crackers. However, you simply cannot beat them ALL.
FOCUS on your APPLICATION and its QUALITY. A few timebombs here and there, and multipart serials (see my example) will get your average cracker and their releases will be “nuked” for a while.
However, if you actively try and create challenges and animosity to your app, you will go down in flames and the crackers will put you in your place.
I reverse engineer all the time, and so do many people on this board. Trust us when we tell you that cracking your app can and will be done. However, if you do it right, you can MINIMIZE the damage done.
EVERY ship in the world takes on some water!!! The best ships are DESIGNED to MINIMIZE the damage that it can do, and can HANDLE the challenges. The same is true with your business plan. Expect to be cracked, and ADAPT accordingly with minimal time and cost.
The oh so knowledgable utopiamania thus responded with;
Quote:
I’m telling you. If you think you can outsmart {RES} BRD, CRD, Lz0, SND, CORE, SSG, FFF – you are dreaming.
I can’t outsmart them, but these protectors I mentioned do it 99.999999999999% of the
time.It’s important that people realise this and don’t give up. Very good protection is available nowadays.
Quote:
I reverse engineer all the time, and so do many people on this board
Shure you do, but none of you can reverse engineer an app protected by say code virtualizer. Smile
I guess it’s developers like this guy that the protector companies make all their money off of? Oh well, I guess it’d be sad if the protectors all lost their jobs…
There is even a big shout out to Sunbeam and LaFarge of {RES}
Sunbeam is probably the best EXECrytor reverser out there. Period. Lafarge is another dynamite reverser as well. Trust me. I know their work from other boards.
The Team SND request forum has about the toughest protected apps out there, and they, along with quite a few others, continually defeat these protections.
Anyone here with reversing experience will at least know of these guys, or the Teams they come from.
If you think you are going to beat the combined knowledge of {RES}, SND, AT4RE, CRD, BRD, Unpack.cn, ect, you are kidding yourself.
Focus on your PRODUCT and make it not SUCK. Then people will WANT to buy it. The perfect example here is PureBasic itself. Sure, there are pirated versions out there, but I and a ton of other people loved it so much we WANTED to buy a legit version. Fred has an amazing product, and as a result, people actually BUY it. His protection is very simple and doesnt get in the way a single bit for registered users. You have no idea how much I love him for that, as do most other people.
Take AVS Video tools and other Themidia protected apps. If I have Acronis Trueimage running before I start up AVS, Themedia REFUSES to let me run AVS because of a “monitor” tool. And I paid for Acronis. Screw AVS for that, and they lost me as a customer.
Bravo localmotion, atleast someone understands how the world works!
[sigh] – Sadly for now it ends on utopiamania sort of “claiming” victory with this final post;
That said, nothing posted here has convinced me to abandon either CodeVirtualizer or ExeCryptor as my tools of choice to protect it from criminals as soon as it hits the streets. Razz
I wonder how fast that program will be torn to shreds?
Injecting code plausible and possible!
Success! It seems completely possible, though quiet a pain to inject new code into existing dex files. This doesn’t not appear like it would easily be done ON a device, though in the development setting it seems perfectly possible and completely do-able.
I’m working on a nice proof-of-concept example to show, though I don’t think this is a “backdoor” to malware. Android has been set up well enough that to properly inject things it would require many things to be done, making it in my opinion extremely hard to do it on the fly on the device. I had to inject the code directly to the dex, resigned both the signature and hash makings for the file, then resign the whole package before reinstalling (after a complete uninstall since we don’t have the same keys as the original package) onto the device. This is a long way away from actually being able to do nasty things with it, which is clearly a good thing, since we don’t want that to happen. This does have practical uses of course, though it seems Google has done security rather well so that this process would most likely only be done by an actual developer for a user to not notice an injected file… Otherwise they would have to allow unknown sources, packages would complain about key, so on and so on…
Hopefully more to come on this subject soon!
Figured I’d give a shout out to the father for his QA Blog, as he did a recent short blurb on the Android bug that we’ve used to gain root on the G1′s with.
While I believe some of the quotes:
“I was in the middle of a text conversation with my girl when she asked why I hadn’t responded. I had just rebooted my phone and the first thing I typed was a response to her text which simply stated “Reboot” – which, to my surprise, rebooted my phone.”
“Google hurried to repair the problem, which causes the phone to interpret any text entered just after the phone was turned on as a command.”
“Linux and Unix users are advised to use their systems with “root” privileges reserved only for administrators, but Android was actually giving anybody that privilege.”
“The Android bug has to rate as one of the great software bloopers of all time.”
“We tried really hard to secure Android. This is definitely a big bug.”
Though some of the quotes are definitely media hype… Someone texting their girl and typed reboot? Ok well that’s a straight up lie, they would of had to type reboot into the main part of their home screen, which in turn would search the contacts and then execute the command. So yes, there is truth they could have rebooted it, but I sure how he doesn’t text his “girl” from the contacts like that normally… She might be mad for not have receiving any messages lately?
Oh well, I guess with ever blunder, ever mishap and every bug – someone has to blow it out of proportion. I mean – I know I was sending a text message and typed ^c and it broke me into the terminal! Next think you know someone will say how they left open safe mode, and they where turning on their phone to contacts (yes contacts, not text) their girlfriend and where shocked to see safe mode in their bottom left corner! Oh wait… You can get in safe mode by holding down menu on boot up…. Silly google… Silly media…
Stumbled upon a good article that has a wealth of information on Debian and Android a like.
I don’t want to rehash the whole thing, but here is a quick blurb of the original article;
This does not replace Android. This also gives you access to the full plethora of programs available in Debian and let’s you continue using your phone as it was intended to be: as an Android device with all the capabilities thereof.
Please note that this is not a “port”: Debian already supports ARM EABI, which is the underlying architecture of Android.
Ok, so Android exists. We finally have hardware, we even have source code. What we didn’t have was some game changing moment whereby we suddenly got control of our mobile phones. You know, the moment that Google has promised us for the last year.
The reality of the situation is actually quite indicative of the attitudes in the cell phone world that even Google is powerless to affect. So, anyone who has actually gotten a G1 and has spent the time to try to do anything awesome with it have been utterly disappointed by the fact that we are just regular users on our own boxes: T-Mobile didn’t give us root, being afraid of what we might do.
I’ve been pretty busy working on some confidential projects and reversing the security of some applications. It looks like developers are getting better at protecting their products! Some more security round ups soon hopefully.
A quick round up of protection schemes I’ve seen thus far in Android (G1 specifically) applications;
- Name/Serial combination – FireWallet, Googhelper etc.
- Expiration Dates – Texas Hold Em Beta, Mileage Ledger, etc.
- Registration Codes – Golf Tracks, etc.
- Online Activation Code – IMPlus
- “Lite” Version – AndSudoku, etc.
I’ve been looking into each and every one, trying to see how each was implemented and used. All but the bottom two, online activation and “lite” versions seem to have been broken thus far. My guess is that the online activation will be broken also, though it will take more time than the rest.
So, your a developer and you want to secure your product? I’d say the best way to protect your program and maintain a cost efficient method would be a good name and serial protection. As a malicious user cannot currently debug you program with normal tools like one might use IDA for the Windows Mobile platform, so this is an advantage for you. Deadlistings are pure dumps of the op codes, though thanks to the dexdump tool provided by google they have some hints as to what the op codes mean. This doesn’t resolve to a very easy method of tracing a program and can be extremely difficult to decode an algorithm. Judging by the releases of the cracks and keygens for current Android programs, a good algorithm is hard to break. Googhelper is a good example of this, thus it has a crack released for this. The good thing for these developers is that a new release or update will make the crack useless since a key generator was not created. Firewallet does not seem to be so lucky as it has been keygenned successfully due to a weak algorithm. This still earns my vote as the best solution to the problem, it isn’t very intrusive to the user and can offer a relatively high form of security for the developer. The developer must put the time into making a good method of checking keys and write their code securely… You should not depend the “security” of people being disallowed to access your dex files, as we’ve seen this isn’t 100% with the G1 root work around.
On a quick side note – above I’ve listed “registration codes” which are often the same as the above, though are not tied to any specific name. I’m not going to go in depth about them as no developer has seemed to make one yet. Yes, I have a application listed next to it – that isn’t a mistake. Maybe I’m just informing you that it isn’t checking codes, and possibly just a static variable. This obviously would not be a secure method if they are doing that…
The next type of protection scheme I would like to talk about is expiration dates. This seems to be popular right now see that all applications must be listed as free. So developers have been assigning “expiration dates” on their beta products or their fully featured products so that people will have to buy them once the ability to do some comes out. This seems like a rather good idea, however it has easily been cracked and will remain to be that way. Essentially local variables are stored in most of the programs with dates that are being checked to the calenders current dates. Or a database is written to with the data of first execution and then checked. These are simple and minor patches to work around. The method could be fairly useful, however it must be implemented in the correct way. This is again where I restate my mantra, write secure code! Don’t rely on assuming people won’t look for weak links – they will always find them. Hopefully this doesn’t affect many of the products already released, though unless they are release with many new features they seem to have released a full-functional product with a minor hindrance of an expiration date.
One of the last schemes and probably the best used one thus far, proven by having yet to be cracked, is online activation codes. This is being used currently by IMPlus by shape-services. Essentially they tie a registration key to a person and/or device and allow them to enter it to register. This sends a signal to their website asking them if it’s valid or not, and will return a response. This allows them to keep track of who is using their product and most likely provides them with analytics for themselves too. They seem to have interweave this process very well into the program so it would be seemingly hard to patch. It would be impossible to create a key generator for this program since it’s being check server side. So one could theoretically generate a correct serial, however the serial will check it to their database and realize that it doesn’t exist or belongs to someone else. This is similar to cd-key checking of games, and it works rather well. This method is not bulletproof though. As you see their products on other platforms have been broken, so I’m sure it is only a matter of time before this one is. A downside to this type of protection scheme is that your burdened with running the server all the time. If it goes down? Well sorry purchasing customers, you can’t use your product right now! So you will forever need to run the service and be paying expenses for running it also. Though, bravo for withstanding the attacks I’m sure your getting from the scene teams in trying to crack your application. Shape-services undoubtedly has very knowledgeable and skill coders who practice good methods of writing secure code.
The very last type of protection scheme is by far the most bulletproof, however it comes with many downsides. By providing “lite” versions of your software you essentially cripple your software and often literally rip-out the functionality of some parts. This is often used in games which are listed as demos which only include level one of the game, etc. While this does work, in a sense, it is essentially uncrackable and unkeygennable… Though customers just do not like this, take a look at reviews and people essentially just don’t like it. “Why do I only have one level!?”, “Why would I pay for this garbage?!” To me at least, is just does not seem like a good model for selling a program. I understand the idea of it, but it doesn’t seem to normally work out well. Either people get sick of the game on the first level or don’t get enough of the game to get hooked. This leaves this with either a bad taste in their mouth or a sense of “I could live without that”. Honestly, how many games have to played that are captivating and challenging in the first level?
To summarize, nothing takes the cake like writing secure code, no matter which method of protection you choose. Name and serials to me, always seem like the most cost efficient and effective method to protecting applications, as long as they are done correctly and securely.
Also, later today I should be finished with the PatchTest application I posted exactly a week ago, so hopefully some other people have gotten a chance to take a look at it. So, until then… Write more secure code!
Recent Comments