Nochmal Cyanogenmod für das Samsung S+ i9001 - aber anders

Wie schon neulich erwähnt, sind meine Kinder recht destruktiv mit ihren Handys, und Kind 2 macht da keine Ausnahme, er versucht derzeit, Kind 1 einzuholen.

Er hat es geschafft, das Samsung S+ so elegant zu biegen, dass das Display kaputt ist, aber das Glas intakt - auch schon eine Kunst.

Der Ärger ist natürlich da, aber der finanzielle Verlust ist nicht ganz so groß wie beim verlorenen iPhone 5 von Kind 1. Das S+ hat bei einem ebay-Händler nur knapp 60 € gekostet.

Das Handy hatte sogar noch eine ältere Android-Version als das erste i9001, das ich im Frühjahr zum Geburtstag des Lütten beschafft hatte. Damals war es 2.3.5, dieses kam mit 2.3.3 zu mir.

Beim Aufladen vor dem Neu-Flashen erst mal Schreck: ein Warnsymbol neben dem Akku. Da ich das alte Handy noch hatte, konnte ich den Akku auswechseln und war wieder beruhigt. Es war wirklich nur der Akku und nicht die Ladeelektronik im Handy wie beim Wasserschaden in einem S2 von Kind 1.

Nach dem Aufladen ein bißchen Herumspielen mit der alten Android-Version und die wohlige Gänsehaut genießen bei dem Gedanken, dass es bald die fast noch aktuelle 4.3.1 bekommen wird ;)

Nachdem ich eine SD-Karte mit dem passenden Custom Recovery, Custom ROM und den Google Apps für Android 4.3 eingebaut hatte, wollte ich den Samsung Recovery Mode starten, um zunächst ein anderes Recovery zu flashen, mit dem es dann möglich ist, ein Custom ROM zu flashen.

Merkwürdigerweise ließ sich zwar so etwas ähnliches wie ein Recovery Modus starten, aber dort gab es kein Menü, um andere Software zu installieren, sondern nur eine kleine Grafik mit einem Pfeil und einem kleinen grünen MännchenAndroiden. Vielleicht lag es auch nur an meinen dicken Fingern, dass ich immerzu den Zeitpunkt verpasste, nach dem Einschalten die Menü-Taste zu drücken, um ins Recovery zu gelangen. Schwer zu sagen ;)

Also eine andere Idee entwickelt: im Play Store gibt es eine App "ROM Manager", die einen Menüpunkt "Reboot to Recovery" beinhaltet. Damit sollte es möglich sein, ohne langwieriges Gefummel ins Recovery-Menü zu gelangen.

Aber natürlich war es nicht ganz so einfach: der ROM Manager erfordert ein gerootetes Handy, weil die Änderungen am Bootloader tiefe Eingriffe erfordern.

Nächste Frage also: wie rootet man ein i9001? Es gibt mehrere Verfahren, das bequemste ist das "Kingo Root Tool", das eine ganze Menge Handys erkennt und rooten kann. Dieses Tool war auch bei mir erfolgreich.

Danach konnte der ROM Manager das Recovery starten, ich konnte das gewünschte Custom Recovery flashen und danach ging es recht zügig, das ROM mit CyanogenMod und die Google Apps auf's Handy zu bringen.

Neues von den Fahrtkosten - Leserbrief

Und die unendliche Geschichte geht in die nächste Runde. Die ersten Eltern ziehen vor Gericht.
(veröffentlicht am 23.09.2014)

Leserbrief zur Fahrtkostenübernahme der VGO

Und es macht "bing" - die nächste Runde "Eltern gegen VGO" ist eingeläutet.
Die WZ berichtet über die erste eingereichte Klage.
Ich kann nicht ganz nachvollziehen, was genau die VGO hier plant.
Der Kreistag beschließt einstimmig eine Aufforderung für ein Moratorium.
Danach lehnt der Kreisausschuss einen entsprechenden Antrag wegen Formfehlern ab.
Die VGO droht mit exorbitanten Gebühren, wenn ein Widerspruchsbescheid erlassen wird, um die Eltern abzuschrecken.
Dabei wird sehr unsanft vorgeschlagen, den Widerspruch zurückzunehmen, um diese Gebühren zu vermeiden.
Leider bedeutet die Rücknahme des Widerspruchs, dass die Eltern dann ihren Anspruch auf Fahrtkostenerstattung verlieren, selbst wenn andere Eltern mit ihren Klagen erfolgreich sein sollten.

Dabei vergisst die VGO, dass sie in der Vergangenheit schon mehrere Prozesse vor Gericht verloren hat, sowohl wegen Formfehlern als auch wegen sachlicher Fehler in der Beurteilung der Fahrtkostenübernahme.
Dem Kreiselternbeirat liegt ein Urteil von 2006 vor (4E 865/06 VerwG Gießen), in dem bei einer gemessenen Entfernung von 2,9 km nach einer Begehung die "besondere Gefahr" durch den Richter festgestellt wurde. Es ging in diesem Urteil um den Schulweg von Dortelweil aus, wobei der Weg einige hundert Meter hinter Gebüsch nicht einsehbar war, und sogar beleuchtet ist.
Ironischerweise war damals ebenfalls schon Armin Klein der Beklagte als Vertreter der VGO.

Erstaunlicherweise ignoriert die VGO sowohl alte Urteile als auch die Einschätzungen von fachkundigen Beteiligten an den aktuellen Begehungen. Der Melbacher Schulweg z.B. führt ebenso über einen nicht einsehbaren Feldweg in vergleichbarer Länge, und im Gegensatz zum Dortelweiler Fall ist dieser Feldweg nicht einmal beleuchtet. Hier hat die Polizei den Weg in ihrer Stellungnahme als "besonders gefährlich" bezeichnet.

Das ficht aber die VGO nicht an - sie stuft die Schulwege nach erfolgter Begehung einseitig als "gefährlich" oder "ungefährlich" ein, ohne dass klar wird, welche Grundlagen die jeweiligen Entscheidungen haben.

Ich hoffe ernsthaft darauf, dass die Politik sich besinnt und dem Vorpreschen der VGO zügig Einhalt gebietet, bis eine gemeinsame, sachliche Grundlage für die Beurteilung der Schulwege gefunden wurde, die für die Eltern nachvollziehbar ist. Es kann nicht sein, dass die VGO hier vor den echten Fakten davonrennt und versucht, selbst andere, vollkommen realitätsferne Fakten zu schaffen.

Signierten Code mit Java erstellen

Man hat's nicht leicht, mit den ganzen Updates Schritt zu halten ... Dauernd Sicherheitslücken in Windows, Flash, Java, sogar in Android findet sich die eine oder andere Lücke.

Um den Erfolg der Updates zu überprüfen, insbesondere für Flash und Java, hatte ich mir vor langer Zeit eine ganz primitive Webseite erstellt, die mir die aktuellen Versionsnummern der installierten Plugins anzeigen kann.

Seit Version 1.7 der Java Runtime werden aber lästige Warnungen ausgegeben, dass demnächst nur noch signierter Code ausgeführt wird, dass Code, der von http- und nicht https-Schema nachgeladen wird, als unsicher betrachtet wird, und überhaupt lassen die Sicherheitseinstellungen der JRE demnächst gar nix mehr zu.

Also hab ich mich mal drangesetzt und aus meiner .class-Datei eine .jar-Datei gemacht, die ich mit meinen eigenen, selbst erstellten Key signiert habe. Das ist aber natürlich nur die halbe Miete, weil man auch der JRE im Browser klarmachen muss, dass der self-signed Code auch wirklich zulässig ist. Man muss also in der policy-Datei auch noch Änderungen vornehmen. Hier ist der ganze Ablauf zusammengestellt, den ich durchlaufen musste, bis meine simple JRE-Versionsabfrage mit Firefox 31, Chrome 36 und JRE 1.8.0.11 wieder funktioniert hat.

Hier ist zunächst der Code für die Ausgabe der JRE-Versionsnummer:

import java.applet.Applet;
import java.awt.Color;
import java.awt.Label;
public class JavaVersionDisplayApplet extends Applet
{
  private Label V;
  public JavaVersionDisplayApplet() {
    this.setBackground(Color.pink);
    V = new Label(" Java Version: " + System.getProperty("java.version") + " from " + System.getProperty("java.vendor"));
    this.add(V);
  }
}

Um diesen Code zu kompilieren, muss das Java Development Kit mit dem javac-Compiler installiert sein. Da Java einigermaßen kompatibel zu alten Versionen ist, kann man auch mit einer aktuellen JRE wie 1.8 noch Code ausführen, der mit Version 1.4 kompiliert wurde. Eine Krankheit von Java ist, dass der Dateiname exakt dem Klassennamen in der Datei entsprechen muss, hier also "JavaVersionDisplayApplet.java".

javac JavaVersionDisplayApplet.java

Als nächstes müssen noch zwei Dinge vorbereitet werden: ein Schlüsselpaar für das Signieren und eine Manifest-Datei, in der der Java-Code etwas genauer beschrieben wird, also etwas poetischer gesagt: Meta-Daten.

Zunächst also das Schlüsselpaar mit dem Programm keytool erzeugen, dass bei der JRE und beim JDK mitgeliefert wird.

keytool -genkeypair -alias thomas -keystore seeling.jks -dname "CN=Thomas Seeling, OU=System Administration, O=Kleintierpraxis Berstadt, L=Berstadt, ST=Hessen, C=DE" -keypass Password1 -storepass Password2

Im weiteren verwende ich immer den Aliasnamen "thomas" für den Schlüssel. Je nach Zusammenhang ist damit entweder der private oder der öffentliche Schlüssel gemeint.

Als nächstes benötige ich noch den öffentlichen Schlüssel separat, damit ich ihn in meinem Browser importieren kann. Dieser Schritt würde entfallen, wenn ich den Schlüssel von einer öffentlichen Root CA signieren lasse oder wenn ich mir selbst eine Root CA gebaut habe und den öffentlichen Schlüssel dieser Root CA schon in meinem Browser hätte.

keytool -export -keystore seeling.jks -alias thomas -storepass Password2 -file tseeling.cer

Ich mag meine Schlüssel lieber in base64-kodiert, also wandle ich die binäre .cer-Datei noch in eine PEM-Datei um:

openssl x509 -in tseeling.cer -inform DER -out tseeling.pem -outform PEM

Weil dies "nur" ein öffentlicher Schlüssel ist, benötige ich nach dem Export aus dem Java-Keyring kein Passwort mehr.
Diese PEM-Datei kann ich nun bequem über ein Transportmittel wie Email, ftp etc. zu meinem Browser-PC übertragen und dort importieren.

Desweiteren benötige ich die schon erwähnte Manifest-Datei, die mit in die .jar-Datei gepackt und signiert werden muss. Diese Datei sieht bei mir so aus:

Permissions: sandbox
Codebase: https://admin.moeller-seeling.local/*
Application-Name: JavaVersion

Der "Application-Name" ist hier nur "Schmuck am Nachthemd" und wird für eine Infobox benötigt, in der die JRE dem Benutzer anzeigt, wer da gerade ausgeführt werden soll.

Wenn das alles zusammengestellt ist, wird nun in zwei Schritten aus der kompilierten Java-Datei und dem Manifest zunächst eine .jar-Datei erzeugt und dann diese Datei mit dem zuvor erstellten privaten Schlüssel signiert.

jar -cfm JavaVersion.jar JavaVersion.txt JavaVersionDisplayApplet.class

jarsigner -keystore /opt/jdk/jre/lib/security/seeling.jks -keypass Password1 -storepass Password2 -verbose JavaVersion.jar thomas 

 Puh, fast geschafft! Jetzt noch diese .jar-Datei in einem kleinen HTML benutzen und vom Webserver ausliefern lassen. Darauf gehe ich nur ganz kurz ein, hier ist ein Beispiel für den HTML-Code:

<table border="1">
<tr><th> The version and vendor from the JRE</th>
<td align="center">
<applet height="60" alt="Browser has Java disabled"
hspace="22" width="440"
archive="JavaVersion.jar"
code="JavaVersionDisplayApplet.class">
</applet>
</td></tr>
</table>

Soweit, so gut. Das war der erste Schritt auf dem Webserver.

Auf dem Browser-PC sind auch noch kleine Schritte nötig, damit man ein self-signed .jar ausführen darf:
man muss in die Security-Policy einen Eintrag machen, dass signierte Dateien von bestimmten Programmierern erlaubt sind, und man muss den öffentlichen Schlüssel dieses Programmierers in den Standard-Keystore der JRE importieren, die der Browser im Java-Plugin verwendet, oder alternativ einen anderen Keystore angeben, in dem dieses Zertifikat enthalten ist.

Auf Windows findet sich das unter "%ProgramFiles(x86)%\java\jre8\lib\security\java.policy" (für die Java-Version 1.8).

Zu dieser (i.a. schon vorhandenen Datei) im Klartextformat habe ich folgende Einträge hinzugeführt:

keystore "file:${java.home}/lib/security/seeling.jks", "jks";
grant signedBy "thomas" {
  permission java.security.AllPermission, signedBy "thomas";
};

Zu der Liste der vertrauenswürdigen Zertifikate habe ich meinen öffentlichen Schlüssel hinzugefügt, den ich weiter oben als PEM-Format gespeichert hatte.

keytool -importcert -noprompt -trustcacerts -alias thomas -file tseeling.pem -keystore "%ProgramFiles(x86)%\java\jre8\lib\security\cacerts" -storepass changeit

Das Passwort der Schlüsseldatei "cacerts" ist üblicherweise "changeit". Natürlich ändert es nie jemand ;)

So, nachdem also nun ganz viele kleine Gemeinheiten geschafft sind, müsste im Browser ein Applet funktionieren, das die JRE-Versionsnummer ausgibt. Wenn man auch nur einen dieser Schritte weglässt, klappt es nicht und entweder der Browser oder die JRE beschimpfen mich, dass alles ganz schröcklich unsicher ist.