Quick and Dirty HyperDeck Studio to H.264

ffmpeg -f concat -i files.txt -map_channel 0.1.0:0.1 -map_channel 0.1.1:0.1  -filter:a "aformat=channel_layouts=0xFFFF" -vcodec libx264 -preset ultrafast -r 25 -pix_fmt yuv420p -y output.mp4 

This will discard 14 of the 16 audio tracks, join the Capture000?-chunks, reencode ProRes to H.264, work around a bug in recent ffmpeg versions and is really fast (4x real time on a recent laptop).

Bus Push 2.0

Bus Push

Herbstputz auch bei den internen Apps: Raus mit der Leinentextur und rein mit ein paar neuen Funktionen. Mit dem heutigen Update der Bits und so App läuft jetzt der Push auch über Parse.com und kann bequem über die Bus Push App angesteuert werden. Ein paar von euch haben beim Test heute nachmittag unter Umständen eine Nachricht bekommen…

Oh, und ein neues Icon hat sie auch bekommen:

Icon

FaceTime Sandbox Entitlements

So, your fancy webcam or video capture card won’t work as a video input for FaceTime. Let’s take a look at why that happens.

sandboxd[768]: ([766]) FaceTime(766) deny mach-lookup com.blackmagic-design.desktopvideo.DeckLinkHardwareXPCService

The driver for the video capture device appears to be implemented as an XPC Service and FaceTime is denied access by the sandbox. But don’t Apple’s own apps get special entitlements for stuff like this? Let’s take a look:

$ codesign -dvvv --entitlements - /Applications/FaceTime.app/
...
<key>com.apple.security.temporary-exception.sbpl</key>
<string>(allow mach-lookup (global-name-regex #"^[0-9]+$"))</string>

So there is an exemption for FaceTime that allows mach-lookups for services that match this regex, but it will only match numeric-only strings. Obviously, this won’t match “com.blackmagic-design.desktopvideo.DeckLinkHardwareXPCService” or any other service named in reverse domain notation.

Let’s try ripping out the code signature, and fiddling with the entitlement to say:

<string>(allow mach-lookup (global-name-regex #"^******$"))</string>

Restart FaceTime, and indeed it will detect the video device with the correct resolution and frame rate (still no picture, but the mach-lookup went through!). Also, after messing with the signature, FaceTime pulls a Skype and will not establish any connection. So, no real success in getting the device to work, but a little win in at least getting around the bad regex for the mach-lookup.

#bus350 Onlineticket

In diesen Minuten sollten sich die Türen zum Carl-Orff-Saal in München öffnen. Um vorbeizukommen, ist es jetzt wahrscheinlich zu spät, aber ihr seid herzlich eingeladen, online zuzusehen.

#bus350 Onlineticket jetzt kaufen

One-Page Checkout

Das Webdesign der Bits und so-Seite ist mittlerweile gehörig angestaubt. Da müsste mal jemand was machen.

Ein kleiner erster Schritt ist jetzt die neue Checkout-Seite für das #bus350 Onlineticket.

bus350ot-wide

Die Seite baut auf dem Bootstrap-Framework von Twitter auf. Das bringt viele Nettigkeiten mit, wie ein fertiges Grid-System, das Jony zwar die Tränen in die Augen treiben würde wie sonst nur Filzunterwäsche unter dem Weihnachtsbaum, aber es ist doch wunderbar einfach zu benutzen, um Kästen auf verschieden breiten Geräten hübsch anzuordnen.

bus350ot-narrowEin und dieselbe Seite sieht sehr unterschiedlich auf iPhone, iPad und iMac aus. Und wo Inhalte abgeschnitten werden, setze ich kleine Buttons, um an die nächste richtige Stelle zu scrollen.

Außerdem:

  • Support für PayPal Express Checkout für Digitale Güter
  • Direkte Zahlung mit Kreditkarten via Paymill
  • Sofortüberweisung mit PIN und TAN der eigenen Bank
  • (und wer mag, kann alternativ auch iTunes-Rubbelkarten in der Bits und so App einwerfen)

Der Checkout findet komplett auf dieser einen Seite statt. Kein Warenkorb, kein Blödsinn, im Fall von der Kreditkartenzahlung ist der nächste Bildschirm nach dem Klick auf den Kaufen-Button die Seite mit dem personalisierten Onlineticket. Das würde ich mir öfter so wünschen. Das Humble Bundle ist da auch sehr hübsch gemacht.

Der Käufer bekommt keinen Account, sondern nur einen personalisierten, signierten Link, auf den er nach dem Kauf weitergeleitet wird. Per Mail wird der Link auch noch einmal verschickt. Das ist von Amazons S3 Authentifizierungssystem inspiriert und ein wenig adaptiert.

Für ein sicheres Gefühl™ klebt jetzt auch ein SSL-Zertifikat auf der Seite. Kreditkartendaten fasse ich gar nicht erst an, das erledigt Paymill. Und bei den anderen Diensten passiert die Kommunikation von Kundendaten auch sowieso immer verschlüsselt zwischen den Servern, und nicht mit dem Browser und der Checkout-Seite.

Nächster Schritt: die bitsundso.de komplett neu machen. Nach der #350. Die ist morgen. Kommt alle!

iPhone Passcode setzen und entfernen

Noch eine Handvoll Tipps zum iPhone-Passcode:iphoneistdeaktiviert

Ist kein Passcode gesetzt, und das Gerät geht verloren, lässt er sich nachträglich via iCloud / Find my iPhone setzen.

Ist ein Passcode gesetzt, wurde vergessen und soll entfernt werden, gibt es laut dem Supportdokument drei Möglichkeiten:

  • Gerät hat ein iTunes-Backup: Unter Umständen (wann genau?) ist eine Wiederherstellung möglich
  • Gerät hat kein iTunes-Backup: iPhone in den Recovery-Mode versetzen und wiederherstellen, die Daten gehen verloren
  • Kein iTunes: Fernlöschung durch Find My iPhone, oder Selbstlöschung nach 10 Fehlversuchen, falls aktiviert.

Wie hier der Einfluss von Activation Lock auf iOS 7 ist, ist noch nicht öffentlich bekannt.

Es gibt aber noch eine angenehmere Möglichkeit, den Passcode zurückzusetzen, die bisher über iCloud oder iTunes nicht angeboten wird:

Ist das iPhone in einer Enterprise-Umgebung, z.B. dem MDM von OS X Server angemeldet, kann der Passcode von diesem MDM-Server aus zurückgesetzt werden. Ohne Wiederherstellung, Backups und Datenverlust. Eventuell ist das eine Option, sich für einmalig 18 Euro von diesem Risiko freizukaufen. Die Einrichtung ist nicht völlig trivial, aber durchaus machbar, wenn man die Dokumentation befolgt.

iOS Data Protection

Das Thema Data Protection kann noch einige Details zusätzlich zur Diskussion in Bits und so #340 vertragen:

Geräte ab dem iPhone 3GS verschlüsseln immer den physikalischen Massenspeicher. Darüber ist z.B. die schnelle Fernlöschung realisiert. Das Gerät kann den Schlüssel aus einem speziellen Bereich, genannt Effaceable Storage (auslöschbarer Speicher), entfernen und damit die gespeicherten Inhalte unzugänglich machen.

Zusätzlich dazu existieren Data Protection Classes. Beim Anlegen von Dateien kann die App die Daten einer Klasse zuordnen, die darüber entscheidet, wann die Daten der App wieder zum Lesen zugänglich sind. Die Klassen sind:

  • No Protection – Datei ist immer zugänglich
  • Complete – Datei ist nicht zugänglich, außer das Gerät ist entsperrt
  • Complete unless already open – Geöffnete Dateien bleiben lesbar, auch wenn das Gerät wieder gesperrt wird
  • Complete until first login – Datei ist nicht zugänglich, bis das Gerät nach dem Booten einmal entsperrt wurde

Diese Zuordnung der Datei zu einer Klasse kann auch wieder abgefragt werden. Außerdem kann abgefragt werden, wie die aktuelle Lesebereitschaft von geschützten Dateien ist. Diese Abfrage ist allerdings nur im gesperrten Zustand negativ.

Die App kann also nicht unterscheiden, ob die eigenen Daten zugänglich sind, weil der Nutzer seinen Passcode eingegeben hat, oder weil er keinen hat.

findmyfriendsApples eigene Apps, z.B. Find My Friends, haben Zugriff auf diese Information und nutzen diese auch sinnvoll. Hat der Nutzer einen Passcode, muss das Passwort zur Apple ID nicht eingegeben werden. Fehlt der Passcode, wird das Passwort verlangt.

Im Enterprise-Umfeld kann in Konfigurationsprofilen ein Passcode erzwungen werden. Dann kann auch die zugehörige Enterprise-App davon ausgehen, dass der Nutzer seinen Passcode eingegeben hat, wenn die Daten zugänglich sind. Für App Store-Apps fehlt diese Sicherheit.

Neben den Data Protection Classes für Dateien gibt es analog dazu Klassen für Keychain-Einträge, mit zusätzlichen Spezialfällen. Mit den “ThisDeviceOnly” Klassen bleibt ein Eintrag nur dann nach einem Backup und Restore zugänglich, wenn er auf dem selben Gerät passiert. Die Dokumentation unterscheidet zusätzlich zwischen einer Wiederherstellung auf einem anderen Gerät und einer neuen Installation auf dem selben Gerät.

Diese Bindung an ein einzelnes Gerät geschieht über die UID, einen 256-Bit AES-Schlüssel, der während der Herstellung in die CPU gebrannt wird. Laut Apple wird keine Kopie dieses Schlüssels von Apple oder seinen Zulieferern gespeichert.

Für iTunes- und iCloud-Backups werden Keybags angelegt, die die Schlüssel enthalten, um Backups auch ohne die Eingabe des Passcodes im Hintergrund zu erlauben. Außerdem kann im Enterprise-Umfeld ein vergessener Passcode damit auch wieder zurückgesetzt werden.

Threema – Klartext via USB und iCloud-Backup

Threema ist ein Messenger für iOS, ähnlich zum allseits beliebten Whatsapp, mit dem entscheidenden Unterschied, dass die Datenübertragung verschlüsselt geschieht und die Schlüssel in der Hand der Nutzer liegen. Der Anbieter hat also keine Möglichkeit, die Nachrichten zu entschlüsseln, und die Nutzer haben nach einem Abgleich der Key Fingerprints die Sicherheit, dass niemand auf der Leitung mithorcht.

Der Schlüssel wird in der Keychain abgelegt und augenscheinlich auch nicht mit in das iOS Backup aufgenommen.

Die entschlüsselten Nachrichten selbst allerdings liegen laut der FAQ direkt im Dateisystem und werden ins Backup mit aufgenommen.

Das Dateisystem kann unter iOS von der “Data Protection” geschützt sein, wenn das Gerät mit einem Sperrcode versehen ist. Fehlt der Passcode, fehlt auch die Sperre.

Fehlt die Sperre, lassen sich alle Nachrichten im Klartext über USB auslesen, z.B. mit iExplorer, ohne Jailbreak.

Und zu guter letzt werden die Nachrichten im Klartext auch in das iTunes-Backup aufgenommen und, wenn das aktiviert ist, auch in das iCloud-Backup hochgeladen.

threema

Das lässt sich einfach nachvollziehen:

  1. Threema einrichten und einige Nachrichten verschicken.
  2. iCloud-Backup durchführen.
  3. Gerät komplett löschen.
  4. iCloud Restore durchführen.
  5. Nachrichten im Klartext per USB auslesen.

Ich habe den Entwickler um eine Stellungnahme dazu gebeten – ich finde trotz der verschlüsselten Übertragung die Handhabung des entschlüsselte Nachrichtentexts doch relativ lax.

Update 13.8.2013: Threema-Entwickler Manuel Kasper hat sich bei mir gemeldet. Aus seiner Sicht sind die Daten durch die iOS Data Protection gut geschützt.

Die lokal gehaltenen Daten könnten durch einen weiteren Schlüssel, z.B. ein langes Passwort, verschlüsselt werden, was aber die Nutzerfreundlichkeit stark einschränken würde.

Mein Vorschlag war dann, die lokalen Daten mit dem gleichen Schlüssel zu verschlüsseln, der auch für die Übertragung über das Netzwerk genutzt wird.

Dieser Vorschlag löse zwar nicht das Grundproblem, dass der Schlüssel am selben Ort wie die Daten, also auf dem Gerät gehalten werde, Manuel Kasper hält es aber für eine grundsätzlich gute Idee, die vielleicht in einem Update als zusätzliche Option umgesetzt werden könnte.

Ein guter Hinweis zur Keychain (mehr dazu hier): Einträge können mittels des Attributs kSecAttrAccessibleWhenUnlockedThisDeviceOnly an den gerätespezifischen UID-Schlüssel gebunden werden. Backups enthalten also immer den verschlüsselten Threema-Schlüssel, können aber nur auf dem gleichen Gerät genutzt werden. Ob Apple keine Kopie dieses Schlüssels hat, sei nicht bekannt.

Speichermedien grundieren mit f3write / f3read

sdhc-32

Ein alter Pick aus der Bits und so #294, aber hier eine Wiederholung wert.

Frisch gekaufte SD-Karten/USB-Sticks/etc. sollte man, auch wenn sie aus einer vermeintlich seriösen Quelle stammen, auf ihre tatsächliche Kapazität und Funktionsfähigkeit überprüfen, bevor man darauf unwiederherstellbare Daten aufzeichnet. Es sind wohl immer wieder gerne Betrüger unterwegs, die falsche Größenangaben auf der Packung und in der Konfiguration des Speichermediums angeben. Die Kamera schreibt also fröhlich 32GB auf eine Karte, die tatsächlich nur 1GB fasst. Die Daten sind dann hinüber. Außerdem kann die Karte auch einfach nur defekt sein, oder die versprochene Schreibgeschwindigkeit nicht halten.

Für Randgruppensysteme tut es dafür h2testw vom Heise-Verlag, auf dem Mac kann man f3write / f3read benutzen. Der Datenträger wird mit einem verifizierbaren Muster beschrieben und dieses wird im Anschluss wieder gelesen.

$./f3write /Volumes/NO\ NAME/
Free space: 29.49 GB
Creating file 1.fff ... OK!                        
Creating file 2.fff ... OK!                        
Creating file 3.fff ... OK!  
...
Free space: 0.00 Byte
Average writing speed: 7.78 MB/s

$./f3read /Volumes/NO\ NAME/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.fff ... 2097152/        0/      0/      0
Validating file 2.fff ... 2097152/        0/      0/      0
Validating file 3.fff ... 2097152/        0/      0/      0
...
  Data OK: 29.49 GB (61835072 sectors)
Data LOST: 0.00 Byte (0 sectors)
           Corrupted: 0.00 Byte (0 sectors)
    Slightly changed: 0.00 Byte (0 sectors)
         Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 17.99 MB/s