iPhone aus Backup wiederherstellen

Es kommt ja hin und wieder einmal vor, dass man -- als Benutzer von Geräten mit angebissenem Obst drauf -- ein (hoffentlich vorhandenes) iPhone-Backup auf ein neues "iDevice"aufspielen muss, was i. d. R. ja problemlos funktioniert.
(Und bevor jemand fragt: Nein, ich habe kein iPhone 7, und zwar "aus Gründen" (die ich vielleicht ein anderes Mal darlege *g*).)
Allerdings gibt es an der einen oder anderen Stelle diverse Ecken und Kanten, die zumeist im Verantwortungsbereich der App-Hersteller liegen. Im Folgenden ein kurzer Überblick bzw. Erfahrungsbericht, was bei diversen Apps schief gehen kann. Ich beziehe mich auf ein iTunes-Backup (nicht iCloud-Backup).

Das Inbetriebnehmen eines neuen "iDevice" aus einem zuvor erstellten Backup ist relativ "straight forward": Anstatt den WLAN-Schlüssel einzugeben wählt man während der Einrichtungsprozedur einfach "aus Backup wiederherstellen" aus und verbindet das iPhone über USB "mit iTunes" (also wohl eher mit einem Rechner, auf dem iTunes installiert ist). (Details dazu siehe auch unter https://support.apple.com/de-de/HT204184.) Es bietet sich an, dass man das Backup vorher mit einem Kennwort verschlüsselt hat, das man jetzt in iTunes eingeben muss (und tunlichst nicht vergessen haben sollte), damit u.a. auch alle WLAN-Kennwörter im Backup enthalten sind. Nach der Wiederherstellung startet das iPhone neu, und dann werden die Apps wiederhergestellt.

Hierbei habe ich mich gewundert, dass sehr viele Apps erneut aus dem Store geladen wurden, obwohl ich dachte, diese seien im Backup mit integriert. Nun ja, waren anscheinend doch nicht alle. Vermutlich einmal zu wenig "Einkäufe übertragen" in iTunes angewählt...

Kommen wir nun zu den "Spezialfällen":

 1. Threema:

Hier sollte man vorher seine Identität gesichert haben (und sich an das dafür vergebene Passwort erinnern können). Die Identität (entspricht einem eindeutigen Benutzernamen aus Buchstaben und Zahlen) wird nach dem ersten Start automatisch erkannt, muss aber mit dem Passwort aktiviert werden. Gelingt das, ist die gesamte Kontaktliste wie auch die Chat-History wieder da.
(Meinem Verständnis nach sind diese ausschließlich im Backup vorhanden, werden also nicht auf den Threema-Servern abgelegt.)

2. Telegram:

Hier kam bei mir nach dem Start der App nur "Verbinden..." in der Statuszeile, und ich konnte weder meine Kontakte noch Chat-History sehen. Nach längerem Herumprobieren und Recherchieren löschte ich die App inkl. aller Daten vom Handy und lud sie erneut aus dem App Store. Nach einer Bestätigungs-SMS und der Eingabe eines Kennwortes (letzteres nur, weil ich die zweistufige Authentifizierung aktiviert hatte) wurde meine Kontaktliste und Chat-History aus der verschlüsselten dezentralen (siehe hierzu diese FAQ) Cloud des Anbieters wiederhergestellt.

3. Signal:

Hier musste ich mit Entsetzen feststellen, dass weder die Kontaktliste noch die Chat-History im iTunes-Backup landet. Dies ist offensichtlich kein Bug, sondern ein (zumindest bspw. hier und hier diskutiertes) Security-Feature ("Signal files are completely excluded from iCloud and iTunes backups."). Weiterhin hätte -- wie meine Recherchen ergeben haben -- nicht einmal die Möglichkeit bestanden, auf dem alten Gerät Kontaktliste oder Chat-History in irgendeiner Art und Weise zu exportieren!

4. Fritz!Phone:

Fritz!Phone verlangte nach Eingabe des Fritz!Box-Kennwortes noch die Eingabe eines gerätespezifischen Kennwortes, welches mir weder bekannt war noch ich jemals vergeben hatte (zumindest meiner Erinnerung nach). Abhilfe war, das iPhone in der Fritz!Box-Oberfläche bei den Telefoniegeräten zu entfernen und danach Fritz!Phone erneut bei der Fritz!Box zu registrieren. Jetzt wurde nur noch das Fritz!Box-Kennwort nachgefragt, und die App konnte sich bei der Fritz!Box als VoIP-Client anmelden bzw. registrieren.

5. Withings Health Mate:

Hier war nur ein erneutes Anmelden in der App mit dem Withings-Account notwendig.

6. Google Authenticator:

Ich verwende bei diversen (Cloud-)Diensten einen Zweifaktor-Authentifizierung (2FA). Leider fehlte nach der Wiederherstellung des iPhone-Backups der Code für Evernote im Google Authenticator. Abhilfe hier war, sich bei Evernote mit einem (hoffentlich noch vorhandenen) "Reservecode" anzumelden, die 2FA zu deaktivieren und wieder zu aktivieren, um den QR-Code für die App zu erhalten.

So weit, so gut. Falls sich in den nächsten Tagen der Benutzung noch mehr "Spezialfälle" auftun sollten, werde ich die Liste hier entsprechend ergänzen.

DHCP-Probleme an LAN4 einer FRITZ!Box

Ich habe hier eine FRITZ!Box 7272 mit vier LAN-Ports. An LAN1 hängt ein Kabelmodem, das eingebaute DSL-Modem wird nicht verwendet. LAN2 und LAN3 funktionieren wie erwartet.
Schließe ich jedoch ein Gerät (egal, ob Rechner, Drucker, Raspberry Pi, ...) an LAN4 an, kommt keine Konnektivität zustande (zumindest würde ein nicht ganz unbedeutendes Betriebssystem aus Redmond das wohl so in etwa ausdrücken *gg*). Es kommt zwar rein elektrisch eine Verbindung zustande (der Rechner merkt, dass ein Netzwerkkabel eingesteckt ist), aber es wird keine IP-Adresse über DHCP angeboten. Ich habe das mit mehreren Geräten ausprobiert, das Verhalten war überall das selbe. Irgendwann weisen sie sich eine Adresse aus dem AutoIP-Bereich (169.254/16 nach RFC 3927) zu. Der sog. "Gastzugang" über LAN4 ist deaktiviert. Nachdem ich lange die Fehlerursache gesucht und auch erfolglos nach einer Lösung gegoogelt habe, hat bei mir folgende Vorgehensweise Abhilfe geschaffen:

• Gastzugang über LAN4 aktivieren: Heimnetz > Netzwerk > Netzwerkeinstellungen > [x] Gastzugang über LAN4 aktiv (Häkchen setzen) und "Übernehmen" klicken;
• Gastzugang über LAN4 deaktivieren: Häkchen bei Gastzugang über LAN4 aktiv wegnehmen und "Übernehmen" klicken;

Danach bekam ein an LAN4 angeschlossenes Gerät eine IP-Adresse aus dem Heimnetzwerk-Bereich (d.h. standardmäßig 192.168.178.x) über DHCP zugewiesen und alles funktioniert wie gewünscht.

OwnCloud über apt Repository

Fall noch jemand eine OwnCloud-Installation über die beim openSUSE Build Service gehosteten "offiziellen" apt-Repositories (gibt's dort auch für Debian etc.) am Laufen hat (wie es damals im c't-Artikel empfohlen wurde) und sich wundert, warum darüber keine Updates auf die Version 8.2.x kommen:
Auf der Infoseite des OwnCloud Build Service findet sich der Hinweis:

Since owncloud-8.2.0 we host the owncloud server at https://download.owncloud.org/download/repositories/8.2/owncloud -- you have to switch repositories to get this new release. The repository here will remain at the 8.1.x branch.

Also muss man den Eintrag in der betreffenden sources.list umstellen (und vorher den Repo-Key hinzufügen), steht aber alles auf der oben verlinkten Seite.
Die Umstellung hat dann auch relativ smooth funktioniert (zumindest nicht mit mehr Problemen als sonst *g*)...

OS X: Programmwechsel mit Cmd-Tab und mehrere Displays

Wenn man mehrere Monitore am Mac angeschlossen hat oder ein MacBook mit internem und externem Display betreibt, verwirrt es manchmal, auf welchem Display die Auswahl der geöffneten Programme angezeigt wird, nachdem man Cmd-Tab gedrückt hat. Eine Logik dahinter scheint auf den ersten Blick nicht erkennbar zu sein, um nicht zu sagen: Das Fenster erscheint "immer" auf dem falschen Bildschirm.
Die tatsächliche Logik, die in OS X (10.9) zur Anwendung kommt, ist hingegen folgende: Das "Command-Tab"-Fenster zum Anwendungswechsel wird immer auf dem Bildschirm angezeigt, auf dem das Dock zuletzt aktiv war. "Aktiv" bedeutet hierbei: Es reicht, wenn der Mauszeiger drüber war. (Es ist also kein Klick erforderlich.)

(Nachbemerkung: In Ermangelung einer Installation von OS X 10.10 kann ich nicht überprüfen, ob es sich bei dem aktuellsten Betriebssystem aus dem Hause Apple ebenso verhält.) 

Fritz!Box VPN (IPSec) und DNS

Vorbemerkung

Warum will man eine VPN-Verbindung über das Internet zur eigenen Fritz!Box herstellen? Hierzu sei auf http://blog.rotzoll.net/2010/07/iphone-per-vpn-an-fritzbox-7270-einbinden/ verwiesen. Kurz zusammengefasst: Man will von außen eine Verbindung in sein Heimnetzwerk herstellen und/oder man benötigt eine Gegenstelle, um über eine sichere Verbindung in einem öffentlichen WLAN Internet zu nutzen.

Fritz!-VPN

Seit geraumer Zeit bieten die Fritz!Boxen bereits die Möglichkeit, Tunnel über das Protokoll IPSec herzustellen. Allerdings war es früher[tm] notwendig, sich mit einer Windows-Software für jede Verbindung bzw. jeden Benutzer eine VPN-Profildatei zu erzeugen und diese über die Weboberfläche der Fritz!Box hochzuladen. Seit einigen Fritz!OS Versionen ist es nun möglich, ganz ohne den Umweg über VPN-Profildateien allein über die Weboberfläche VPN für einen Benutzer freizuschalten bzw. zu aktivieren.
Voraussetzung ist, dass die Fritz!Box von außen über einen (Dyn)DNS-Eintrag erreichbar ist. AVM bietet hierfür den Dienst "MyFritz" an. Alternativ dazu kann man auch einen der "üblichen Verdächtigen" (z.B. noip, freedns.afraid.org etc., Vergleichstest in c't 07/2013 ab S. 108) nehmen.
Im Prinzip geht man wie in diesem Tutorial des Herstellers (hier für iOS-Clients) beschrieben vor, also zuerst über den Punkt "System" > "Fritz!Box-Benutzer" einen neuen Benutzer (mit Benutzername und Kennwort) anlegen und "VPN" für diesen Benutzer aktivieren. (Die anderen Optionen können allesamt abgeschaltet werden!) Unter dem Link "VPN-Einstellungen anzeigen" des neu angelegten Benutzers ist das "shared secret" zu erfahren, das in den Clients neben Benutzername und Kennwort eingetragen werden muss. (Es werden keine Zertifikate verwendet, sondern pre-shared keys, was etwas unsicherer ist.)
Das war es auch schon -- eigentlich.

iOS / DNS

Ich habe dann anschließend die IPSec-VPN-Verbindung unter iOS 8.1 eingerichtet, was wie in oben erwähnten Tutorial funktionierte. Das Herstellen der VPN-Verbindung aus dem Mobilnetz hat dann auch wie erwartet funktioniert, nur konnten dann vom iPhone weder Webseiten aufgerufen werden noch hatten Apps (wie Mail oder Threema) eine funktionierende Internetverbindung. In Safari bekam ich allerdings nach Eingabe der IP-Adresse meiner Fritz!Box in die Adresszeile die Weboberfläche selbiger angezeigt. Ich vermutete also ein DNS-Problem. (Nicht verifiziert habe ich dieses allerdings aus Zeit- und Testmangel unter anderen Betriebssystemen.)
Dass ich nicht der einzige mit exakt diesem Problem bin, kann man hier oder hier nachlesen. Mit irgendwelchen Fritz!OS-Zwischen- oder -Labor-Versionen schien es wohl mal zu gehen, aber mit der derzeit aktuellsten (nicht-Labor-)Version wohl wieder nicht "out of the (Fritz!)box"...
Was bei mir dann endgültig weiter geholfen hat, war der Tipp in diesem Kommentar: Man muss in der Weboberfläche der Fritz!Box unter "Internet" > "Filter" > Tab "Listen" > "NetBIOS-Filter aktiv" ausschalten, mit "Übernehmen" bestätigen und denn wieder einschalten und erneut mit "Übernehmen" bestätigen. (Scheint also wohl irgendwie ein Bug zu sein...)
Jetzt funktioniert auch die Namensauflösung, wenn man über IPSec VPN mit der Fritz!Box verbunden ist. Auf dem iPhone wird (bei bestehender VPN-Verbindung) in entsprechenden Apps (ich verwende die Funktion "Gerät" der App "TrafficMonitor") als externe IP-Adresse die externe IP-Adresse meines Internetanschlusses daheim angezeigt.

Alles gut?

Naja, wenn das iPhone auf Standby geht, wird die VPN-Verbindung beendet, und man muss sie manuell erneut herstellen, wenn man wieder auf der "sicheren Seite" sein möchte. Es gibt wohl seit einigen iOS-Releases Möglichkeiten, dies zu persistieren, aber damit habe ich mich noch nicht beschäftigt.

Verschlüsseltes iPhone Backup in iTunes - Passwort vergessen?

Wenn man seine "i-Devices" mit iTunes sichert und Wert darauf legt, dass auch alle auf dem Gerät gespeicherten WLAN-Passwörter mit gesichert werden, muss man das Backup verschlüsseln, indem man in iTunes das Häkchen bei "iPhone-Backup verschlüsseln" setzt und ein Kennwort vergibt.

Um das betreffende Gerät aus dem Backup wiederherzustellen, muss dann das Kennwort eingegeben werden, nicht jedoch bei jeder weiteren Sicherung des Gerätes, wodurch zumindest schon einmal die Gefahr besteht, dass das Kennwort in Vergessenheit gerät und man es dann, wenn man es braucht, nicht mehr weiß... :-/
Ok, nehmen wir nun an, man kann sich an das Kennwort nicht mehr erinnern, ist aber auf das gespeicherte Backup nicht unbedingt angewiesen; soll heißen: man möchte jetzt ein unverschlüsseltes Backup oder alternativ auch ein Backup mit einem neuen Kennwort anlegen. Klingt auf den ersten Blick nicht sonderlich schwer: Warum nicht einfach das Häckchen bei "iPhone-Backup verschlüsseln" wegmachen? Geht nicht: Hierzu müsste man nämlich das vergessene Kennwort eingeben. So weit, so schlecht: Dann nehmen wir eben einen anderen Rechner, auf dem wir noch nie ein Backup des betreffenden Gerätes erstellt haben. Dieser dürfte ja nichts von einem verschlüsselten Backup wissen. - Falsch! Auch dort ist der Punkt angehakt und das Häkchen geht nur weg, wenn man das Kennwort weiß, was man ja aber vergessen hat. Daraus folgt, dass die Daten zur Kennwortüberprüfung entweder auf dem Device selbst gespeichert oder beim Hersteller mit der AppleID verknüpft sind.
Eine kurze Google-Suche zu dem Thema bringt viel Müll (Motto: "Dann nimm halt einen anderen Rechner und mach dort ein unverschlüsseltes Backup.") zum Vorschein. Außerdem einen Apple Support-Artikel. Zitat:

Wenn Sie sich nicht an Ihr Kennwort erinnern können und neu beginnen möchten, müssen Sie eine vollständige Wiederherstellung der Software durchführen und die Option "Als neues Gerät konfigurieren" auswählen, wenn iTunes Sie zum Auswählen eines wiederherzustellenden Backups auffordert.

D.h. man muss laut Apple das betreffende Gerät komplett zurücksetzen, um den Kennwortschutz loszuwerden (!).
Nachdem ich noch weiter gesucht habe, bin ich auf dieses Tool gestoßen. Es erlaubt in der Vollversion, das Kennwort mittels Dictionary Attacke und/oder Brute Force zu knacken. Es ist leider nur für Windows erhältlich - also dort nochmal ein verschlüsseltes Backup anlegen...
Elcomsoft Phone Password Breaker ist schnell installiert. In der kostenlosen Demo-Version zeigt es nur die ersten zwei Buchstaben und die Länge des gefunden Passwortes an; will man mehr, zahlt man mindestens 79€ dafür. Für einen ersten Test reicht aber die kostenlose Version. Ein Test, um zu merken, dass man Kennwörter in der von mir verwendeten Komplexität (Länge mindestens 9, eher 14 Zeichen, enthält Buchstaben in groß und klein sowie Ziffern und Sonderzeichen) nicht in endlicher Zeit "brute forcen" kann. Mein Rechner (ohne GPU-Unterstützung) wäre vermutlich mehrere hundert Jahre beschäftigt gewesen, mein Kennwort herauszufinden, also zu spät für das iPhone 6... ;-) Selbst die Dictionary-Attacke hätte inkl. Mutationen der Wörterbucheinträge fast einen Tag lang gedauert.
Ein ca. 30 Minuten dauernder Anruf beim Apple Support ergab folgendes: Auch Apple kann das Kennwort nicht so zurücksetzen, dass künftige Backups unverschlüsselt sind. Ohne das Kennwort zu kennen, bleibt nur das komplette Zurücksetzen des iPhones. Um möglichst viele Daten zu retten, empfahl die freundliche und kompetente Dame, vorher noch alle Fotos runterzukopieren und auf dem Telefon zu löschen sowie anschließend ein iCloud-Backup zu machen. Aus diesem könnte man ja nach dem Zurücksetzen das Backup wieder einspielen, so dass die meisten Daten dann wieder auf dem Telefon zur Verfügung stehen, wenn man die zu sichernden Daten vorher in den Einstellungen auf dem Telefon entsprechend ausgewählt hat. Außerdem müsse auf dem PC iTunes und alle zugehörigen Komponenten deinstalliert und neu installiert werden bzw. beim Mac auf den Desktop und dann wieder zurück in den "Applications" Ordner gezogen werden.
So schnell wollte ich allerdings nicht aufgeben. Während das iCloud-Backup lief, hatte ich genug Zeit, über alternative Lösungswege nachzudenken:
Wenn das o.g. Elcomsoft Tool in der Lage ist, Mutationen über Wörter aus einer Liste durchzuführen (irgendwann gab es da auch mal einen c't-Artikel über Tools, die dies können), dann gebe ich als Ausgangsmaterial einfach mal eine Liste der von mir in den letzten Jahren an verschiedensten Stellen verwendeten Kennwörter mit und stellte die Mutationsoptionen in allen Kategorien auf "max":

Tatsächlich meldete das Programm nach kurzer Wartezeit (< 1 Minute) Erfolg: Es zeigte mir die ersten zwei Zeichen sowie die Länge des vergessenen Kennworts an. (Hätte ich 79€ investiert, bekäme ich das ganze Kennwort angezeigt.) Ich probierte ein paar Mutationen eines auf das Muster passenden mir bekannten Kennwortes aus und hatte schließlich mein vergessenes Kennwort wieder und war so in der Lage, das Häkchen bei "iPhone-Backup verschlüsseln" zu entfernen.

Fazit:

1. "iPhone-Backup verschlüsseln" ist sinnvoll (wenn man nicht nach dem Wiederherstellen des Devices bei allen Freunden und Bekannten die WLAN-Passwörter erneut einsammeln möchte).
2. "iPhone-Backup verschlüsseln" ist [zu?] sicher:
• Nicht einmal Apple kann den Benutzer in die Lage versetzen, ein unverschlüsseltes Backup anzufertigen, nachdem er einmal ein Passwort vergeben und vergessen hat.
• Es wird starke Verschlüsselung verwendet. Brute Force ist bei ausreichend langen Kennwörtern aufgrund der Rechenzeiten quasi nicht möglich.
3. Besser ist es, ein gut zu merkendes Kennwort zu verwenden, das einem auch noch einfällt, wenn man es mehrere Monate oder Jahre nicht eingegeben hat und/oder dieses an einem sicheren Ort (z.B. Zettel unter der Tastatur oder Datei "streng geheime Kennwörter.docx" ;-p ) zu verwahren. NIE NIE NIE jedoch sollte man das dort verwendete Kennwort vergessen.

Aufwand insgesamt:
Passwörter ausprobieren: ca. 1/2h; Recherche und Test des Tools: ca. 2,5h; Telefonat mit Support: ca. 1/2 h; Lösung: ca. 1/2h; Blog-Artikel: ca. 1/2h;
plus ca. 1/2 Tag schlechte Laune, die die family ertragen musste... :-/

(Weitere) Links dazu:

• http://support.apple.com/kb/HT4946?viewlocale=de_DE
• http://apple.stackexchange.com/questions/10964/how-to-get-itunes-to-stop-encrypting-iphone-backups-without-the-password
• http://stackoverflow.com/questions/1498342/how-to-decrypt-an-encrypted-apple-itunes-iphone-backup

Ubuntu 11.10 - Netzwerkkonfiguration verzögert Start unnötig

Nur falls der selbe Fehler bei noch jemandem auftritt, hier eine Lösung, die bei mir weiterhalf:

Problem: Beim Booten von Ubuntu 11.10 erscheint zunächst die Meldung

"Waiting for network configuration..."

dann:

"Waiting up to 60 more seconds for network configuration..."

dann:

"Booting the machine without full network configuration"

Bei anderen war hier das Problem, dass hier der dbus abgestürzt ist, weil sich die Verzeichnisstruktur zwischen 11.04 und 11.10 geändert hat und diese Umstellung wohl teilweise beim Upgrade nicht richtig funktioniert hat. Nichtsdestotrotz war dies bei mir nicht die Ursache für o.g. Meldungen.

Nach einem Blick in /etc/network/interfaces erkannte ich jedoch, dass hier ein paar Einträge mit eth1 vorhanden waren, die da nicht hingehören, da bei mir nur eth0 aktiv ist (nur 1 NIC, on-board, kein WLAN):

iface eth1 inet dhcp
auto eth1

Ich habe das mal geändert nach

iface eth0 inet dhcp
auto eth0

Die Zeilen mit "lo" ließ ich unangetastet:

auto lo
iface lo inet loopback

Seit der Änderung bootet mein Ubuntu wieder wie geschmiert (und ca. 2 Minuten schneller als mit der falschen Netzwerkkonfiguration), und die Meldungen sind auch verschwunden. :)