Towards a hacker friendly mobile world

As a hacker there is one part of technology which is particularly
fascinating and this is communication technology. It is mind boggling to
think that you can reach a third of the worlds 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. Particularly the Internet, a
network intimately connected with computers, has taught us, that
machines can communicate, too. Not only that, 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 one could harness this technology for
your own purposes. Till 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 results 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 are valid for all modules. The one I have 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 ringtone. On UMTS
(or WCDMA) 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 2 or 3 pin connector
going to the battery (3rd 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 it's 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 the 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
micro-controllers. 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 problem 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 re-compile
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 micro-controller 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 micro-controllers are Harward designs with separate program and
data memories. The first usually even 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 micro-controllers 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 fully fledged Web-browser with only 2 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 solder-able packages are 512 Kilobytes. Anything
beyond that is either hard to get, difficult to drive with
micro-controllers, 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.