Archive for the coding Category
0
Compiling an Android Emulator Kernel for Loadable Kernel Modules

So you want to rootkit the emulator? These are rough notes I took while attempt to get this working on my own machine (OSX 10.8.5) – results may vary. According to random posts I’ve seen, OSX is a bit finicky and no one really gets it to work right – Ubuntu everything is apparently just peachy. You’ve been warned though, YMMV.
If on OSX, you must install libelf – this was the only dependency I was missing. If you don’t have this the build will randomly fail and not be exceptionally helpful about why.

Building the Kernel
Clone emulator kernel directory then get the branch of the kernel we want

git clone https://android.googlesource.com/kernel/goldfish

cd goldfish
git checkout -t origin/android-goldfish-2.6.29 -b goldfish

Before we build the kernel we must configure it, though we don’t want the default configuration (this doesn’t actually let the emulator boot) and we want to ensure LKM support is present. Note that the feature to load is seperate from the unload feature, you must enable both. Let’s first copy the configuration for goldfish_armv7_defconfig. Then manually change the LKM state (goldfish_armv7_defconfig will default to having modules enabled and loadable, but not unloadable) to any features we need.

make ARCH=arm goldfish_armv7_defconfig

make ARCH=arm menuconfig

If you are compiling on OSX, you will want to manually edit the .config file to not include CONFIG_NETFILTER, simply comment this line out before proceeding. You will be prompted to confirm this change prior to compiling as well. If you do not make this change you’ll see an issue similar to this appear;

make[2]: *** No rule to make target net/netfilter/xt_CONNMARK.o', needed by net/netfilter/built-in.o’. Stop.
make[1]: *** [net/netfilter] Error 2
make: *** [net] Error 2

Compile the kernel, modify the CROSS_COMPILE switch as necessary for your builders setup;

make ARCH=arm SUB_ARCH=arm CROSS_COMPILE=$ANDROID_NDK_ROOT/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/arm-linux-androideabi-

If you are unsure where to point CROSS_COMPILE, you can try below to help narrow it down, assuming you have

$ANDROID_NDK_ROOT set;
find $ANDROID_NDK_ROOT | grep ‘\-gcc$’

Making the Emulator use the Newly Compiled Kernel
The easiest way to use the kernel immediately is to just point an already existing AVD image at it via the emulator command;

emulator -kernel arch/arm/boot/zImage -avd -verbose

You don’t need -verbose, obviously, though it would be helpful the first time to watch for the potential segfault or if the kernel image was bad. If the “android” doesn’t appear in the emulator box and nothing is streaming to the console, you likely borked one of the above steps. You should try to enable the “Use Host GPU” setting for the avd as well, since this appears to drastically improve performance of the emulator for most MacBook Pros.
Another potential way to use the kernel is to copy the kernel from arch/arm/boot/zImage into one of your platforms, this will cause all AVDs using that platform to use the customer kernel. The path for that is something like $ANDROID_SDK_ROOT/system-images/android-17/armeabi-v7a/kernel-qem.

If you run into something like below (verbose output from emulator command, happen almost immediately);

emulator: Kernel parameters: qemu.gles=0 qemu=1 console=ttyS0 android.qemud=ttyS1 android.checkjni=1 ndns=3
emulator: Trace file name is not set

emulator: autoconfig: -scale 0.821094
Segmentation fault: 11

This is likely from some weirdness in the avd from not shutting down properly (or just using it, the emulator is horrid). The easiest way to recover is just kill it (rm -rf ~/.android/avd/*) and recreate the avd.

Making a LKM
Shortly I’ll post an example to github, but for now here is a very simple LKM that should compile fine.
Makefile, should be fully complete, you may need to change the path of both KERNEL_DIR and CCPATH;

The helloworld code for android_module;

Dump both of these into any directory and run make after making the appropriate changes. You should then have an android_module.ko file.

From here just push it to the emulator via adb, then use insmod/lsmod/rmmod as needed and enjoy. Depending on the time I have for the rest of the week, I’ll try to dump some kernel modules I’ve written and used for malware analysis on my github.

0
Ops, did I publish that in the AOSP?

A while back when grep’ing through the AOSP for package manager references, I noticed something weird;

What’s this directory? What is contained in it? Let’s look at the readme;

Ops! Did someone mean to publish this repo? It’s all a bunch of experimental and interesting code. Granted it’s a bit old now, but still very interesting to look at. Specifically there are what looks to be the precursor to fragments and ui testing automation, done and committed before the final work was committed to AOSP. There is also the DroidDreamCleaner utility which is interesting. While it was an fix for an old issue, it’s just interesting to see how Google coders handled the issue without having to reverse it. We can even see a “DreamThreater” application which looks like some work done to make an Android screen saver. Sadly not all this code can compile since it relies on some code which isn’t accessible to us and the released branches of AOSP. It seems this code may have been mistakenly committed to the public branch after the kernel.org mishaps, as it appears to have been made public after AOSP became available on Google’s own servers.

If you don’t have all of AOSP pulled, you can get it by just cloning the following repository;

Again, nothing ground breaking – but definitely an interest repository of code to take a look at, if not to see how Google coders work on “internal” code which isn’t released but to see their comments and documentation that is sometimes stripped from AOSP :)

0
Quickly setting up an Android emulator for fuzzing/hacking

Normally I like spending time fuzzing/causing segfaults with real devices, not sure why – maybe it’s just because it just feels more gratifying. Though recently for a small project at work, I need to be able to do multiple devices for longer periods of time and swap out different modules relatively fast. This would be a huge problem – but I wanted to automate it and do the least amount of work possible. A challenge that comes up sometimes with the somewhat stock phones I use for testing, is that some compiled modules/elf binaries never worked that well. Sometimes due to carrier modifications, sometimes due to Cyanogen modifications other times just due to me being stupid and compiling things horribly wrong. Since I just got my desktop machine all set up, it seemed like the perfect time to try and automate this on a box I could just SSH into and let run all the time!

After a quick bit of Googling, I didn’t see many instructions on how to modify emulator images fast. Lots of people said, generate an emulator, then change the system.img by mounting it, then restart the emulator and make sure it doesn’t overwrite changes. That’s a pain though, I don’t want to mount anything! Though this did remind me of building the AOSP which can product the system.img — perfect!

After making all my changes, some Dalvik changes and some Webkit changes, kicked off a full build via the normal commands;

While waiting for the compilation to finish – I prepped a “target platform” to build an emulator image for. To quickly do this I just copied the android-15 directory under the platforms directory of the sdk. This will give us the proper structure and files required while keeping the normal platform for android-15 intact.

Awesome, we copied over the system.img too the nessicary directory, lets just edit a few files so I don’t forget what this when I build my emulators. Open up the source.properties file and edit the version number to something you can remember, I just changed mine to say 4.0.3-hacked;

Now I can just create an emulator like normal and fire it up;

Now it just time to attach your fuzzing and other automated tools to the emulator.

20
An update on the Archos 5 Android rooting…
Penguin inside ;)

Penguin inside ;)

Progress has been quiet slow as of lately, albeit progress none the less though. As normal, I figured I’d attempt to document this so that anyone attempting to root devices in the future that might be similar to the Archos might have an easier time :)

Thus far when rooting phones we have been coming in contact with less protection. After gaining root we have been able to remount the partitions and edit them directly – making the changes persistent immediately. Though there is a fundamental difference with the Archos that comes into play. The Archos stores everything on a (maybe two or three?) flash chips. The partitions of the chips are like normal phones and mounted as read-only. The problem comes into play since what is mounted is not a filesystem, but a cramfs file. This cramfs file is what needs to be modified to create any changes to the system files.

So just modify the cramfs file, right? Nope – Archos caught you on this one. Simply modifying the cramfs, which is actually a “cramfs.secure” file will lead to a bad signature error. What the heck is that all about? Essentially when Archos creates a firmware update and flashes a new ‘androidroot.cramfs.secure‘ to the device. This file is signed with a signature of itself. Sadly we cannot recreate the signature for the file since it’s an RSA/MD5 signature of the contents. This means that they basically run a program after the have a androidroot.cramfs to append the signature like the following:

secure = RSA(MD5(cramfsFile)) + cramfsFile;

The RSA function uses a private key that we do not, and most likely will never have. Essentially in the bootloader there is a program called cramfschecker that does something like the following pseudo code:

if(RSADecrypt(signature) == MD5(file)) ? return goodFile : return badFile;

The RSADecrypt function uses a public key that we have found, but is no help to us.

Alright, know that we know what files need to get modified and how we are locked out of them, how do we actually get past this? This is where we have to get into modifying the kernel and boot loader. The flash memory is a little tricky but essentially is mapped out like the following:
[code]
mtd device - name ----- nickname - description
mtd0 ------- stage1 --- boot0 ---- bootloader part 1, also contains keystore
mtd1 ------- stage2 --- boot1 ---- bootloader part 2, also contains boot image
mtd2 ------- recovery - recovery - recovery kernel and recovery.cpio (filesystem)
mtd3 ------- init ----- init ----- init (main) kernel and init.cpio (filesystem)
[/code]
Now here is where the cool stuff comes into play. Stage1, among other things, checks the signature of stage2 to verify that it has not been modified. When stage2 begins it performs the same type of check on recovery and init. Inside recovery and init a program called cramfschecker is called, which checks the actual cramfs.secure files that we want to change. So the chain of trust is as follows:
Stage1 -> Stage2 -> recovery/init -> cramfs.secure
We need to modify Stage1 to accept any stage2, stage2 to accept any recovery/init and then remove the cramfschecker call so we can execute anything we’d like without worrying about if it is signed or not.

Now we know everything that needs to be done, so lets do it! Well, it’s sadly not that easy. We know how and can modify the cramfs files, that’s not hard. We can flash new a recovery/init, and even flash a new stage2. The problem is that we cannot currently flash a stage1 since it is marked as read-only after boot by the kernel. Yes, it is marked read-only, not locked – which if it where we could simply use a ‘flash_unlock‘ tool on it.

Currently I’ve been diving into the init kernel, which is at the beginning part of the init section, gzipped. This has been pretty tough trudging and I’ve enlisted the help of EiNSTeiN_. This is still pretty ugly stuff to look through though – we are basically looking for a small struct that make uses the kernel module to set the partition to read-only. The struct should look something like this:

Though this should all be GPLed code – since it is the kernel! Ah hah! That could make things so much easier. Sadly Archos has not yet posted the GPLed kernel source code for the Gen7 devices (which the Android model is).

After about two to three weeks of trying to track down someone, anyone with an Archos contact, or even just someone at Archos who isn’t outsourced technical support I finally got an answer! Prior to reaching this person I mainly got the run around, saying it will be up soon or that it is already posted. For some reason it also kept getting lost in the translation that I was requesting the GPLed *kernel* source code from the Archos 5 Android model. Someone in France apparently kept seeing “Android” and said “NO! It’s Apache, we don’t have to release that, Google hosts the source, goto them!” Finally I got a response, rather promptly I might add, from a USA Archos representative saying that Google hosts the code. After exchanging a few more emails they finally understood that I was requesting the Gen7 kernel source code, which is under the GPL license – NOT the Android source code which is under Apache. PHEW!

So the latest update is that we are essentially in a holding pattern, waiting for next week to come. I’ve been promised that the GPLed source code for the kernel will be posted by the end of next week, though I shouldn’t hold my breath until Friday. If it doesn’t appear on the site by Friday evening EST then I can start calling and complaining again… This time someone can actually be help responsible though, so I feel like it will actually happen. Once we get this code, it’s only a matter of time before EiNSTeiN_ and myself track down the right code which should help us in creating a program to patch the mtd partitions into being read/writable.

If you feel like you can help us with this, feel free to post here, email me or send a reply on twitter. Also if you just want to get the most updated information, I’d recommend you follow me on twitter @timstrazz.

11
State of the Android Archos… And Some More

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

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

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)

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!

2
Android Turrent Defense “Badge System” under the hood

Pew pew! Take that green circles!

Pew pew! Take that green circles!


A recent addition to the android market has been ATD, Android Turret Defense. This is a Plox-like game, though it has the “maze” strategy element combined in it. Strangely — it reminds me of a few old maps I used to play with friend for starcraft… Anyway I finally got around to beating it which isn’t too difficult once you get the hang of placing turrets and a get a decent strategy. At the end it awards you with a “badge code” — not sure exactly what the author intends to use this for, but I decided to take a look at how these are created. I was interested in how they where generated, and to see if people could easily replicate them, or if there would be any deterrents to keep people from just sharing them. Again, this is possibly completely useless information, since we have no idea what these codes will be used for. The could be used for tournaments, downloads, prizes – or maybe to just “give” you an image of a badge… As of right now we just don’t know.

Below is a dump of the function we will be analyzing with my comments in it (highlighted green), they should be pretty easy to follow:

.method private createBadgeCode()Ljava/lang/String;
// Date now = New Date();
new-instance v2,java/util/Date
invoke-direct {v2},java/util/Date/ ; ()V

// SimpleDateFormat dateFormat = new SimpleDateFormat(“yyMMddhhmm”);
new-instance v5,java/text/SimpleDateFormat
const-string v7,”yyMMddhhmm”
invoke-direct {v5,v7},java/text/SimpleDateFormat/ ; (Ljava/lang/String;)V

// StringBuilder raw = new StringBuilder();
new-instance v7,java/lang/StringBuilder
invoke-direct {v7},java/lang/StringBuilder/ ; ()V

// raw.append(dateFormat.format(now));
invoke-virtual {v5,v2},java/text/SimpleDateFormat/format ; format(Ljava/util/Date;)Ljava/lang/String;
move-result-object v8
invoke-virtual {v7,v8},java/lang/StringBuilder/append ; append(Ljava/lang/String;)Ljava/lang/StringBuilder;
move-result-object v7

// raw.append(difficulty);
iget v8,v12,tx/games/atd_world.difficulty I
invoke-virtual {v7,v8},java/lang/StringBuilder/append ; append(I)Ljava/lang/StringBuilder;
move-result-object v7

// raw.append(“tensaix2j”);
const-string v8,”tensaix2j”
invoke-virtual {v7,v8},java/lang/StringBuilder/append ; append(Ljava/lang/String;)Ljava/lang/StringBuilder;
move-result-object v7

// Bytes[] rawbytes = raw.toString.getBytes;
invoke-virtual {v7},java/lang/StringBuilder/toString ; toString()Ljava/lang/String;
move-result-object v4
invoke-virtual {v4},java/lang/String/getBytes ; getBytes()[B
move-result-object v0

/* Below code refined;
int sum = 0;

for(int i = 0; i < rawbytes.length(); i++)
sum += rawbytes[i];
*/

const/4 v6,0
const/4 v3,0
l3c1e:
// length = rawbytes.length();
array-length v7

// if( v3 > v7 ) goto: l3c30
if-ge v3,v7,l3c30

// v7 = rawbytes(v0);
aget-byte v7,v0,v3

// v6 += v7;
add-int/2addr v6,v7

// v3 ++;
add-int/lit8 v3,v3,1
goto l3c1e

l3c30:

// StringBuilder badge = new StringBuilder();
new-instance v7,java/lang/StringBuilder
invoke-direct {v7},java/lang/StringBuilder/ ; ()V

// v8 = Math.random();
invoke-static {},java/lang/Math/random ; random()D
nop
move-result-wide v8

// v10 = 4652007308841189376;
const-wide v10,4652007308841189376 ; 0x408f400000000000

// v8 = Math.round(v8*v10);
mul-double/2addr v8,v10

// I thought it only took one variable??
invoke-static {v8,v9},java/lang/Math/round ; round(D)J
move-result-wide v8

// v10 = 1000
const-wide/16 v10,1000

// v8 += v10;
add-long/2addr v8,v10

// badge.append(v8);
invoke-virtual {v7,v8,v9},java/lang/StringBuilder/append ; append(J)Ljava/lang/StringBuilder;
move-result-object v7

// badge.append(dateFormat.format(now));
invoke-virtual {v5,v2},java/text/SimpleDateFormat/format ; format(Ljava/util/Date;)Ljava/lang/String;
move-result-object v8
invoke-virtual {v7,v8},java/lang/StringBuilder/append ; append(Ljava/lang/String;)Ljava/lang/StringBuilder;
move-result-object v7

// badge.append(difficulty);
iget v8,v12,tx/games/atd_world.difficulty I
invoke-virtual {v7,v8},java/lang/StringBuilder/append ; append(I)Ljava/lang/StringBuilder;
move-result-object v7

// badge.append(sum);
invoke-virtual {v7,v6},java/lang/StringBuilder/append ; append(I)Ljava/lang/StringBuilder;
move-result-object v7

// return badge.toString();
invoke-virtual {v7},java/lang/StringBuilder/toString ; toString()Ljava/lang/String;
move-result-object v1
return-object v1
.end method

An example of the output of this function is; 1310090403121501473

Broken down the output looks like this;

1310090403121501473, (round(random * const)+1000

1310090403121501473, Date in yyMMddhhmm format.

1310090403121501473, “0” Difficulty, Noob = 0, Normal = 1, Pro = 3

1310090403121501473, sum of bytes (date + difficulty + “tensaix2″)

I’ll post more later if the “badge system” is every finished and released. Hopefully this serves as a decent example on how to reverse simple android programs… Enjoy!

3
Compiling cupcake with some changes for the G1 (HTC Dream)


Easier than baking a cake!

Easier than baking a cake!

Currently working on some random things on the Android OS source – which of course if I can get my little, “additions”, to work properly I’ll be releasing them. Though I was having a few problems getting the code to compile – so I figured I’d throw together this post just in case anyone else is having similar trouble.

Essentially in the post I was originally reading here, stated the following;

At the time of writing, the Android Dream build was broken. I needed to do the following to make it work:
* Several (relatively minor) changes in the Dream audio driver code to fix compilation issues.
* Copied libOmxCore.so to mydroid/out/target/product/dream/system/lib (this was a missing step in the Building for Dream documentation, and something that should be in the HTC provided script)

Well that wasn’t the problem I was getting though — the erorr I had been getting was actually:

In file included from frameworks/base/libs/audioflinger/AudioResamplerCubic.cpp:20:
system/core/include/cutils/log.h:68:1: warning: this is the location of the previous definition
target thumb C++: libaudioflinger <= frameworks/base/libs/audioflinger/AudioFlinger.cpp
make: *** No rule to make target out/target/product/dream/obj/lib/libaudio.so’, needed by out/target/product/dream/obj/SHARED_LIBRARIES/libaudioflinger_intermediates/LINKED/libaudioflinger.so’. Stop.

make: *** No rule to make target /tmp/dream/target/product/dream/obj/lib/libcamera.so', needed by /tmp/dream/target/product/dream/obj/SHARED_LIBRARIES/libcameraservice_intermediates/LINKED/libcameraservice.so’. Stop.

make: *** No rule to make target /tmp/dream/target/product/dream/obj/lib/libOmxCore.so', needed by /tmp/dream/target/product/dream/obj/SHARED_LIBRARIES/libopencorecommon_intermediates/LINKED/libopencorecommon.so’. Stop.

/media/other-storage/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/../lib/gcc/arm-eabi/4.2.1/../../../../arm-eabi/bin/ld: warning: librpc.so, needed by /tmp/dream/target/product/dream/obj/lib/libaudio.so, not found (try using -rpath or -rpath-link)

make: *** No rule to make target /tmp/dream/target/product/dream/system/lib/libaudio.so', needed by /tmp/dream/target/product/dream/system/lib/libaudioflinger.so’. Stop.

make: *** No rule to make target /tmp/dream/target/product/dream/system/lib/libcamera.so', needed by /tmp/dream/target/product/dream/system/lib/libcameraservice.so’. Stop.

make: *** No rule to make target /tmp/dream/target/product/dream/system/lib/libOmxCore.so', needed by /tmp/dream/target/product/dream/system/lib/libopencorecommon.so’. Stop.

(This list was compiled over multiple re-runs of make)

The simple fix was essentially what was stated in the original post, though it just took me a few minutes to figure this out. After running the locate command like a mad man and not finding anything on my developer machine, I finally reread *everything* and checked the device for the file – and there it was!

I just ended up throwing this into my extract-files.sh;
adb pull /system/lib/libaudio.so proprietary/libaudio.so
adb pull /system/lib/libcamera.so proprietary/libcamera.so
adb pull /system/lib/libOmxCore.so proprietary/libOmxCore.so
adb pull /system/lib/librpc.so proprietary/librpc.so
So my resulting file looked like this;
[code]
#!/bin/sh

mkdir -p proprietary
adb pull /system/etc/AudioFilter.csv proprietary/AudioFilter.csv
adb pull /system/etc/AudioPara4.csv proprietary/AudioPara4.csv
adb pull /system/etc/gps.conf proprietary/gps.conf
adb pull /system/bin/akmd proprietary/akmd
adb pull /system/lib/libhtc_ril.so proprietary/libhtc_ril.so
adb pull /system/lib/libaudioeq.so proprietary/libaudioeq.so
adb pull /system/lib/libqcamera.so proprietary/libqcamera.so
adb pull /system/lib/libaudio.so proprietary/libaudio.so
adb pull /system/lib/libcameraservice.so proprietary/libcameraservice.so
adb pull /system/lib/libcamera.so proprietary/libcamera.so
adb pull /system/lib/libOmxCore.so proprietary/libOmxCore.so
adb pull /system/lib/librpc.so proprietary/librpc.so
chmod 755 proprietary/akmd

adb pull /system/etc/wifi/Fw1251r1c.bin proprietary/Fw1251r1c.bin
adb pull /system/etc/wifi/tiwlan.ini proprietary/tiwlan.ini
[/code]

libaudio.so, libcameraservice.so, libcamera.so, libOmxCore.so, librpc.so then needed to be copied over to TARGET/dream/target/product/dream/obj/lib/ and also to the locked folder TARGET/dream/target/product/dream/system/lib/

Ta-da! After approximately 10 runs, it finally compiled for me… Hopefully this helps anyone who ran into the same problems as me.

1
“UnknownHostException” on AndroidOS

Alright so I’m doing some coding and kept running into this strange error while trying to connect to a site to perform a POST action.

12-01 18:27:52.175: WARN/System.err(764): java.net.UnknownHostException: Host is unresolved: www.strazzere.com:80

Obviously www.strazzere.com is a valid and resolvable host since you can read this post. This occurred whenever .connect() or .getOutputStream() was called. So after banging my head against a wall for a bit (ok more like an hour or so), I decided to try the fundamentals of troubleshooting.

Does the emulator have internet? Yeap – can connect to www.google.com
Can the emulator get the host www.strazzere.com? No… Strange – could have sworn it did though?

Apparently something must have happened with emulator upon switching connections or after hibernation. The solution seems to be to reboot the emulator. After doing so, I checked connection with www.strazzere.com and it worked fine. Yet another thing we can sing all-hail-reboot for I guess. Maybe the next version of the emulator will handle these better, though it’s not too bad as long as you know what is going on I guess.

Hopefully this article is found by some frustrated developer who hit the same wall I did!

9
Uniquely Identifying Android Devices with special permissions

Previously I wrote about how to uniquely identify Android devices without special permissions. However, maybe you want to get into the nitty-gritty and get an even more unique identifier for the device. This can be done, but you need special permissions. Essentially what I mean by “special permissions” is that the user will be prompted when installing that “this application tries to do this”. “This” referring to (in this specific case) Reading Phone State. This doesn’t mean it’s doing anything bad, however users might be turned off if your calculator wants to read the phones state etc. This is just how Google has set up the installation of applications, so that a user is properly notified of what an application is given permission to do.

What are the kind of identifiers we can get with this special permission? We can grade the “Device ID” which is the IMEI number, the phone number, Software Version (not sure if it’s currently being used?), Sim Serial Number and Subscriber ID.

That should be enough unique identifiers for anyone to come up with some hash! Heck, phone number alone should be enough since it would be readily known by a customer and easy to use.

To get these values add the following somewhere in your program;

Note that you MUST add permission access to android.permission.READ_PHONE_STATE otherwise your program will force close. This is added in the AndroidManifest.xml like the following;

On the emulator it will output things like the following;

DeviceId(IMEI) = 000000000000000
DeviceSoftwareVersion = null
Line1Number = 15555218135
SimSerialNumber = 89014103211118510720
SubscriberId(IMSI) = 310995000000000

One should also note that a real device currently returns “00” for Device Software Version, so it’s possible that this is something reserved for future use. These could all easily be used in some type of registration algorithm that you want to tie to a certain device. Also if you choose your identifiers properly you could allow your registration code to be complaint across all versions of your product. Using a phone number for example could allow a user to use your application on any phone they put their SIM card into. If you want to prevent this you could tie it to both the device ID and the phone number.

1 2 >