Android from Scratch?

Aleksandar Kuktin akuktin at gmail.com
Sat Jun 22 08:35:25 PDT 2013


>On Sat, 22 Jun 2013 11:17:48 +0000
>Jason Daly <jason_daly at lavabit.com> wrote:
>
> [snip]
> 
> Any guidance here would be appreciated.
> 
> Thanks,
> Jason Daly

Aside from Cyanogenmod, there are VERY few places to look to. For the
most part, you will just have to make it all up yourself.

About a year ago, I too had a private project to implement a Unix-class
OS on my smartphone, but I also wanted to go deeper and completely
replace all software with my software. So far, the project has been
gravely unsucessfull, but I will write a bit about it, so that you (or
anyone else reading this) can get a jump-start (and maybe solve the
problem where I failed).

Basically, the first thing you need is total control over the device,
AKA root access. Some phones have a firmware which easily enables this
(or has granting that access as a feature), but some phones do not. If
your phone does not have root access, you will have to r00t it
yourself. Regarding my phone, I found that the /etc directory was
world-writable. Talk about security, right? The directory had a bunch
of scripts that were run as root during the boot process, so I used
that to crack my phone. I would imagine you will find similar obvious
holes in your phone. After all, the police/CIA/NSA need to have a way
to access your phone, right? So all Android phones probably have a
backdoor somewhere on them.

For terminal access, I used:
https://github.com/jackpal/Android-Terminal-Emulator . The github
repository has a pre-built application, so you can have it without
registering your phone with Google (a big no-no for all privacy freaks
out there).

The next step, and the one on which I failed, was getting a proof of
life. Basically, the idea is to verify that you can boot your userland
and therefore verify that you have the capacity to hack the phone.
After that, the objective would be to change the kernel, thus having
your userland and kernel. After that, I planned to also change the
underlying firmware because the firmware had the FOTA capability. FOTA
stands for "Flash-Over-The-Air", basically, the carrier or the CIA/NSA
or their cronies or whomever have a built-in backdoor for your phone
and can undo your work at a moments notice.

However, I grinded to a halt when it was time to prove the ability to
boot a random userland.

All Android phones have an internal non-volatile memory. Unless your
phone is special, this memory can be accessed from the userland. How
exactly, varies from phone to phone. You will probably find it as an
array of flash memory devices, in my case under /dev/mtd. So I
had /dev/mtd/mtd0, /dev/mtd/mtd1 and so on. There is also a descriptor
file for these, maybe somewhere under /proc, I don't remember anymore.

Anyhow, once you locate the access points for the internal memory, you
can do what I did and just use `cat' to copy them on the SD card and
then from the SD card to your desktop/laptop for further analisys. As
far as writing stuff into the phones internal memory, you will need a
more specialized program for that. Basically, you need a program
specialized in writing raw flash storage devices. Using a plain `cat'
to write the device will fail miserably. I have not tried using `dd'.

Among the many partitions of the internal memory, there is the "boot"
partition and also the "recovery" partition. Both hold the kernel and
the init filesystem and therefore both can be used to boot the system.
The process is, therefore, to download the recovery partition from your
phone, change its initfs, then upload the changed one back and use your
phones method of recovery booting to boot into the alternative OS.

This is the step I failed because I was unable to boot the recovery
partition except once, confusingly. I only tried various esoteric
button press combinations, Cyanogenmod also has a program which is
supposed to be able to boot the recovery partition with software means,
but I never tried it.

Above, I mentioned the idea of an alternative OS. Because you have only
one phone which you absolutely must not brick, it is prudent to first
build the new OS in paralel with the existing one (for example,
contained in a file on the original OS-es filesystem) and then, when
everything has been proven to work, just swap the two systems.

Hacking an alternative userland will probably not be a problem for an
LFS-er. However, the problems begin to mount, and very rapidly, when
you dive lower. Even though Android is supposed to be "open-source", it
is suprisingly difficult to find kernel sources that were used in
compiling the kernel running on the device in your hand. The closest I
ever got to my kernel's sources was here: https://www.codeaurora.org/,
but I never found them.

The FOTA firmware is an EVEN bigger problem. Being firmware, it is
highly dependant on the underlying hardware which, for you, is pretty
much a black box. Things are a little better if you somehow find a
datasheet for your systems chip in some dark and God-forsaken part of
the Internet, but even then they are not much better. For the most
part, the analisys of the FOTA partition of my phones internal memory
showed:
1. like the master flash memory image, the FOTA partition is
   partitioned.
2. it has an obvious kernel-userland separation. No definitive proof
   was uncovered of filesystems being present.
3. it has a bootloader.
4. what it actually *IS* is the complete implementation of a mobile
   phone. It appears that the Android's Linux kernel uses the FOTA as
   its worker and is otherwise completely powerless.

I also uncovered several very strong leads as to what the FOTA-s kernel
is in my case. It appears to be some kind of "Wombat", "Wombat" being a
real-time OS kernel designed specifically for mobile phones. If you can
believe it, it too is open-source but, ofcourse, good luck finding the
source. Although I tried figuring out what the FOTA userland is
consisting of, I ultimately gave up.

/******************************************************/

Nowdays, I have just scrapped the whole "buy an Android phone of the
shelf and then install LFS on it" approach. For different reasons, I
recently began moving into FPGA-s and that opened up a VERY interesting
opportunity I am certain to eventually exploit. Here's what it is:

Make your own phone.

FPGA manufacturers make and sell a variety of chips that already have
an ARM CPU embedded in them. I am certain that with a little practice
one would be able to use such chips to implement working brains of a
smartphone. There already exist open source GSM software
implementations and it probably won't be a big problem to implement
hardware that such software can exploit. Radio equipment itself may be
a problem, depending on the timing issues. But there must be at least
one business out there that makes ready-to-use GSM radios (modems ?).

So, my current approach to creating a custom phone can now be best
described as "buy an Android phone off the shelf, rip it apart, solder
the new chip in the place of the old one, put it back together
and then install LFS on it".

It's a long shot, I know. But only such shots can guarrantie you safety
in the cyberpunk world we now find ourselves living in.

-- 
You don't need an AI for a robot uprising.
Humans will do just fine.
                     --Skynet



More information about the lfs-chat mailing list