Sonntag, 14. September 2014

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:

Freitag, 24. August 2012

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. :)

Samstag, 31. März 2012

Android - SD-Karten-Probleme

Nachdem mein bisheriges Smartphone displaymäßig den Geist aufgegeben hat (und ich -- nebenbei bemerkt -- bisher keine Möglichkeit gefunden habe, an die auf dem Gerät gespeicherten Text-Notizen zu kommen) und noch kein iPhone5 in Sichtweite ist (ein iPhone "for ass" (=4S), das für'n Arsch ist, mag ich nicht), musste ein Android-Mittelklasse-Smartphone her. Die Wahl fiel auf ein Samsung Galaxy ACE. Wie auch immer. Das Telefon lief seit ca. einem Monat relativ problemlos. Dann wurden diverse auf der SD-Karte installierte Apps durch ihre internen Namen (z.B. "com.evernote" anstatt "Evernote") und Einheits-Icon dargestellt und waren nicht mehr startbar. Auch ein Deinstallieren und neu aus dem Market-Place Play-Store (welch besch****ner Name!) brachte keine wirkliche Besserung. Die Fehlermeldung z.B. von Evernote war so was wie "I/O-Error beim Zugriff auf die SQLite-Datenbank". Na gut, erst mal den "Evernote"-Ordner auf der SD-Karte gelöscht, was aber keine Besserung brachte. Dann die SD-Karte mal in den Rechner (Windows XP) gelegt und recherchiert, dass die Apps wohl im Ordner ".android_secure" landen. Tatsächlich lagen da zwei Dateien "com.evernote-1.asec" und "com.evernote-2.asec", wobei auf die erste nicht zugreifbar war (I/O-Error). Auch löschen konnte man sie nicht. Eine Datenträgerüberprüfung verlief fehlerfrei. Dann gleich mal Ubuntu gebootet. Lesezugriff auf die Datei war immer noch nicht möglich, ein "rm com.evernote-1.asec" wurde jedoch anstandslos ausgeführt. Nach Einsetzen der Karte ins Telefon und anschließender Neuinstallation von "Evernote" wurden alle Notizen neu synchronisiert, und jetzt geht alles wieder. Die anderen Apps, die Probleme machten (meiner Erinnerung nach war dies noch "Barcoo Barcode Scanner"), wurden dann auch von der SD-Karte geputzt und neu aus dem Store installiert. Nur "Layar" (Reality Browser) wird im Store nicht mehr gefunden. Zumindest nicht, wenn man von dem Gerät aus sucht. Per Suche auf http://play.google.com/ landet man aber hier und kann direkt aus dem Web die Installation auf dem eigenen Gerät auslösen. Ende gut, (bisher) alles gut (bis auf die Akkulaufzeit des Smartphones, aber das ist ein anderes Thema...).

Mittwoch, 29. Juni 2011

Energiesparen - aber richtig

Wir müssen ja bekanntlich alle Energie sparen, insbesondere wenn wir alle deutschen Kernkraftwerke abschalten und die Fehlmenge nicht durch "Atomstrom"-Importe aus den Nachbarländern ausgleichen wollen.

Zum Thema "Energie sparen im Haushalt" habe ich im Rahmen einer Diskussionsrunde folgende nachdenklich machende Anekdote gehört:
Das ökologische Gewissen plagt den Besitzer eines alten Kühlschrankes aufgrund des Energiebedarfs sehr, so dass er sich auf den Weg machte in die nächste Filiale eines beliebigen Elektronikgroßmarktes. (Er ist ja schließlich nicht "blöd" und Geiz ist bekanntlich "geil".) Dort entdeckt er das Ziel seiner Wünsche, den Traum seiner schlaflosen Nächte: Einen Kühlschrank der Energieeffizienzklasse "A+++". Bei so viel Energieeffizienz schaut man natürlich nicht auf den Preis, schließlich will ja das ökologische Gewissen befriedigt werden. Das Gerät wird also gekauft, stolz nach Hause gebracht und voller Freude in der Küche aufgestellt.
Doch: Was macht man jetzt bloß mit dem alten Kühlschrank? Der geht ja noch!! Und zum Entsorgen ist der ja eigentlich viel zu schade! Also wird er mit der letzten Kraft in den Keller verschafft und dort angeschlossen: Ist doch praktisch, so ein Zweitkühlschrank im Keller, da kann man dann ja auch mal eine größere Menge gekühltes Bier bereithalten, wenn sich Gäste angekündigt haben, oder vielleicht auch nicht angekündigt haben, aber jederzeit aufkreuzen könnten. Oder die Dritttorte für größere Familienfeiern drin kühlstellen...
Wo ist der Fehler??

Freitag, 17. Juni 2011

Boot-USB-Stick für Ubuntu 10.04 LTS mit Ubuntu 11.04 erzeugen

Versucht man, mit Hilfe des "Startup Disk Creator" und einem Ubuntu-10.04-ISO-Image aus Ubuntu 11.04 einen bootbaren USB-Stick zu erzeugen, scheint auf den ersten Blick alles zu klappen, bis man von diesem Stick versucht zu booten. Dann erscheint nur die Fehlermeldung:
Unknown keyword in configuration file: gfxboot
vesamenu.c32: not a COM32R image
Gut, könnte man sagen, hätte man nur die Release Notes von 11.04 gelesen, wäre man auf folgende Information gestoßen:
There is a problem creating a bootable 10.04.2 or earlier USB image from Ubuntu 10.10 or 11.04 system. Booting from the USB can be made to work, but using the workaround of typing "help" and pressing Return.
Da dieser Workaround mich nicht wirklich befriedigen konnte (ich würde mich bspw. jedes Mal wieder fragen, was ich eingeben muss, wenn ich den Stick nutze), habe ich etwas weiter recherchiert und bin im Launchpad (Ubuntus Bugtracker) darauf gestoßen, dass man auf dem Stick nur die Datei /syslinux/vesamenu.c32 durch die Version von /usr/lib/syslinux/vesamenu.c32 ersetzen muss, dann funktioniert es.

Dienstag, 30. November 2010

JavaScript/DOM: Verhalten von appendChild()

Folgendes ist mir bei der JavaScript-Entwicklung aufgefallen.

Verwendet man die Methode appendChild(), um ein vorher bspw. mittels getElementById() (oder der PrototypeJS- bzw. JQuery-Funktion "$()") aus dem DOM geholtes Element an anderer Stelle oder in ein anderes Dokument (ein anderes Browserfenster) einzufügen, wird das an der ursprünglichen Stelle stehende Element gelöscht (!).

Dies ist kein Bug, sondern laut DOM-Spezifikation so gewollt.
If the newChild is already in the tree, it is first removed.
Soll das Element an der ursprünglichen Stelle bestehen bleiben, ist diese zunächst mittels der Methode cloneNode() zu duplizieren.

Sonntag, 14. November 2010

GrowlMail und OS X 10.6.5 / Mail 4.4

Nach meinem Update auf Mac OS X 10.6.5 (vorher hatte ich noch 10.5.x) funktionierte das Apple Mail Plugin GrowlMail nicht mehr, welches Growl Benachrichtigungen anzeigt, wenn neue Mails eintreffen.
Leider ist es so, dass bei der neuen Version von Apple Mail Plugins für jede Version von Apple-Mail, für die sie verwendbar sind, eine UUID dieser Version von Apple Mail enthalten müssen. Es kann also ein Plugin nicht mehr die Information enthalten "Ich bin für alle Versionen von Mail ab 4.0 geeignet", sondern muss alle Versionen (bzw. deren UUIDs) explizit auflisten.

Wurde GrowlMail beim Start von Mail aufgrund der (vermeintlichen) Inkompatibilität bereits deaktiviert, muss man es von dem Ordner
Users/Library/Mail/Bundles (deaktiviert)/GrowlMail.mailbundle
wieder in den Ordner
Users/Library/Mail/Bundles/GrowlMail.mailbundle
verschieben.

Dann fügt man zur in dem Bundle enthaltenen Datei Info.plist unter SupportedPluginCompatibilityUUIDs die beiden UUIDs von Apple Mail 4.4
"857A142A-AB81-4D99-BECC-D1B55A86D94E"
und
"BDD81F4D-6881-4A8D-94A7-E67410089EEB"
hinzu.

Alternativ kann man das auch über das Terminal lösen:
defaults write ~/Library/Mail/Bundles/GrowlMail.mailbundle/Contents/Info SupportedPluginCompatibilityUUIDs -array-add "857A142A-AB81-4D99-BECC-D1B55A86D94E"
defaults write ~/Library/Mail/Bundles/GrowlMail.mailbundle/Contents/Info SupportedPluginCompatibilityUUIDs -array-add "BDD81F4D-6881-4A8D-94A7-E67410089EEB"


Quelle: http://langui.sh/2010/10/14/fixing-growlmail-in-10-6-5-mail-4-4/


Nachtrag:

Für
Apple Mail 4.5 (kommt mit Mac OS X 10.6.7) lauten die UUIDs
"1C58722D-AFBD-464E-81BB-0E05C108BE06"
und
"9049EF7D-5873-4F54-A447-51D722009310".

Siehe http://langui.sh/2011/03/21/fixing-growlmail-in-10-6-7-mail-4-5/