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

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.

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)

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!

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.FileNotFoundException;
import java.io.FileWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.io.UnsupportedEncodingException;
import java.net.InetAddress;
import java.net.MalformedURLException;
import java.net.Socket;
import java.net.URL;
import java.net.URLConnection;
import java.net.URLEncoder;

public class auth {

	// declare variables for use in gettig auth-token
	private final static String account = "yourAccount@gmail.com";
	private final static String password = "yourPassword";

	// service must be 'android' for market-data
	private final static String service = "android";

	public static void main(String[] args) throws UnsupportedEncodingException, MalformedURLException, IOException {

		// Prepare data for being posted
		String rdata = URLEncoder.encode("accountType", "UTF-8") + "=" + URLEncoder.encode("HOSTED_OR_GOOGLE", "UTF-8");
        rdata += "&" + URLEncoder.encode("Email", "UTF-8") + "=" + URLEncoder.encode(account, "UTF-8");
        rdata += "&" + URLEncoder.encode("Passwd", "UTF-8") + "=" + URLEncoder.encode(password, "UTF-8");
        rdata += "&" + URLEncoder.encode("service", "UTF-8") + "=" + URLEncoder.encode(service, "UTF-8");

      // Send data
      URL url = new URL("https://www.google.com/accounts/ClientLogin");
      URLConnection conn = url.openConnection();
      conn.setDoOutput(true);

      // Write post
      OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream());
      wr.write(rdata);
      wr.flush();

      // Get the response
      BufferedReader rd;
      String line;
      StringBuffer resp = new StringBuffer();
      try {
    	  rd = new BufferedReader(new InputStreamReader(conn.getInputStream()));
    	  while ((line = rd.readLine()) != null) {
    		  resp.append(line);
    		  System.out.println(line);
    	  }
    	  wr.close();
    	  rd.close();
      } catch (FileNotFoundException e1) {
    	  // Catch bad url
    	  System.out.println("Error: Bad url address!");
      } catch (IOException e1) {
    	  // Catch 403 (usually bad username or password
    	  if(e1.toString().contains("HTTP response code: 403"))
    		  System.out.println("Error: Forbidden response! Check username/password or service name.");
      }

      String token = resp.toString().substring(resp.toString().indexOf("Auth=")+5);

      try{
           //Create file
          FileWriter fstream = new FileWriter("auth.token");
              BufferedWriter out = new BufferedWriter(fstream);
          out.write(token);
          //Close the output stream
          out.close();
          }catch (Exception e){//Catch exception if any
           System.err.println("Error: " + e.getMessage());
          }
	}
}

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!