Towards a Hacker Friendly Mobile World

by Casandro

As a hacker, there is one part of technology which is particularly fascinating to me and this is communication technology.  It is mind boggling to think that you can reach a third of the world's population within seconds by punching a few digits into a small plastic box on your desk and lifting up the receiver.  (Or the other way round if you have a dial phone.)

But not only people can communicate.  The Internet, a network intimately connected with computers, has taught us that machines can communicate with themselves, too.  Not only that, but you can make machines and people communicate with each other.

Digital wireless communication networks certainly are one of the more interesting developments.  Although those were already deployed in the early-1990s, only now the prices have fallen enough to make ubiquitous communication a reality.

Obviously, it would be great if you could harness this technology for your own purposes.  Until recently this was very difficult.  You could buy special mobile stations from companies like Falcom which provided you with a simple modem-like interface.  I believe some of them even were MS-DOS compatible so you could run your own software.  However, when those were around, they were large and expensive.

Then many companies decided to take a normal mobile phone and place it into a new package.  This resulted in a small printed circuit board with some shielding.  Unfortunately, those boards still cost around $100, so they had to be replaceable.  Since space was an issue, the connectors often were tiny and exotic.  Few companies provided something you could solder at home.

Recently, prices have fallen enough for directly soldered modules to be feasible.  The distance between the "pins" is now large enough to allow hand soldering even by lesser skilled people like me and there is no need for an exotic connector.

Companies which sell those modules are Enfora and SIMCom, but there are probably many others.  My personal experience is with SIMCom as they have some quite easy to use modules.  However, most of what I will be talking about is valid for all modules.  The one I have the most experience with is the SIM900D, which is so far the most reliable I have seen.  First of all, it is fairly simple.  You connect a SIM card to the module (some modules come with an internal SIM card reader), a random length of wire as antenna, as well as the serial port, power source, and power button.  You press the button, wait a bit, and enter ATATATATATATAT on the terminal until you get an echo.  It's just like with any Hayes modem, in fact there is even auto-bauding.  Most of the commands are standardized, however some are not.

If you want to build a telephone, most modules will provide you with symmetrical analog connectors for audio in and out.  Those are designed to be directly connected to microphones and speakers.  In fact, many modules even have a "buzzer" output so you can get a ring tone.  On UMTS (or W-CDMA) modules, you can even have camera connectors and file systems.  Since those protocols are fairly bursty, one of the main problems is the power supply.  It needs to be able to deliver short surges of up to several amperes without the voltage dropping below a certain threshold.  Most suggested power supply designs have an inductor in series after the actual power supply.  Make sure its series resistance is low enough.  For mobile devices, however, most modules offer battery chargers which are able to charge lithium-ion batteries.  Those have a two or three pin connector going to the battery (third pin for temperature sensor) and a charge input pin.  Some even have a switched external voltage output, but, depending on what you want to do, you can also get your power from that battery.

On the software side, there is one problem.  AT commands are not very suitable for automatic processing.  Most commands end their output in an OK or ERROR line.  However, some commands also immediately respond with OK and later announce their result via something called an "Unsolicited Message."  Those messages can pop up at just about any time.  Many start with a +, while others like RING have no particular format.

One popular feature is what some Chinese companies call an "intrinsic TCP/IP stack."  It allows you to establish and use TCP connections or send and receive UDP packets without implementing TCP/IP yourself.  The quality of those stacks is quite diverse.  Some reboot constantly while others work fine.  Each vendor has its own commands to set up the connection.  Typically, you first need to connect to the GSM network, then the GPRS network, then you can establish a connection to the APN before you can do your TCP connection.  If you don't like that, you can also establish a PPP connection to the module and directly send packets to the APN.

So what does it take to make your own mobile phone?  Theoretically, most of those modules already have connections for keyboards and displays.  If you could get your own custom firmware onto such a module, you could use it directly.  However, this requires you to contact the manufacturer, and it's unclear if they will respond.  The more flexible route is to add an external application processor.  This would be a great opportunity for a software project.  How could one make an operating system for mobile phones which is truly hacker compatible?  Something perhaps a lot smaller than Linux, so you can use cheap low-power and easy to solder microcontrollers.  This would not only give you full control of the software, but also of the hardware.

There are already some "embedded" operating systems, both free and commercial.  One of the problems is that they rarely focus on the user.  You usually have a pre-compiled monolithic block which does what it's programmed to do.  If you want to change anything, you need to recompile that block.  This leaves you with nothing more than a stupid appliance.

There is no technical reason why it needs to be like this.  Home computers used to boot into a BASIC interpreter.  They used to store their software in a tokenized format which you could easily read using the LIST command.  You could easily edit your software and run it.  Just imagine having some powerful and small language which would make the same thing possible.  On boot-up it would read the source files from files on a file system, either in token or text form and store them in RAM.  The interpreter would interpret them, and you had a local de-compiler to translate the tokens from and to text.  Add in an editor and you have a hacker friendly system.

Speed probably is no issue anymore.  A C64 could execute about 100k instructions per second.  The most meager microcontroller you can reasonably buy can execute 16 million in the same time.  Of course, native code would be faster, but there are several problems:

1.)  Many microcontrollers are Harward designs with separate program and data memories.  The first usually is flash which you cannot rewrite very often.

2.)  Translating binary code back to something human readable is fairly complex.  In order to avoid bugs, it seems sensible to avoid any unneeded complexity.  However, you can always switch to binary code later, as all the software is available as source.

3.)  Those microcontrollers typically have no security features.  They have no boundary checking, they have no protected mode, not even an MMU.  With an interpreter, you can easily emulate those properties.

Pieces of code people generally would like to have as native code could always be implemented in the interpreter itself, or there could be some mechanism which allows you to execute code stored in a binary file.  Ideally, most of the software running would be interpreted and editable while it runs.  This seems to be impossible, however the Lisp machines as well as the experimental Erlang system from Erlang: The Movie (watch it, you won't regret it) showed that it could be done.

Networking with already existing services might be a bit more difficult.  After all, running a full-fledged web browser with only two kilobytes of RAM might be hard.  Contiki managed to do that by using "byte serving," a technique allowing you to ask for a small portion of an object from a web server.  However, since fixed computers are easily available, it might be a good idea to render the web page at a server you own.  A 320x240 monochrome frame only needs a few seconds to transmit at GPRS speeds, and you could load more into the frame buffer of the display for fast scrolling.  Such techniques are used, for example, by the Opera Mini browser.

Another route would be to emulate an already existing system.  However, this means you will have to have a lot of RAM.  The largest RAM chips you can get reliably in solderable packages are 512 kilobytes.  Anything beyond that is either hard to get, difficult to drive with microcontrollers, difficult to solder, or a combination of those.

This is, of course, just a collection of ideas.  Each one of them seems possible.  Combining them might create something amazing we can all share.  Let's work together to make the world a more hacker friendly place.