Ich hatte eben einen "Fehler 492" bei der Installation einer App aus dem Market.

Natürlich habe ich erst die üblichen Schritte zur Fehlerbehebung mit dem Market versucht, hatte damit aber keinen Erfolg.

Die Lösung habe ich dann mit einer Kombination aus zwei Aktionen erlangt.

1. Wipen der Cache Partition
   Das Smartphone im Recoverymodus neu starten (entweder über das Menü beim Neustart oder über das Gedrückthalten der "Volume Down"-Taste beim Start des Handys), Wipe Cache Partition (variiert je nach Recovery) wählen und die Sicherheitsabfrage bestätigen.
2. Wipen des Dalvik Caches
   Wo wir schonmal im Recovery sind, könnenwir auch direkt noch via advanced -> Wipe Dalvik Cache den Dalvik Cache löschen.
3. Neuinstallation des Markets
   Die Market Version 3.4.4 findet man beispielsweise HIER zum Download. Eine offizielle Version gibt es im Market, diese konnte ich allerdings nicht installieren.

Ob die 3.4.4er Version auch bei neueren Marketversionen zur Fehlerbehebung dient, vermag ich nicht zu sagen.

[Update 07.01.2012] Wenn die oben genannten Schritte bei euch keinen Erfolg zeigen, dann versucht einen Komplettwipe (wipe data/factory reset). Das funktioniert auf jeden Fall. Wenn ihr dann vorher auch noch eure Apps mit Titanium Backup sichert, ist euer System schon ein paar Minuten nach dem Factory Reset wieder wie gewohnt eingerichtet. [/Update]

Wenn man sich "mal eben" einen Server oder vServer gemietet hat, sollte man diesen erstmal "grundsichern". Diese Minimalsicherung besteht aus 3 Punkten. Ich gehe hier von Debian aus, da dieses meiner Erfahrung nach am Häufigsten verwendet wird und auch ich es nutze.

1. Update

Der logischste Punkt. Ein nicht geupdatetes System oder veraltete Dienste sind ein geöffnetes Scheunentor. Dies lässt sich mit

apt-get update && apt-get upgrade && apt-get dist-upgrade

aber auch direkt schmerzlos beheben.

2. Root per SSH verbieten

Der Root Account existiert auf jeder Linux Distribution. Deswegen ist dieser Account Teil einer jeden Bruteforcing Attacke. Wenn ihr dem Root Account den Login via SSH verbietet, muss der Angreifer neben eurem Passwort zusätzlich auch noch den Usernamen erraten.

Legen wir also zuerst unseren neuen User an.

adduser sshuser

Natürlich solltet ihr keinen so einfallslosen Namen nehmen, sondern eben einen, der schwer zu erraten ist.
Im Prozess der Usergenerierung müsst ihr auch direkt das Passwort anlegen, welches natürlich ebenfalls schwer zu erraten sein sollte. Ichhabe vor einiger Zeit schonmal beschrieben, wie man komplexe und doch merkbare Passwörter erstellen kann.

Prüft unbedingt, ob ihr euch mit diesem User auch per SSH einloggen könnt, bevor ihr fortfahrt. Ist dies nämlich nicht der Fall, sperrt ihr euch selbst aus!

Nun geht es ans editieren der sshd_config, die ihr im /etc/ssh-Verzeichnis findet. Ich nutze hierfür den vi, euch steht natürlich die Benutzung eines anderen Editors offen. Eine kurze Einführung in den vi findet ihr beispielsweise HIER.

vi /etc/ssh/sshd_config

Sucht nach dem Eintrag

PermitRootLogin yes

und ändert ihn in

PermitRootLogin no

Zusätzlich könnt ihr bei Bedarf auch noch zwei neue Zeilen einfügen

LoginGraceTime 2m
MaxAuthTries 6

Dadurch wird eine Bruteforcingattacke nach 6 Versuchen verhindert.
Außerdem solltet ihr präventiv den Login mit leerem Passwortverhindern, um den einen Testaccount, den ihr garantiert irgendwann mal vergesst nicht zum Problem werden zu lassen.

PermitEmptyPasswords no

Startet nun noch den SSH-Dienst neu

/etc/init.d/ssh restart

und ein SSH-Login als root ist unmöglich.

Ports schließen

Dies ist eine etwas größere Sache, weswegen ich sie nur generell anschneide. Mit dem Befehl

netstat -tulpen | grep -v 127.0.0.1

findet ihr alle Ports und Dienste raus, die auf eurem Server nach draußen herrschen und damit potentiell angreifbar sind. Deaktiviert hier alle Dienste, die ihr nicht zwingend braucht.

Damit ist der Server rudimentär gesichert. Natürlich gibt es noch weitere darüber hinausgehende Sicherungsmöglichkeiten, die ihr auch nutzen solltet, doch ein frischer Server ist nach diesen Maßnahmen vergleichsweise sicher.

Wenn ihr auf eurem gerooteten(!!!) Android Smartphone die gespeicherten W-LAN Passwörter auslesen wollt, ist das überhaupt kein Problem.

1. Startet euren bevorzugten Rootexplorer. Ich nutze hierfür den ES File Explorer mit aktivierten Root Funktionen.
2. Navigiert in das Verzeichnis /data/misc/wifi.
3. Sucht dort nach einer Datei wpa_supplicant.conf bzw. bei einigen ROMs auch bcm_supp.conf und öffnet diese mit einem Texteditor. Der ES File Explorer hat einen integriert.
4. Dort könnt ihr die W-Lans mit ihren entsprechenden Keys im Klarformat lesen.

Im September hatte ich die App LBE Privacy Guard schonmal vorgestellt, doch seitdem ist viel passiert. Die komplett überarbeitete Version 2 mit zusätzlichen Funktionen erschien. Zeit sich diese Top App nochmals anzuschauen.

Eins vorweg: LBE Privacy Guard benötigt zwingend Root!

Beschreibung von LBE Privacy Guard aus meinem damaligen Post:

Obwohl man bei Android bereits bei der Installation die angeforderten Rechte der App einsehen kann, schützt das noch nicht vor Missbrauch. Eine Radioapp sollte meinen Standort kennen, um mir lokale Sender anzubieten. Aber muss sie das alle 25 Minuten machen, selbst wenn ich sie nicht nutze? Weswegen will ein Kalenderwidget ständig meine Kontakte abfragen? Warum braucht die Facebook App viel mehr Rechte als eigentlich sinnvoll? Hier kommt der LBE Privacy Guard ins Spiel, der den Nutzer erstmal um Erlaubnis fragt, bevor der jeweiligen App die entsprechenden Berechtigung gewährt wird. Verneint ihr diese Abfrage, bekommt die App diese Rechte diesmal auch nicht. Aber nicht nur das. Man kann Apps bestimmte Berechtigungen auch permanent verbieten. Die Google+ App geht euer Standort gar nichts an? Standortabfrage verboten!  Ihr bezweifelt, dass dieses oder jenes Spiel die IMEI eures Droiden für den reibungslosen Ablauf benötigt? Zugriff verwehrt! Facebook soll nicht eure komplette SMS-Kommunikation mitlesen können? Kann es nun nicht mehr!
Das ist ziemlich genau der Kern der Aussage. LBE Privacy Guard fungiert als Firewall für nahezu jegliche App Abfrage. Bevor eine App eine bestimmte Info einholen kann, werdet ihr standardmäßig gefragt. Will also Google Maps euren Standort wissen oder Facebook auf eure SMS Konversationen zugreifen, blendet LBE Privacy Guard vorher eine Anfrage ein, ob ihr dies denn auch wirklich erlauben wollt. Antwortet ihr 20 Sekunden lang nicht darauf, wird dies automatisch verneint. So wird effizient verhindert, dass Informationen an Apps gegeben werden, die ihr nicht weitergeben wolltet. Neu hinzugekommen ist seit Version 2 die Möglichkeit des Traffic Monitorings. Quasi ein eingebauter 3G Watchdog. Ich halte nicht viel von diesen Watchdogs, da die meisten Smartphonebesitzer wohl eine Flatrate haben sollten, die lediglich nach einem bestimmten Volumen gedrosselt wird. Für jene, deren Volumen begrenzt ist, sind diese Funktionen aber eventuell sehr nützlich.

Das Menü ist in 5 Untermenüs aufgeteilt. Unter Internet könnt ihr den Watchdog einstellen und Apps den Zugriff  auf  das Internet erlauben oder verbieten. Im Privacy-Menü könnt ihr alles regeln, was mit persönlichen Daten zu tun hat, SMS, Kontakte, Anrufliste, Positionserfassung und Phone ID. Das Money-Menü bietet alle Einstellungen, um Apps den Versand von SMS oder das Tätigen von Anrufen zu verbieten. Unter Applications werden euch alle überwachten Apps und auch die von euch als vertrauenswürdige Apps definierte Programme angezeigt. Via Settings kommt ihr natürlich in die Einstellungen.

Sehr interessant ist auch die Log-Funktion von LBE Privacy Guard. In dieser könnt ihr sämtliche Anfragen aller überwachten Apps nachvollziehen. Das ist vor allem deswegen interessant, weil man die meisten Anfragen nicht mitbekommt, da das Handy ja in der Tasche ist. So ist mir bei meinem damaligen Test die App TuneIn Radio negativ aufgefallen, weil sie in einem recht kurzen Intervall versuchte, meinen Standort abzufragen. Selbst wenn sie grade nicht lief. Gleiches galt damals übrigens bei Google Maps.

Fazit: Auch diesmal wiederhole ich mein Fazit. LBE Privacy Guard ist eine MUST-HAVE App für jedes gerootete Smartphone. Der dadurch gewonnene Privatssphäre und auch Sicherheitsgewinn ist unersetzlich.

Kleine Anekdote mit integrierter Anleitung: Zu Testzwecken habe ich grade mal den Download Manager Flashget 3.7 installiert. Den Installer habe ich direkt von der Website des Herstellers heruntergeladen, den englischsprachigen Installer ausgeführt, das Programm installiert. So weit, so langweilig. Doch dann startet das Programm und zeigt mir so eine GUI an:

Da mein Chinesisch etwas eingerostet ist, wollte ich die Sprache umstellen, klappte aber nicht. Egal welche Sprache ich auswählte und egal welche Sprachversion des Programms ich installierte, es blieb chinesisch. Das hat mich dann doch etwas angespornt, deswegen habe ich ein bisschen und in den Programmdateien geschnüffelt und bin auch recht schnell fündig geworden.

Die Vorgehensweise ist für Windows XP, dass sie bei den neueren Betriebssystemen von Microsoft identisch ist, kann ich nicht garantieren.

Zuerst solltet ihr natürlich alle eventuell offenen FlashGet-Sitzungen beenden. Öffnet nun die Datei FGResDetector.conf, die sich im Unterverzeichnis FGResDetector_I\data eures FlashGet Verzeichnisses befindet (standardmäßig C:\Programme\FlashGet Network\FlashGet 3\FGResDetector_I\data).

Ändert dort den Eintrag

CurLanguage=E:\WorkSpace\FlashGet_3\output\FGResDetector_I\Lang\l.eng.xml

entsprechend eurem Pfad zur l.eng.xml. Bei einer Standardinstallation sähe die Zeile dann so aus:

CurLanguage=C:\Programme\FlashGet Network\FlashGet 3\FGResDetector_I\langl.eng.xml

Wenn ihr FlashGet jetzt startet, habt ihr eine klar lesbare englische Oberfläche.

Der ganze Aufwand war übrigens nutzlos, da das Programm das Protokoll, für dessen Download ich es installiert hatte - das  Real Time Streaming Protokoll, kurz RTSP - trotz andere Angaben auf seiner Website nicht beherrscht.