Mit diesem Blogpost habe ich mal eine völlig alternative Herangehensweise im Angebot, einen Speedport-Router unter einem nativen Linux-System zu flashen. Als Firmware lässt sich bei einem Speedport W 501V z.B. ein modifiziertes AVM FritzBox-Image oder Freetz einspielen. Die neue Software erweitert den Telekom Router um zahlreiche Funktionen.
Die üblichen Tutorials beschreiben eine Methode, mit der sich mittels einer Ubuntu-VM das speed2fritz Script “platformunabhängig” ausführen lässt oder mit verschiedenen Windows-Tools ein Image erstellt und geflasht werden kann. Mir war es anfangs nicht möglich, das Speed2Fritz Script nativ unter ArchLinux laufen zu lassen, da die Angeschlossenen Router nie erkannt wurden. Doch dank eines kleinen Patch lässt sich der ganze Prozess erheblich vereinfachen!
Als erstes wird speed2fritz aus dem AUR mit dem Packet-Wrapper yaourt kompiliert und installiert:

yaourt -S speed2fritz

Nach erfolgreicher Installation muss die Datei /opt/speed2fritz/includes/includefunctions angepasst werden, z.B. mit einem Texteditor wie vim oder nano. (Bei diesem Quellcodeausschnitt handelt es sich um die Revision 1453). Aus der Passage: [...]

Source code

[ $ISALICE ] && kernel_mtd5=$(mktemp -t mtd5_XXX) && dd if=${arg} of=${kernel_mtd5} bs=1k skip=7808 2> ${ddlog} &&\
    grep -q '0 bytes (0 B) copied' ${ddlog} && echo "--> Firmware size < 8MB." && unset ISALICE
      fi
    echo -e "${ECHO_BOLD}${ECHO_ROT}If no restart on its own, you must reboot your box
  fi
  [ $ISALICE ] || kernel_mtd1="${arg}"
  echo "Waiting for box to restart ..."
  while [ `ping $ping_params ${IPADDRESS} 2>&1 | grep -c 'nreachable'` != "0" ] ||\
 [ `ping $ping_params ${IPADDRESS} | grep 'receive' | awk '{ print $4 }'` == "1" ]; do
   echo -n "."
   sleep 1
  done
  while [ `ping $ping_params ${IPADDRESS} 2>&1 | grep -c 'nreachable'` != "0" ] ||\
 [ `ping $ping_params ${IPADDRESS} | grep 'receive' | awk '{ print $4 }'` == "0" ]; do
   echo -n "."
  done
  echo -e "\nInitiating file transfer of 'kernel.image' ...\n"
  echo "Please be patient, it takes about one minute to erase the mtd1 partition ..."
  [ $FORCE_CLEAR_FLASH ] && autoload=no || autoload=yes

Source code

[ $ISALICE ] && kernel_mtd5=$(mktemp -t mtd5_XXX) && dd if=${arg} of=${kernel_mtd5} bs=1k skip=7808 2> ${ddlog} &&\
    grep -q '0 bytes (0 B) copied' ${ddlog} && echo "--> Firmware size < 8MB." && unset ISALICE
      fi
 echo -e "${ECHO_BOLD}${ECHO_ROT}If no restart on its own, you must reboot your box again.${ECHO_END}\n"
  fi
  [ $ISALICE ] || kernel_mtd1="${arg}"
  echo "Waiting for box to shut down and restart ..."
  ping -i0.2 ${IPADDRESS}| while read line; do echo $line | grep -Fq "bytes" && break; done
  ping -i0.2 ${IPADDRESS}| while read line; do echo $line | grep -Fq "bytes" && break; done
  #while [ `ping $ping_params ${IPADDRESS} | grep 'receive' | awk '{ print $4 }'` == "1" ]; do
  # echo -n "."
  # sleep 1
  #done
  #while [ `ping $ping_params ${IPADDRESS} 2>&1 | grep -c 'nreachable'` != "0" ] ||\
  #[ `ping $ping_params ${IPADDRESS} | grep 'receive' | awk '{ print $4 }'` == "0" ]; do
  # echo -n "."
  #done
  echo -e "\nInitiating file transfer of 'kernel.image' ...\n"
  echo "Please be patient, it takes about one minute to erase the mtd1 partition ..."
  [ $FORCE_CLEAR_FLASH ] && autoload=no || autoload=yes

sudo speed2fritz

Im Menü kann jetzt das Modell ausgewählt werden (siehe Bild 1), ein Experten-Modus aktiviert werden (siehe Bild 2), weitere Einstellungen vorgenommen werden und die Konfiguration gespeichert werden (siehe Bild 3). Den Standard Dateinamen bestätigen (Enter) und mit Pfeiltaste nach rechts das Steuerelement “Exit” auswählen. Danach fertigt das Script ein Image an mit den gewünschten Eigenschaften (hierfür muss Internet verfügbar sein!).
Erster Schritt, download der original Firmware-Images bestätigen:

Images extracted… Press ‘ENTER’ to continue

Nach dem modifizieren der Firmware, das eigentliche Image erstellen mit:

Images extracted… Press ‘ENTER’ to continue

Nach einer kurzen Zeit sollte folgender Text erscheinen:

Search active netconnections on: eth0 eth1 eth2 eth3 eth4 eth5
Ethernet card found on: eth0
Parameter in use:
Eth eth0
IP 192.168.178.1
OEM avm
Produkt Fritz_Box_7140_AnnexA
HWResvison 93.1.1.0
kernel_args annex=B
Imagedirectory /opt/speed2fritz/Firmware.new

———————————————————————–
All settings will be removed, because clear mtd3 and mtd4 was selected!
———————————————————————–

Press ‘ENTER’ to proceed!

Erst jetzt kann der noch ausgeschaltete Speedport-Router an den Laptop via Ethernet-Kabel angeschlossen werden. Wichtig: Es sollte kein Netzwerkmanager wie Wicd oder NetworkManager im System aktiv sein, auch sollte kein Dhcp-Client auf dem Interface laufen!
Nachdem die Meldung mit “Enter” bestätigt wurde, kann das Netzteil am Router eingesteckt werden. Das Skript sollte nun die Firmware flashen und den Router neustarten. Sobald dieser erreichbar ist (in der Zeit nicht ausstecken!) unter 192.168.178.1, kann die Weboberfläche gestartet und das Skript beendet werden.

Die komplette Ausgabe des Shell-Scripts gibts hier.

Mit diesem Blogpost habe ich mal eine völlig alternative Herangehensweise im Angebot, einen Speedport-Router unter einem nativen Linux-System zu flashen. Als Firmware lässt sich bei einem Speedport W 501V z.B....

Hardware setup

Die Idee hinter der Hardware des CarPCs war, das Ganze möglichst kostengünstig mit bereits vorhandenen Teilen zu realisieren. Deshalb sind einige der Komponenten nicht wirklich optimal. Außerdem hatte ich mir zum Motto gemacht im Zweifelsfall die Dinge lieber selbst zusammenzubasteln als etwas fertiges zu kaufen.

Der Rechner selbst ist ein ASUS EeePC 1000H der wegen eines gesprungenen Display ausgemustert wurde. Um im Auto selbst Platz zu sparen wurde lediglich die Hauptplatine mit der Festplatte eingebaut. Die 160GB Festplatte ist mit SATA direkt auf der Platine angeschlossen und mit Heißkleb fixiert. Zur Kühlung des Netbooks wurde entfernt und durch eine Metallplatte, die auf dem Prozessor (Intel Atom) und dem Chipsatz der Motherboards aufliegt, ersetzt.

Das Auto in dem der CarPC verbaut wird ist ein Nissan Primera. Hier gibt es ein kleines, flaches Fach unter dem Lenkrad, in das die Platine hinein passt. Lediglich für die Stecker die rund um die Platine eingesteckt werden benötigen mehr Platz. In dem Plastik oberhalb des Fachs wurde zusätzlich ein kleiner Lüfter angebracht der die Luft über der Kühlungsmetallplatte in Bewegung hält. Die Kühlung ist auch ohne Kühlrippen ausreichend, das die Wärmeentwicklung so gering ist.

Die Stromversorgung gestaltete sich relativ kompliziert, da der EeePC zwar 12 V Eingangsspannung braucht aber die Spannung des Bordnetzes im Auto zu stark schwankt und der Rechner früher oder später ausgeht. Außerdem stellt sich das Problem wie starke Spannungsabfälle, wie etwa beim Anlassen des Motors, abgefangen werden, damit der Rechner weiterläuft. Ein handelsübliches ATX-Netzteil für den Autobetrieb kann an den EeePC nicht angeschlossen werden und der Originalakku ist auch nicht mehr vorhanden. Für einen eventuellen Neu- oder Nachbau des CarPCs ist hier wahrscheinlich das größte Verbesserungspotential vorhanden.
Letztendlich wird der Rechner von einem KFZ-Netzteil für Laptops mit konstanter 12V Spannung versorgt
Zur Überbrückung von Spannungeinbrüchen wurde zusätzlich ein kleiner 12V Bleiakku mit 3.4 Ah verbaut und mit einer Diode der Stromrückfluss ins Bordnetz verhindert.

Der Plan ist mit einem Microcontroller noch ein automatisches Zuschalten des zusätzlichen Akkus sowie das An-/Abschalten der Rechners mit Drehen des Zündschlüsseln zu verwirklichen.

Angeschlossen an der Rechner sind:

• 1x Line-Out (Klinke) zum Radio
• 1x USB Hub im vorderen Bereich des Autos
• 1x USB Hub im Kofferraum
• 1x USB für Touchscreen
• 1x VGA für Touchscreen

Der Bildschirm ist ein resistiver 8″ Touchscreen (lsusb -> Bus 003 Device 006: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen) mit einer nativen Auflösung von 1024×768 Pixeln. Eingelassen ist er in die Mittelconsole etwa auf Lenkrad Höhe. Für der Einbau des Touchscreens wurde das Radio nach unten in die Nähe des Schaltknüppels verschoben und die Lüftungsgitter wurden entfernt.

An den USB-Hub im Kofferaum ist ein GPS-Empfänger angeschlossen, der direkt unter der Heckscheibe befestigt und somit nicht durch die Karosserie behindert wird.

Software setup

Die Softwarebasis des CarPCs stellt eine unveränderte x86-ArchLinux Distribution dar, die nur “Core”-Software bereitstellt, also keine graphische Oberfläche oder unerwünschte, im Hintergrund laufende Daemons die garnicht benötigt werden. Das “Minimal”-Betriebssystem ist besonders praktisch, um eine sehr anpassungsfähige, von der Konfiguration nachvollziehbare und performance-orientierte Architektur unterhalb des eigentlichen XBMC-Frontends zu garantieren. Dieses Tutorial setzt eine mit Standarteinstellungen installierte ArchLinux-Version (linux>3.0,xbmc=10.1,xorg-server>1.11) voraus, auf dessen Installation hier aber nicht wieter eingegangen wird.

Wurde das Betriebssystem erfolgreich installiert, über LAN mit dem Internet verbunden und ist nach dem Root-Login einsatzbereit, kann die Konfiguration des Betriebssystems vorgenommen werden.

Mit einen der folgenden Befehle werden die Netzwerkeinstellungen gesetzt (entweder automatisch oder manuell) und danach extra Paketquellen in der Konfigurationsdatei des Paketmanagers hinzugefügt, indem vor der “[Extra]“- und der darunterstehenden “Include”-Zeile die “#”-Kommentarzeichen entfernt werden:

Source code

dhclient eth0
ifconfig eth0 <IP> && route add default gw <IP des Gateways> && sh -c "echo "nameserver 8.8.8.8" > /etc/resolv.conf"
vi /etc/pacman.conf

Darauf hin können alle Software-Pakete heruntergeladen und installiert werden, darunter unter anderem: Video-Treiber und X-Server (Touchtreiber: xf86-input-evdev), GPS-Daemon und dazu passendes Statusprogramm (gpsd, xgps), Netzwerkmanager und Bluetooth-Daemon (wicd, bluez), Audiotools (alsa-utils, libvorbis)und das Xbmc-Mediacenter. Der Pacman-Wrapper Yaourt wird benötigt um zusätzliche Programme aus dem “Arch User Repository” (AUR) herunterzuladen, unter anderem: Das freie Navigationssystem Navit, ein Touchscreen-Kalibrierungsprogramm (xinput_calibrator), ein Automount-Skript (udiskie) und ein Benachrichtigungsprogramm für ein mit Android betriebenes Smartphone (android-notifier-desktop):

Source code

pacman -Syu xorg wicd libvorbis sudo rfkill xbmc xorg-server xorg-xinit alsa-utils gpsd xgps base-devel xf86-input-evdev xf86-video-intel xorg-utils xorg-server-utils consolekit udev bluez
wget http://aur.archlinux.org/packages/package-query/package-query.tar.gz
tar zxvf package-query.tar.gz
cd package-query
makepkg -si
cd ..
wget http://aur.archlinux.org/packages/yaourt/yaourt.tar.gz
tar zxvf yaourt.tar.gz
cd yaourt
makepkg -si
cd ..
rm -r yaourt* package-query*
yaourt -S navit xinput_calibrator udiskie android-notifier-desktop

Jetzt wird ein normaler Benutzer ohne administrative Rechte erstellt (der auch Xbmc ausführen soll) und zusätzlich in die sudoers-Datei eingetragen, um bei bedarf wieder “Superuser”-Rechte zu bekommen. Eine Anleitung für ein Autologin findet man hier. Anmerkung: Anstatt vi kann auch z.B. nano als Editor benutzt werden. Vim muss jedoch erst mit dem Paketmanager Pacman installiert werden.

Source code

useradd carpc
gpasswd -a carpc audio video storage
vi /etc/sudoers

In /etc/sudoers nur folgende Zeile hinzufügen: (in diesem Beispiel heißt der Benutzer carpc!!)

/etc/sudoers

carpc ALL=(ALL) ALL
carpc ALL=(ALL) NOPASSWD: /sbin/poweroff,/sbin/shutdown,/usr/bin/killall,/usr/sbin/console-kit-daemon

Mit folgenden Befehlen werden wichtige Addons für XBMC installiert (aber noch nicht aktiviert! see here), wie z.B. ein Wicd-Frontend mit dem man sich innerhalb von XBMC mit WLAN-Netzwerken verbinden kann, sowie das eigentliche Touchscreen-Theme “touched”:

Source code

wget http://project-insanity.org/wp-content/uploads/2011/12/Script.linux_.wireless-0.0.5_offline_arch.zip
unzip script.linux.wireless-0.0.5_offline_arch.zip .xbmc/addons/
wget http://project-insanity.org/wp-content/uploads/2011/12/Skin.touched.tar.gz
unzip skin.touched.tar.gz .xbmc/addons/
rm Script.linux.wireless-0.0.5_offline_arch.zip Skin.touched.tar.gz # aufräumen

Für das Automount-Script udiskie muss folgende Datei angelegt werden (mit SU-Rechten) um allen Benutzern der Gruppe das automatische Einhängen von Wechseldatenträgern zu erlauben:

/etc/polkit-1/localauthority/50-local.d/10-udiskie.pkla

[Local Users]
Identity=unix-group:storage
Action=org.freedesktop.udisks.*
ResultAny=yes
ResultInactive=no
ResultActive=yes

Die Datei .Xinitrc dienst dazu, Befehle nach bzw. mit dem X-Server start auszuführen auf dem aktiven Display. Hier sind es z.B. Befehle die console-kit aufgrund eines Bugs neustarten müssen, damit udiskie funktioniert (optional). Vorallem aber, startet hier die Xbmc-Instanz.

~/.xinitrc

export SDL_MOUSE_RELATIVE=0
sudo killall console-kit-daemon &
sudo /usr/sbin/console-kit-daemon &
udiskie &
xbmc

Folgende Datei startet immer wieder den X-Server neu, falls dieser abstürzt. Dazu wird das Automount-Script udiskie gestartet und für XBMC eine SDL-Einstellung setzt, die fehler in der Touchsteuerung behebt.

~/.bash_profile

if [[ -z $DISPLAY && $(tty) = /dev/tty1 ]]; then
export SDL_MOUSE_RELATIVE=0
udiskie &
exec startx
fi

Für unseren Touchscreen wurde folgende Konfiguration benötigt. Die Kalibrierungswerte wurden mit dem Programm xinput_calibrator ermittelt, welches leider nach unserer Erfahrung einen Window-Manager benötigt wie Metacity um zuverlässig zu funktionieren (TTY1: export DISPLAY=:0 && xinput_calibrator && metacity –replace).

/etc/X11/xorg.conf.d/10-evdev.conf

Section "InputClass"
Identifier "evdev pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev keyboard catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev touchpad catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev tablet catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev touchscreen catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "InvertX" "on"
Option "InvertY" "on"
Option "Calibration" "103 1890 157 1911"
EndSection

Nach der Zeile “button/power)” in /etc/acpi/handler.sh folgende Zeile hinzufügen:

/etc/acpi/handler.sh

sudo /sbin/poweroff

/etc/X11/xorg.conf.d/keyboard.conf

Section "InputClass"
Identifier "Keyboard Defaults"
MatchIsKeyboard "yes"
Option "XkbLayout" "de"
EndSection

Source code

(sudo) alsactl store
vi /etc/rc.conf

Source code

DAEMONS=(syslog-ng dbus !network !dhcdbd !networkmanager !net-profiles wicd gpsd bluetooth acpid crond !asterisk)

Work in progress …

Die nächsten Schritte des Projektes sind:

• Eine Freisprechanlage, realisiert mit einem Asterisk-Server auf dem CarPC, der über WLAN (/Bluetooth?!) sich mit dem Android-Handy des Fahrers verbindet.
• Verbesserte Integration des Navigations-Systems in XBMC. (Navit oder iGO-Navigationssoftware mit Wine ausprobieren, wie hier schon erfolgreich getestet wurde.)
• Sprachausgabe für Navit.
• Alternative Setups mit Android 4.0 x84 und Win7 (CPOS CarPC-Software / iCT(inCar Terminal))
• Automount funktioniert leider noch nicht ganz.
• XBMC-Theme fertigstellen
• Gpsd.conf fehlt noch
• Android-Telefon automatisch mti Obexfs mounten und Multimediadateien in XBMC einbinden

Credits:

Original skin: http://forum.xbmc.org/showthread.php?t=105142 (thx Jezz_X!)
Original wicd-plugin: http://forum.xbmc.org/showthread.php?t=90410 (thx vikjon0!)

Anmerkungen:

Ich bitte darum, Kritiken, Verbesserungsvorschläge oder Alternativkonzepte in den Kommentarbereich zu schreiben. Es ist nicht einfach, einen Überblick über vorhandene CarPC-Projekte und dazugehörige Software im Internet zu finden, deswegen würden wir uns über jede Anregung freuen, danke.

Weiterführende Links:

• Car-PC.info – Webseite mit Forum, Wiki (Anleitungen) und einer Übersicht (zum Teil veraltet) zu verschiedener CarPC-Software.
• Android-Notifier Google-Code Projektseite
• XBMC.org – Webseite der freien Multimediacenter-Software
• Mp3Car.com – Forum mit vielen hilfreichen Beiträgen zum Thema CarPC
• Liste mit alternativen CarPC-Systemen sowie weitere Software
• nghost2 – Eine leider seit 2008 nicht mehr weiterentwickelte, native CarPC-Software. Benutzt SDL++-Library für die grafische Darstellung (SourceForge Projektseite)
• nghost3 – Ein relativ aktueller Prototyp und kompletter rewrite von nghost2 auf Basis von QT4 und Clutter (GitHub Projektseite)

Hardware setup Die Idee hinter der Hardware des CarPCs war, das Ganze möglichst kostengünstig mit bereits vorhandenen Teilen zu realisieren. Deshalb sind einige der Komponenten nicht wirklich optimal. Außerdem hatte...

Nebenbeierfindung: Die Lampomate! (CC-BY-SA 3.0 )

Wochenende Nr. 1: Zum ersten mal trafen wir uns, um die beim 27C3 gepriesene Opensource-Firmware OsmocomBB auf unserem Testphone Motorola C118 auszuprobieren. Eher unvorbereitet kommt es dazu, denn obwohl unser Kollege in Flensburg hardwaretechnisch gut ausgestattet ist, fehlt ihm der notwendige PL2303-chip um einen Adapter von Serial auf 2.5mm 3-poligen Klinkestecker (also known as T191 unlock cable) selber zu basteln. Konkret benötigt dieser Adapter auf der Seite des Handys eine Betriebsspannung von 3.3V. Ein kurzfristig bei MediaMarkt teuer erworbener Adapter (_ enter model name here _) von Serial auf USB sollte ungeachtet einer Betriebsspannung von 7.0V+ trotzdem unser Handy mit der Osmocom-Firmware flashen, jedoch ohne Erfolg. Nachdem wir uns #osmocom irc-channel hatten bestätigen lassen, dass unser Handy definitiv getoasted ist (oder zumindest die Datenpins der Headsetbuchse) war die letzte Rettung eine Samstag-Abend-Einkaufaktion dank Ebay Kleinanzeigen für ein Motorola C139. Denn wie sich herausstellte, war der MediaMarkt-USB-Adapter mit einem zusätzlichen MAX1797 Step-Up-Wandler ausgestattet, der sich von unserem Profilötmeister dedo ohne größere Komplikationen entfernen ließ. Ohne diesen Wandler konnten wir nun den Headsetstecker direkt an die TXD- und RXD-Connectors von PL2303 löten. Zum Test messten wir beim flashen von einer Firmware die Peaks der Betriebsspannung mit einem Multimeter, welche bei akzeptablen ~4V lagen. Das Kompilieren von OsmocomBB ging ohne Probleme und nach der Anleitung von rot13.org war es nun auch möglich, die Firmware auf das C139 zu flashen! Unglücklicherweise, hatten wir wohl genau mit diesem Model pech und waren nicht in der Lage eine Verbindung zu einer Mobilfunkzelle aufzubauen, geschweige denn mit Wireshark oder Tcpdump GSM-Traffic mitzuschneiden. Die Layer23-Applikation mobile blieb still, meldete aber auch keine ungewöhnlichen Fehler.

 
Wochenende Nr. 2: Dieses Wochenende ein neuer Versuch, diesmal unter ArchLinux mit einem selbst zusammengeschraubten Buildscript welches im Vergleich zur offiziellen Anleitung die aktuellste Version von dem offiziellen gcc Arm-Toolchain enthält. Somit gillt, ganz einfach und unkompliziert:

yaourt -S osmocombb-git kraken-git wireshark-gtk gnu-netcat

… und schon ist die komplette Suite unter /opt/osmocombb installiert (und auch das Programm “kraken” mit dem sich später der mit A5/1 verschlüsselte GSM-traffic entschlüsseln lässt). Nachdem das Handy mit dem USB-Adapter an den PC angeschlossen ist (bei uns zeigt lsusb den Adapter so an: Bus 002 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port), wird mit osmocon die Firmware wie folgt auf das Motorola-Handy geflashed:

sudo /opt/osmocombb/host/osmocon/osmocon -p /dev/ttyUSB0 -m c123 /opt/osmocombb/target/firmware/board/compal_e88/layer1.compalram.bin

Sollte es zur Problemen bei der Ausführung von layer1 geben, kann man auch den Parameter “-m c123xor” ausprobieren. Zumindest sollte, nachdem man den roten Auflegen-Knopf einmal kurz gedrückt hat, folgender output erscheinen:

(…)
got 1 bytes from modem, data looks like: 43 C
Received PROMPT2 from phone, starting download
(…)
handle_write(): 2555 bytes (47611/47611)
handle_write(): finished
(…)
got 1 bytes from modem, data looks like: 42 B
Received DOWNLOAD ACK from phone, your code is running now!

OSMOCOM Layer 1 (revision osmocon_v0.0.0-906-g5bbea93)
======================================================================
Device ID code: 0xb4fb
Device Version code: 0×0000
ARM ID code: 0xfff3
cDSP ID code: 0×0128
Die ID code: 3783221bd8039bd3
======================================================================
REG_DPLL=0×2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================

THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!!
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0×0001
DSP API Version: 0×0000 0×0000
Finishing download phase
DSP Download Status: 0×0002
DSP API Version: 0×3606 0×0000
LOST 752!

Parallel dazu wird jetzt die layer23-Applikation “mobile” gestartet mit:

sudo mkdir -p /root/.osmocom/bb/
sudo touch /root/.osmocom/bb/mobile.cfg
sudo /opt/osmocombb/host/layer23/src/mobile/mobile -i 127.0.0.1

Jetzt ist man schon in der Lage mit telnet (default-port 4247) auf die Osmocom-Shell zuzugreifen um EInstellungen vorzunehmen oder Verbindungsinformationen abzurufen. Mit dem Programm “cell_log” kann man sich die verfügbaren Provider und Basisstationen in der Umgebung anzeigen lassen:

/opt/osmocombb/host/layer23/src/misc/cell_log

Aber wir wollen ersteinmal Telefonate unserer O2-Handys aufzeichnen, dazu suchen wir uns die ARFCN von den bei uns verfügbaren O2-Zellen raus:

Um Trafficanalyse auf einem bestimmten Frequenzbereich durchzuführen, “fixen” wir layer23-ARFCN auf 676 (O2 Germany) mit folgendem Befehl:

/opt/osmocombb/host/layer23/src/misc/ccch_scan -a 676

Parallel dazu:

nc -u -l 4729 > /dev/null &
sudo wireshark -k -i lo -f ‘port 4729′

Weitere (unvollständige) Vorgehensweise:

cd /opt/kraken/
sudo wget http://opensource.srlabs.de/attachments/download/41/a51_table_torrents.tgz
sudo tar xvf a51_table_torrents.tgz
sudo aria2c *

Soweit so gut … Wir werden diesen Blogpost noch erweitern!

Tools:

Further reading: http://srlabs.de/research/decrypting_gsm/, http://srlabs.de/uncategorized/airprobe-how-to, http://bb.osmocom.org/trac/wiki/Sniffing/, http://cgit.osmocom.org/cgit/osmocom-bb/, http://security.osmocom.org/trac/, Vortrag vom 27c3 zu Angreifen von Handys meist via SMS, Vortrag vom 27c3 zu OsmocomBB, Noch einer der ein Motorola gehackt hat, [Video] Cracking A5 GSM encryption (HAR 2009)

Gloassar:
GSM-R: Global System for Mobile Communications – Rail(way) Ein in Deutschland von der DB Systel betriebenes Rangier- und Bahnsteuerungsfunk.
Ergänzungen::

http://lists.osmocom.org/pipermail/baseband-devel/2011-May/001909.html

URGENT:
need
Bus 002 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
for burst_ind

git clone
git checkout sylvain/burst_ind
git pull
make

Wochenende Nr. 1: Zum ersten mal trafen wir uns, um die beim 27C3 gepriesene Opensource-Firmware OsmocomBB auf unserem Testphone Motorola C118 auszuprobieren. Eher unvorbereitet kommt es dazu, denn obwohl unser...