Profile cover photo
Profile photo
Johannes Zweng
Curious, interested in technology , open minded...
Curious, interested in technology , open minded...
Johannes's interests
View all
Johannes's posts

Post has attachment
My Nitrokey Pro has arrived

I was looking forward to receive my Nitrokey Pro ( After using the Yubikey Nano for some time now I was curious about the Nitrokey Pro as its hardware and firmware are both open source:


On the inside the Nitrokey Pro seems to be a PC/SC compatible USB smartcard reader holding a Micro-SIM sized (15 mm × 12 mm) smartcard.

The smartcatd seems to contain an OpenPGP compatible applet, as well as some other applet to perform the TOTP ( and HOTP ( operations, but I haven't looked yet into this in detail.

Below you find some pictures after I have opened the case (I placed the YubiKey Neo only for size comparison also there).

#Nitrokey #NitrokeyPro

20 Photos - View album

Post has attachment
No Open Mobile API on Google Pixel phones:

As Google did not include the 3rd party library "Open Mobile API" - which is needed to access the Secure Elements in SIM cards - in its Nexus devices I was curious if this is also the case with the new Pixel devices.

I downloaded Pixel and Pixel XL System image from the link in this thread:

The system images of both devices do not contain the "Open Mobile API". Without this API apps cannot access the Secure Element within a UICC (SIM card).

This means payment apps (or other apps) which use the SIM card as storage for their secure keys (Secure Element) will not work out of the box with the pixel devices (for example here in Austria the "Bankcard Mobil" aka "Bankomatkarte mobil").

If it will ever be possible to make it work by manually installing (flashing) these API (as I described in earlier postings for the Nexus 6) depends on the hardware of the phones. Besides the software (Open Mobile API) the phones would also need a special single wire connection (see also: between the UICC (SIM card slot) and the NFC controller chip (one pin of the SIM card must be physically connected to a special pin of the NFC chip). If this SWP connection is not present, it will be impossible to use NFC applications backed by the UICC Secure Element on these phones.

Host Card Emulation:
This has nothing to do with HCE (host card emulation). HCE apps simulate a NFC smartcard totally in software (without a physical Secure Element in the phone or SIM card) and get their data from a secure backend (cloud services). Examples for this kind of apps are Wirecard's payment app "boon" (at least the version here in Austria) and AFAIK also Android Pay. These type of apps will work on all modern stock Android versions.

Some of the build properties extracted from the system images:

Pixel XL: Sep 8 18:55:20 UTC 2016
ro.product.model=Pixel XL

Pixel: Sep 8 18:52:11 UTC 2016

Post has attachment
TL;DR: Bank Austria Automaten restoren defekte Magnetstreifen

Ich habe seit längerer Zeit das Problem, dass meine Karte zwar an allen Kassen und Bankomaten in Österreich funktioniert, nur an den Foyer-Automaten meiner eigenen Bank nicht ("Karte ungültig oder defekt").

Das Problem dürfte am Magnetstreifen liegen, den ich vermutlich unabsichtlich auf meiner Karte beschädigt habe. Meine Vermutung bisher ist, dass die Bank kundenspezifische Daten auf Track-3 des Magstripes speichert, die bei den bank-eigenen Foyerautomaten gelesen werden.

Beim Bezahlen an Kassen oder anderen Bankomaten ist das egal, denn da kommt nur der EMV Chip zum Einsatz.

Für mich als Kunde natürlich blöd, denn ich habe die letzten Monate immer aktiv die Automaten meiner eigenen Bank gemieden, wenn ich Bargeld beheben wollte.

Gestern habe ich es wieder einmal probiert und festgestellt, dass zwar wieder eine Fehlermeldung kommt, aber danach der Magnetstreifen wieder restored wird. Bei einem neuerlichen Versuch kam dann kein Fehler mehr.

Stellt sich die Frage:
Welche Daten stehen da jetzt eigentlich drauf? Offensichtlich kann der Automat die Daten ohnehin aus dem Backend holen und zum Abheben bräuchte es ja sowieso nur den EMV Chip. Wozu wird da der Magnetstreifen überhaupt benötigt?

Post has attachment
Flickercode Testpage

Ich hab meine Testseite zum Herumspielen mit den CardTAN Flickercodes nun hier online gestellt:
Sollte auch auf Mobilgeräten halbwegs funktionieren.

Wenn man "Show all details" anklickt, wird im Detail angezeigt, wie sich der Flickercode zusammensetzt (am besten dazu das Interval "ms per step" etwas größer stellen, dann sieht man schön, wie der Flickercode Schritt für Schritt funktioniert).

#cardTAN #flickercode #onlinebanking


Post has attachment
Fun with a CardTAN Reader.. :-)

Mein CardTAN Reader ist gekommen und ich hatte heute Zeit mich ein wenig mit dem "Flicker-Code" (dieser "flackernde" Code zum Übertragen der Transaktionsdaten von der OnlineBanking-Webseite auf den CardReader) auseinanderzusetzen.

Ich habe mir dazu eine kleine Testseite gebaut und versucht, mehr über das verwendete Protokoll herauszufinden. Jetzt weiß ich zumindest mal, wie die Daten von der Banking Webseite in den CardTAN Generator übertragen werden.

Nächster Schritt ist herauszufinden, wie die Kommunikation zwischen CardTAN Generator und Bankkarte im Detail funktioniert. Mehr Infos folgen hoffentlich demnächst (wenn ich Zeit finde)..

#OnlineBanking #CardTAN #flickercode

2 Photos - View album

Post has attachment
Serial console on ESCAM Ant QF605 camera:

I bought a cheap ESCAM Ant QF605 Wifi webcam, almost bricked it and revived it using the serial console.

Long story:
I bought one of these cheap 720p wifi webcams some weeks ago (to be specific, it was the "ESCAM Ant QF605").

The camera comes with an app ( and an online service which I both didn't want to use. So I just used the app for setting set up the camera (especially the WiFi password) and after that prohibited all internet access for the camera at my router and simply directly used the RTSP URL for accessing the h264 video stream:

or on older firmware versions:

The quality is not overwhelming but ok for the price. The camera by default also starts a telnet daemon on port and I found the root login online using Google:

User: root
Password: jvbzd

This way I found out that the camera runs thttpd and some single binary "/progs/bin/sctrl" which seems to do all the video stuff and opens the 554 port (providing the RTSP stream).

Unfortunately the camera also seems to have some problems. It gets pretty hot and keeps rebooting randomly every few days or hours (maybe related to the heat?).

Nevertheless, last week I tried to explore the boot process of the system and played around with some of the init-scripts, as suddenly the camera didn't seem to boot anymore. It never came online again.

In the first moment I regretted that I wasn't more careful and thought that I had bricked the device. But after opening I soon discovered 4 promising looking contacts on the PCB which turned out to be a serial line (rx, tx, ground and 1 pin unconnected).

By using my FTDI serial to USB converter I was able to connect to the serial console and got access not only to the U-Boot boot prompt, but also to the Linux console (fortunately the kernel was compiled with serial console).

Having this access I saw that the device did in fact boot, but was rebooting before the WiFi came up. To exit this boot loop I simply modified the boot parameters for the Linux kernel on the U-Boot command line, by adding the argument "single" which directs the kernel to boot into single user mode (just starting a shell and none of the startup scripts).

Maybe this information will help others so I attached pictures where to find the serial connectors on the board. I also attached a short video showing the boot loop and how I managed to boot into single user mode over the serial console.

Serial settings I used in minicom: baudrate 115200, 8N1, software flow control

I also attached lots of other images of the device for documentation.

18 Photos - View album

Post has attachment
Soeben getestet: Auch am Nexus 6P dürften SIM-basierte NFC-Payment-Lösungen nicht möglich sein

Danke an +Wolfgang Trexler der mir nach dem Nexus 5X nun auch ein 6P für Tests zur Verfügung gestellt hat.

Ich habe nun mit dem 6P ebenso zahlreiche Tests und NFC-Konfigurationsänderungen wie schon beim 5X durchgeführt, aber auch bei diesem Gerät scheint keine physische SWP-Verbindung zwischen dem NFC-Chip und dem SIM-Slot vorhanden zu sein (zumindest deutet aus Software-Sicht alles darauf hin).

Somit wird es niemals möglich sein (egal welche Software-Updates noch kommen mögen) SIM-karten-basierte Lösungen wie die Bankomatkarte Mobil ( mit dem Nexus 6P zu verwenden, da eine Hardware-Voraussetzung fehlt (nämlich die angesprochene SWP Verbindung zwischen NFC Chip und SIM-Karte).

Für Details siehe auch meine früheren Postings hier auf Google+ oder mein Posting auf stackoverflow:

Post has attachment
Overriding OMAPI Secure Element access control with an Xposed module

For those who are interested, I've written a (little bit longer) posting on XDA about an Xposed module I've published a few weeks before on Github which shows that overriding the access control mechanism of the SIMalliance Open Mobile API can be done very easily.

Post has attachment
Bin leider nicht am #32C3 vor Ort aber u.a. auf den Talk bin ich schon gespannt:

Ich habe mich bis jetzt immer nur mit den Dingen beschäftigt, die zwischen Karte und Terminal passieren. Hier geht's aber um die Kommunikation eine Ebene dahinter: nämlich zwischen Terminal und Banken-Backend.

TL;DR: SIM-basierte NFC-Payments sind am Nexus 5X leider nicht möglich.
Soweit ich das mit meinem derzeitigen Wissensstand feststellen kann, hat das Gerät keine SWP Verbindung vom NFC-Chip zur SIM-Karte (also fehlt eine Hardwarevoraussetzung). :-(

Wie in einem vorigen Post beschrieben, habe ich mich mit der Thematik auseinandergesetzt, wie ich auf meinen Nexus Geräten die Bankcard Mobil (eine SIM-karten-basierte NFC Payment Lösung) zum Laufen bringe. (Für Details siehe hier:

Bis jetzt hatte ich nur ein Nexus 5 und ein Nexus 6 zur Verfügung, dank +Wolfgang Trexler konnte ich nun auch mit einem Nexus 5X testen.

Das 5X (genauso wie das 6P) hat im Gegensatz zu den letzten Geräten der Nexus Serie wieder einen NFC Chipsatz von NXP verbaut (genauer: den NXP PN548/C2 mit Firmwareversion 10.01.19). Dadurch konnte ich nicht mehr 1:1 die NFC-Chip-Konfigurationen vom nexus 5 oder nexus 6 übernehmen.

Nach zahlreichen trial-und-error Versuchen mit diversen Config-Parametern des NXP Chips hatte ich es immer noch nicht geschafft, dass ich eingehende NFC SELECT APDUs die an ein als "offhost" deklariertes Service adressiert sind (wie eben die Bankcard Mobil) an die SIM Karte routen kann (anstatt dass sie am Android-Hostsystem aufschlagen).

libnfc Library:
Als nächsten Schritt wollte ich herausfinden, ob das Gerät überhaupt eine SWP (single wire protocol) Verbindung zwischen SIM und NFC Chip hat. Leider kenne ich mich in hardware-Dingen nicht so gut aus, daher habe ich mir in Folge zuerst den unteren NFC Softwarestack genauer angesehen, um zu lernen wie das funktioniert: auf unterster Ebene gibt's den kerneltreiber, der das device file /dev/pn54x bereitstellt. Darüber - und für mich interessanter - liegt in der Architektur die "libnfc-nci" Bibliothek, welche wiederum HAL- (hardware abstraction layer) Implementierungen für NXP und Broadcom Chipsätze beinhaltet (die dann über das Device File mit dem Chip reden). (Das ist eine Bibliothek für beide Chipsatzfamilien, da mittlerweile beide Hersteller das Standard NCI Interface für ihre Chips verwenden: NXP hatte ja früher ein eigenes proprietäres Interface).

Genau diese NXP Implementierung habe ich mir durchgesehen, und dabei eine interessante Function entdeckt: "phNxpNciHal_SwpTest" ( die laut Kommentar zum Testen der beiden SWP lines des Chips dient. Die wird im Code aktuell nicht verwendet, klang aber genau nachdem was ich suchte - nämlich ein Weg, um festzustellen, ob die SWP lines am Chip mit der UICC verbunden sind.

SWP Test function
Ich habe daher den Code angepasst und habe (zahlreiche Log-Statements eingeführt, damit ich mich besser im ablauf zurechtfinde) und nach der Initialisierung des Chips diese Function 2x aufgerufen (einmal für SWP1 und einmal für SWP2 Line). Alle meine Änderungen finden sich hier:

Danach habe ich die library neu kompiliert und das resultierende /system/lib64/hw/ File (via recovery system) auf dem Nexus 5X platziert und neu gebootet.

Im logcat sieht man nun alle meine Logstatements, und auch den Aufruf der SWP Test function, aber leider liefert die für beide SWP lines einen Fehler zurück. (Während des Tests war eine SWP-fähige SIM-Karte im Gerät eingelegt, daran sollte es also nicht liegen.)

Die relevanten Zeilen im resulitierenden logcat-File, finden sich ab hier: (am besten einfach nach dem String "JZJZ" im Logfile suchen.

Die beiden Zeilen: "phNxpNciHal_SwpTest - FAILED" sind jene, die mich darauf schließen lassen, dass weder SWP1 noch SWP2 auf dem Nexus 5X connected sind.

Ich bin kein Hardware-Experte, also vielleicht liege ich hier auch falsch. Ich bin offen für jeden Hinweis!

Keine Bankcard Mobil am Nexus 5X (zumindest sieht es für mich stark danach aus). :-( Sehr schade, denn das Gerät hätte mir ansonsten eigentlich sehr gut gefallen.

Martijn Coenen, das ist jener Software Entwickler der bei Google für den NFC Stack in Android verantwortlich ist, hat mir mittlerweile bestätigt (siehe Link), dass seines Wissens nach sowohl das Nexus 5X als auch das 6P keine Verbindung zwischen NFC-Chip und SIM-Karte hat und somit nicht für SIM Card-basierte Payment-Lösungen verwendet werden kann:

Wait while more posts are being loaded