The first feature that is frequently being asked for is 64-bit Windows support: I have been in contact with the kind people over at ReactOS who will hopefully be able to sponsor DroidPad and ‘sign’ the 64-bit driver. This will eliminate the whole Windows issue of enabling ‘test mode’ associated with previous DroidPad versions.

The next request is for custom joystick layouts: the next version of the Android app will allow the user to put a file on the SD card describing a joystick, mouse or slideshow layout. I will provide examples of what to put in these files to make them work with DroidPad.

As for USB mode, the user must select ‘Debug mode’ from the ‘Applications’ menu in Settings on the phone as before, then find and install the necessary drivers (often on a CD that came with the phone) before DroidPad will recognise the device. Details on how to do this will most likely appear in the next Beta version.

If you would like to test this version then downloads are available below. If DroidPad does crash while running it would be very useful to file a bug report (either for the PC part or the Android part); I can then see where it went wrong and fix it.

Downloads

Android

The Android part can be downloaded from the Android Market – search for “DroidPad 2.0″. The old version doesn’t have to be uninstalled.

Please report bugs through the Android bug reporter.

Windows

NOTE: This new version doesn’t currently work with Windows 64-bit. If you have problems installing the drivers then this is most likely the cause.

First, the old version of DroidPad will have to be uninstalled (PPJoy is redundant and can be uninstalled too – if not prompted to do so during DroidPad’s uninstall, remove it now). Make sure the old version of DroidPad is completely removed from your PC before proceeding.

Next, download the new version (link below). This new version does not require PPJoy at all, and should install automatically.

Download DroidPad 2.0 Beta for Windows

Reporting Windows Bugs

If something goes wrong or doesn’t happen as expected, please file a bug through the PC bug reporter. If possible please attach the log files; on Windows XP they are located in C:\Documents and Settings\<Username>\Application Data\droidpad, on Windows 7 in C:\Users\<Username>\AppData\Roaming\droidpad.

Linux

DroidPad 2.0 for Ubuntu can be installed using the PPA ppa:w-shackleton/droidpad-daily. This contains latest versions of DroidPad and will be updated with the latest versions.

Installers for other distros aren’t currently provided however a source package can be downloaded here and built manually.

Bugs should also be reported through the PC bug reporter, however please say that the bug is being reported for Linux.

The download file

Firstly, the extra download file is a minimal version of a debian system – having the same system on each device makes it easier to ensure the same will happen on the same device.

When Network Spoofer is run, the file is loaded (mounted) on the phone to allow the files to be accessed. This is where almost all of the bugs with Network Spoofer not loading occur; for some reason some devices just won’t load the file. If you want to have a go at mounting the file on the phone, then this script is used to actually load it, and the variables used are set by the application itself before running the script.

One of the reasons this stage sometimes doesn’t work is that Android’s app2SD (applications on the SD card) uses this same method to load SD card applications, and this could be interfering on some phones.

Running programs inside the debian system

For programs to function correctly on this new system, a few system folders have to be mounted inside the new system – namely /dev, /proc and /sys. This is also done in the script mentioned above.

The unix command chroot is used to actually run programs inside the new debian system – it makes the program think it has a different ‘root’ (top) folder.

Setting the system up to run spoofs

Inside this new environment (where programs think they are actually running on a debian computer), the script /usr/local/bin/spoof is run. This script uses the phone settings given by the Android app (as well as some detected settings) to set up the phone, ready to start spoofing.

First, it starts arpspoof running in the background on the phone (line 97) which basically gets all internet traffic going first through the phone. The phone tells the victim computer that it is the router, and tells the router that it is the victim – this is called a ‘man in the middle’ attack.

To change information on websites, data travelling on port 80 needs to be redirected to something else (line 115) and then picked up by a proxy server which is started on the phone (line 112). The proxy server can then change or redirect whatever it wants to on the phone.

Changing data on websites

There are a set of scripts in the /rewriters folder in the debian image. Each one waits for URLs to be inputted (typed into it), then returns a new and potentially modified URL. The easiest way to add a new spoof is to add a new script (based off one of the others) along with a text file describing it (see one of the others for an example).

A link is created to the script to be used (line 111), or if multiple spoofs are used a script is created which chains the selected scripts together. There is an option in the configuration for the proxy which tells it to use the linked script to change URLs as they are asked for – this is the key feature of the proxy.

If data on the webpage is changed, the script may download the HTML file, change it and put it in the folder /var/www/images. This folder is visible on a webserver which is run on the phone (see the image flip script for an example)

The spoof is now running – the script then waits for an enter key press before stopping. It then stops the arp spoof, shuts down the proxy and the webserver, removes the port 80 redirect rule and finishes.

I hope this has explained the inner workings and will help people to expand the project, fix issues on certain devices and create more spoofs. If you have a feature that you’ve created / would like implementing, file a request / question or add your own branch of the code on the launchpad code hosting page.

Stage 1 (the code on the website)

For this stage, a Linux computer definitely helps. The Linux file command can reveal (misleadingly) a bit about the code once it is converted to binary. Also note that there is more to the code than is shown on the website – try to find more!

Using GDB to get a memory dump from the program is an easy way to get an answer once you’ve figured out what the code is.

Stage 2

This stage is less of a code cracking challenge, and more of a straight forward programming task. Very little information is provided about what you actually need to do in this stage, however it is useful to know that operand 1 is always an index of a register, starting at 0; even in commands such as movm, the memory address is taken from the selected register, then used to get the value in the memory.

The jmp commands which don’t specify the row of a segment always use cs (this is what it’s for). The jmp commands which specify a register should then also set cs.

The program is self modifying – the program first decodes another part, then runs it. Make sure your program can do this.

Stage 3

Download cygwin and run the program from within it. You need to make a file called ‘license.txt’ containing information which the program will use to give you the password.

Use a disassembler (such as IDA Pro free) to see what the program does. Try to find out what you need to put in license.txt to make it continue.

The extra numbers are located in the previous steps. Look for unused code in Stage 1 and unused numbers in Stage 2 to find numbers that might go here.

I hope these hints will help people having a go at this challenge without giving too much away.

The challenge is to write a Virtual Machine to interpret a block of code given in the instructions – once the program is interpreted, the solution appears in the memory of the virtual computer. The code itself firstly decrypts a section of the memory; this decrypted block is itself a program which is then run by the Virtual Machine.

Solution: Download [tar.gz] [source code repo]

The program can be built using Haskell’s cabal command.

For those who are interested or want to have a go with hexdumps, here is the output of this program:

310433aa40028003520072017301b250
3014c001800010100000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
3200750c310833324002800352007201
7303b200c3b000301bc001ff00000000
00000000000000000000000000000000
00007510010000000000000000000000
cc000000000000000000000000000000
7d1f15604d4d527d0e276d106d5a0656
4714420eb6b2b2e6ebb4838ed7e5d4d9
c3f08095f182829abd95a48d9a2b3069
4a6965551c7b691c6e04743521262f60
034e371e335439e6bab4a2ada4c595c8
c1e48aece7928be881f0ad98a4d0c08d
ac2252657e272b5a12610a017a6b1d67
474554202f6461373533373066653135
63343134386264346365656338363166
62646161352e65786520485454502f31
2e300000000000000000000000000000
377a07111f1d682532771e62235b4755
53301142f6f1b1e6c3ccf8c5e4ccc0d3
85fd9ae3e681b5bbd7cd87a3d36b366f
6f66553016455e09745c3f292b663d0d
02302835150915ddecb8e2fbd8cbd8d1
8bd582d99af192abe8a6d6d08caad294
cf454667207d44146b456d5403176062
555a4a6661115768750562367d02104b
08224232bae2b9e2d6b9ffc3e98a8fc1
8fe1b8a496f18f81b18d89ccd4787661
723e372356737179637c081120697a14
6805211e322759b7cfabddd5cc9793f2
e7c0ebffe9a3bfa1ab8bbb9e9e8ca0c1
9b5a2f2f4e4e00000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

The result (and the next stage) are hidden within this data.

Enjoy!

For these new features to work the latest version of the extra files needs to be downloaded.

This version also includes Busybox; this should fix quite a few of the bugs reported. Any log output which includes the text ‘applet not found’ should be fixed.

See the Main Page for more info.

Downloads available on the main page.

I’ve included a new spoof as well, however if there is anything new you’d like to see in this program (new spoofs etc.) then leave a comment below.

The latest version can be downloaded from the Android Market.

See the main project page for more info and downloads.