List of devices attached
???????????? no permissions

This posting is about (1) granting ourselves permissions and (2) finding out that the Fairphone has a chipset from Mediatek, one of the biggest fabric-less semiconductor companies.

Mediatek conquered the market already in the age of feature phones (you know, these mostly touchscreen-less mobile phones with a physical numpad and monochrome displays). Mediatek was one of the factors why mobile phones became so cheap and wide-spread, because Mediatek had the idea of packaging software and hardware together. Before Android and iOS made the App hype emerge, Mediatek let the Shanzhai phenomenon happen by selling a platform, not only a single chip. The hardware was shipped with a reference design and software that allowed customization. This way Shanzhai vendors emerged for example in China, providing farmers and migration workers with cheap but somehow fancy cell phones. The Shanzhai vendors were kind of unofficial vendors, mostly family-driven. They imitated the look of major brands and customized the features to their needs and the needs of their relatives.

Why ADB?
Before going into the issue with ADB: Why would you want to make ADB work at all? Here is a list of ADB commands that I find useful:

• adb install /path/to/apk/myApp.apk
  Install the App myApp.apk directly to the device, for example if you develop your own app and want to install it from the command line.
• adb uninstall packagename
  Uninstall a particular app. You need to know the package name (jump to list items further to see how to get a list of all package names)
• adb shell
  Gives you a terminal to your device (which acts similar to a linux terminal, but with restricted commands). That’s one of the most powerful tools to tinker with your Android system!
• adb shell pm list packages
  Lists all the packages that are installed on your phone
• adb shell input text LONG TEXT YOU WANT TO INPUT
  Inserts a text into the currently focused text field (useful if you need to type long URLs)
• adb push fromDesktop.txt toDevice.txt
  copies the file fromDesktop.txt on the desktop to the device with the filename toDevice.txt
• adb pull fromDevice.txt /home/users/diebin/coolStuff.txt
  the other way around: from Phone to Desktop

Further commands can be found in the official developers page of Android.

Permission denied?

First things first. Why don’t we have permission to access the Fairphone? That’s not fair. The reason is that as normal user in Ubuntu we don’t have the permission to access the device out of the box.  Let’s fix it:
The blog “rechtzeit” gave us the means to proceed further:

1. Ubuntu allows to view verbose information on the devices that are connected via USB with the following command:
   lsusb
2. The relevant line for the Fairphone is:

   Bus 001 Device 010: ID 0bb4:0c03 High Tech Computer Corp.
   You can extract the following information from this line:
   Vendor ID 0bb4
Device ID 0c03
Bus    Nr 001
Device Nr 010

3. Next, gather more information by using the busname 001 and the device number 010:
   udevadm info --attribute-walk --name=/dev/bus/usb/001/010
   This gives:
   looking at device '/devices/pci0000:00/0000:00:1a.7/usb1/1-5':
   KERNEL=="1-5"
   SUBSYSTEM=="usb"
   DRIVER=="usb"
   ATTR{configuration}==""
   ATTR{bNumInterfaces}==" 2"
   ATTR{bConfigurationValue}=="1"
   ATTR{bmAttributes}=="c0"
   ATTR{bMaxPower}=="500mA"
   ATTR{urbnum}=="1608"
   ATTR{idVendor}=="0bb4"
   ATTR{idProduct}=="0c03"
   ATTR{bcdDevice}=="0255"
   ATTR{bDeviceClass}=="00"
   ATTR{bDeviceSubClass}=="00"
   ATTR{bDeviceProtocol}=="00"
   ATTR{bNumConfigurations}=="1"
   ATTR{bMaxPacketSize0}=="64"
   ATTR{speed}=="480"
   ATTR{busnum}=="1"
   ATTR{devnum}=="12"
   ATTR{devpath}=="5"
   ATTR{version}==" 2.00"
   ATTR{maxchild}=="0"
   ATTR{quirks}=="0x0"
   ATTR{avoid_reset_quirk}=="0"
   ATTR{authorized}=="1"
   ATTR{manufacturer}=="MediaTek"
   ATTR{product}=="MT65xx Android Phone"
   ATTR{serial}=="0123456789ABCDEF"

   My personal translation of this long list is:
   Product: MT65xx Android Phone
   Manufacturer: MediaTek
   Serialnumber: 0123456789ABCDEF (looks kind of dummy)
   Hm, why MediaTek? I googled around and found: Indeed, Fairphone, uses a Mediatek 6589 chipset – with Quadcore CPU btw!

   Intermezzo: MediaTek and platformization before Android and iOS

   I was not really following the whole Fairphone assembly process, I only briefly read their newsletters. What about this company? Mediatek is a Taiwanese company. Of course they have a corporate responsibility subpage. Not yet sure, what that means for the people who produce the chipsets. Especially, since Mediatek is a fabless company, that means they do not have fabrics and assembly lines. One can assume that the dirty work is outsourced in order to afford corporate responsibility.

   Moreoever, what I have found after some web research is an interesting article about platformization on the hardware level: We all know operating systems as platforms. On the desktop, it was Mac OS X or Microsoft Windows. On the smartphone, it was iOS and Android. But those platforms rely on smartphone hardware. One essential physical part of a mobile phone was the baseband processor, a chip that processes signals in order to establish wireless connection between the phone and the carrier provider stations. Over time the vendors who produced the baseband processors were able to sell a set of chips (chipset) that has embedded wifi, graphical processor units, system memory, etc included. So everything comes from one vendor. The major vendors of mobile chipsets are Broadcom, Qualcomm, and… MediaTek. I have this information from the references article above, written by Jonathan Goldberg (UK). He actually refers to Professor Willy C. Shih at Harvard University. To judge from Shih’s profile, he has quite some experience in the hardware and software field (from semiconductors to Java to intellectua property disputes ) and now transmits it in MBA programs at Harvard. Research focus is on competitive dynamics and multi-country production in technology. Unfortunately his papers are not available for free. But I found others who cite his papers about MediaTek. For example “The Evolution of China’s Mobile phone Industry and good-enough Innovation“.

   Before the arrival of smartphones, bottom-up innovation was happening in Chinas production of mobile phones. Those phones were called Shanzhai phones. Shanzhai refers to kind of family-based non-official manufacturers that produce imitations of well-branded products, but low-cost and with a lot of variations and customizations. MediaTek’s baseband was increasingly incorporated in such Shanzhai phones. After the rise of smartphones, the trend is apparently towards bigger and official vendors, but MediaTek still plays a big role, as we can see in the Fairphone. But who actually produced the hardware that is now lying on my desk? Let’s keep this for another article and move on

   Let’s give ourselves the permission to access our own device

4. Now we need to add a rule to the system such that UDEV (the device manager) knows that it can give us (and ADB) access to the device:
   sudo vi /etc/udev/rules.d/99-android.rules

   Add the following content:
   SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", OWNER="yourUsername" GROUP="yourGroupProbablySameAsUsername", MODE="666"

   The blog ‘rechtzeit’ mentioned
   SYSFS{idVendor}
instead of
ATTR{idVendor}.

   But this would not identify the device in my case. You need to compare against the output of udevadm in step 3. The line above worked for me.

5. Reconnect the device, and check if the permissions are now properly set:
   ls -l /dev/bus/usb/01/010
   The effect of those 5 steps is, that instead of just root having the permissions of accessing the device, also the user and group have.
   In other words, the output of the ls command line should be:
   
crw-rw-rw- 1 yourUsername yourGroup 189, 12 Jän 18 17:20 /dev/bus/usb/001/010

   rather than:
   
crw-rw-r-- 1 root root 189, 11 Jän 18 17:14 /dev/bus/usb/001/010
6. Try again adb devices:
   List of devices attached
0123456789ABCDEF    device

   Voilà! We granted ourselves the permissions we need to exercise the possibilities that the Fairphone offers, together with ADB.

Warum überhaupt HTTPS? Weil über HTTP alles unverschlüsselt gesendet wird. Wenn du ein Passwort eingibst, das nicht oder höchstens base64-encoded gesendet wird, dann kann im Grunde jede_r dein Passwort sehen. Bei Cookies ist es ähnlich, da kann auch fast jede_r deine schon eingeloggte Identität annehmen, was vor ein paar Jahren die Firesheep-Extension ganz schön gezeigt hat. Diese Schwachstellen waren Sicherheitsexpert_innen seit Jahrzehnten bekannt, aber erst seit wenigen Jahren haben auch die ganz großen Fische (Google, Facebook, …) reagiert und fast ganz auf HTTPS umgestellt.

[Update nach Hinweis: Aber natürlich sind nicht nur das unverschlüsselte Senden von Passwort und Cookies problematisch, und die damit verbundene Möglichkeit des Identitätsdiebstahls – es geht ja prinzipiell auch darum, dass keine_r – gleich Mensch oder Maschine – mitlesen kann, wenn er_sie die Verbindung abhört. Weder die stalkende Netzwerkadministration noch unser geliebter Staat, der ja eh nur unser Bestes will, wenn er deine oder meine Privatsphäre verletzt…]

Ein Problem, welches sich aber auch durch die Nutzung einer CA nicht ganz lösen lässt, sind sogenannte Man-in-the-Middle (MITM) Angriffe. Zwar hilft es schon, wenn ein Server von einer CA zertifiziert wurde (insofern es das vorhin beschriebene Usability-Problem löst und das Abfangen von SSL-Zertifikaten zumindest ein bisschen erschwert), aber dieses blinde Vertrauen in die Autorität ist ein potenzielles Risiko, welches dir als Benutzer_in des Webs bewusst sein sollte. Das Perspectives Project, versucht dieses potenzielle Problem zu lösen, indem es sich nicht auf das verlässt, was dein Browser sagt, sondern die Entscheidung, ob ein Zertifikat jetzt gültig sein sollte, ein bisschen demokratisiert.

Da ich mittlerweile wegen dem Studium vieles an den unterschiedlichsten Rechnern mache und ich auch keine Lust hatte, mich bei der sich daraus ergebenden Vielfalt der graphischen (und nicht graphischen) Oberflächen, mit denen ich so tagtäglich konfrontiert bin, mir unterschiedliche Programmoberflächen anzutun, habe ich gedacht, dass es doch auch ein IRC-Clienten für die Kommandozeile geben müsste.

Gefunden hatte ich zunächst ircII, was meinen anfänglichen Bedarf (ein simpler IRC-Client, mit dem ich mich verbinden und mit anderen kommunizieren kann) durchaus erfüllte. Allerdings habe ich nach ein paar Tagen gemerkt, dass der Client ein bisschen zu simpel war und sich auch nicht einfach (wenn überhaupt) so konfigurieren ließ, wie ich es wollte.

Nach einer kurzen Recherche war ich dann mit zwei auf ircII aufbauenden Clienten konfrontiert (BitchX und EPIC), die mehr Konfigurationsspielraum versprachen. Die (recht spärliche) Dokumentation der beiden hat aber zum Glück meine Lust die Software meinen Wünschen anzupassen sofort getötet, so dass ich der Empfehlung eines Kollegen folgen konnte und irssi ausprobieren konnte, was mich von den Standardeinstellungen gleich so überzeugt hat, dass ich mir nicht einmal die Dokumentation durchlesen musste.

Ein einfaches irssi -c irc.freenode.net -n username reicht und ich bin schon verbunden, dann /join #bin und ich bin schon im richtigen Channel. Und kann chatten (bzw. auch bot-like idlen).