Posts by Mquadrat

Sehr gute Entscheidung!
MIUI sollte primär für Mi's gepflegt werden, alles andere (Der ganze jämmerliche Rest) sollte dann nur nebenbei erledigt werden, falls Zeit dafür ist.

http://en.miui.com/thread-29327-1-1.html

[Blocked Image: http://marvinbeer.de/miui/Mi4.jpg]

Mi 4— The Fastest & Most Gorgeous Mi Phone Ever.
- Stainless steel frame, unbelievable craftsmanship & polish
- Snapdragon 801 chipset, 3GB RAM, 16/64GB Flash
- 5-inch 1080p IPS display, very high colour gamut (84% of NTSC range)
- 13MP rear camera, f1.8, real-time HDR, 4K video recording (Sony IMX214)
- 8MP front camera, f1.8, 80-degree wide angle (Sony IMX219)
- 3080 mAh internal battery, quick charging at 9V/1.2A or 5V/2A
- Swappable back plate
- UMTS & TDD-LTE support (internationally FDD-LTE availability TBA)
- Approx 320 USD for 16GB, 400 USD for 64GB

[Blocked Image: http://marvinbeer.de/miui/Mi4Side.jpg]
[Blocked Image: http://marvinbeer.de/miui/Mi4UR.jpg]
[Blocked Image: https://lh5.googleusercontent.com/-vNiA2zXyKu4/U84dtUUUY5I/AAAAAAABq04/v_-F_6NEnR8/w692-h782-no/X4.007_%25E5%2589%25AF%25E6%259C%25AC.jpg]

hyJahhN7C2c
ZAryl6EXyWE

Der Updater funktioniert noch nicht korrekt mit dem aktuellen Update 4.7.18

Gern geschehen

Ich rate mal ins Blaue: Das war sicher der "NFC Tag read failed" Sound.

Hast du dein Mi3 in einer Hülle mit irgendwelchen Karten, die evtl NFC/RFID Tags enthalten?

Tipp: NFC in den einstellungen abschalten.

Kaufe ich (Beide!)

>=1,3A bei 5V sollten es schon sein!

Welchen Test nutzt du? Bedenke, dass die Gegenseite ebenfalls die Leistung bringen muss.
Wenn der Test Server nur eine 100Mb/s Anbindung besitzt, kann es schonmal eng werden. Auch ein 1Gb/s Server kann, je nach IOPS, mal überlastet sein.

Benutzt du eine Anti-Virus-APP?

Ich empfehle folgendes:
1. [Blocked Image: http://www.marvinbeer.de/miui/WLAN1.png]
2. [Blocked Image: http://www.marvinbeer.de/miui/WLAN2.png]
3. [Blocked Image: http://www.marvinbeer.de/miui/WLAN3.png]

Wie? Ich habe kurz gesucht und folgendes gefunden:

java -jar signapk.jar testkey.x509.pem testkey.pk8 [unsigned.zip] [signed.zip]

Soweit ich weis ist eine .pem alleine nicht ausreichend um etwas zu zertifizieren, sondern eher um es zu bestätigen.
Kann sein dass die Vorgehensweise der Zertifizierung von SSL & co und Andoid abweicht.

Kurz: .pem ist IMHO ein öffentlicher Schlüssel, dieser ist zum zertifizieren ungeeignet.

Edit: Vllt. hilft das: http://code.metager.de/source/…/target/product/security/

Bitte entschuldigt den tripple post.

Ich habe inzwischen schnell mal in den Quellcode geschaut.

folgendes ist der Punkt, an welchem man ansetzen sollte:

Datei: https://github.com/MiCode/miui…lob/master/src/verifier.c

function: verify_file() //Welche sonst?...

Die Frage scheint also: Wie signiert man die custom-OTA-ROM, damit diese vom MiRecovery angenommen wird? Ich denke, das könnte schwierig werden ohne die entsprechenden Zertifikate.

Quote from San Blarnoi

Hm, wenn der Hash tatsächlich "falsch" wäre, warum lassen sich die .zip dann via Updater und manuell via recovery installieren?
Weil diese Prüfung dort nicht durchgeführt wird?

Das wäre dann die Aufgabe des ROM-Erstellers, oder wie meinst du das jetzt?

Evtl. wird eine "Quell"-Prüfung durchgeführt? Hier könnte die IP, die URL oder sonstwas des files geprüft werden.
Ich mag solche blind-Vermutungen nicht. Ich bin aber inzwischen sicher, dass es nichts mit der Datei an sich zu tun hat.

Super. Danke für das Log.

Das bestätigt meine Vermutung:

Verifying update package…
I:verify_file returned 1

Was passiert hier?
Der Quellcode der diese results ausgibt wäre sicher hilfreich.
Fakt ist, dass ein hash-check fehlschlägt. Nun ist die Frage: Was wird gehasht? Woher stammt der erwartete Wert?

Da praktisch jedes neue Update einen anderen Hash hat, kann an dieser Stelle kein Hashing auf den Inhalt stattfinden. Es muss etwas oberflächiges sein.

Zu prüfen wäre auch, warum 3 gefordert wird, bevor /res/keys überhaupt geladen wird. Hardcoded?
Das kann aber auch ein log-fault sein.

Für mich logisch wäre:

- Update Datei finden
- Update Datei hashen, Ergebnis speichern
- Erwartete Hashes laden
- Vergleichen

Die Frage ist nun: Wenn die 3 als Hash fix ist, die Datei /res/keys vor dem Update gelesen wird.... woher kommt diese Datei, was steht darin?
Ein Hash abgleich ist IMHO an dieser Stelle zwecklos - wenn der hash den INHALT des Updates darstellt.
Zwei möglichkeiten: 1. Der Hash ist sinnlos.
2. Der Hash dient nur einer nicht variablen Überprüfung. Also einer Konstante wie bsp. weise des Dateinamens.

I:Update location: /cache/u.zip
-- die nächsten 3 Zeilen sind neu und warten auf eine Interpretation
I:read key e=3 hash=20
I:1 key(s) loaded from /res/keys
I:verify_file returned 1

1. Wird die Datei /cache/u.zip gefunden.
2. Kommentar
3. Wird ein Hash berechnet. Das Ergebnis wird ausgegeben (Hash == 20)
4. Hier wird eine Datei geladen die erwartete (fixe???) Hashwerte enthält. (in dem Fall sollte der Hash == 3 (e(expected)=3) sein. Aber der Hash der Datei u.zip ergibt 20. (Ich könnte mir jetzt den Sourcecode angucken, wie der Hash berechnet wird, habe dazu derzeit aber keine Zeit. Vielleicht morgen.)
5. Weil der Hash nicht passt, wird 1 statt 0 returned.
Würde der Hash passen, würde 0 returned und alles wäre schick. (C++ basics) 1 löst hier offensichtlich einen break aus.

Aufgabe: Hash-Algorithmus finden, verstehen, anpassen.

Vermutung: Ein Hash Wert von 3 wird erwartet, einer von 20 berechnet - viel kann hier nicht passieren. Evtl. reicht schon der Dateiname um diese Abweichung zu erzeugen. Ich will mich an dieser Stelle nicht zu weit aus dem Fenster lehnen - auch weil ein Hash eigentlich eine fixe Länge hat, was hier offensichtlich nicht der Fall ist.

Anmerkung: Das Interesse ist meinerseits schon vorhanden. Leider habe ich den Thread bisher übersehen. Die Struktur des Forums von MIUI Germany ist eben nicht die optimalste.

Trotzdem DANKE! für dein Engagement.

Unterhalb der Ohrmuschel liegen CPU+GPU, RAM und ROM.
Wenn das Mi3 etwas zu tun hat, wird es logischerweise dort oben zuerst warm. Das ist also normal und nicht zu beanstanden.

Deine Schilderungen bezüglich des Speakers sind jedoch frappierend.

Quote from athlone

Ich habe mir das Archiv auf meinem Laptop noch einmal heruntergeladen und diesmal mit McAfee prüfen lassen.
McAfee hat an dem Archiv nichts auszusetzen.
Ist McAfee besser oder war die Prüfung nur luschig?

Kasperskys heuristik-Engine hat bei der Datei angeschlagen. Das kann bei heuristik mal vorkommen. Besser einmal zu viel als einmal zu wenig gewarnt. Kaspersky ist in jedem Fall die bessere Wahl.

Das virus lab hat sich leider noch nicht gemeldet.
Du kannst die Heuristik deaktivieren, bist dann jedoch nicht mehr so gut vor noch unbekannten und neuen Bedrohungen geschützt.

Mein Link zu virus Total weiter oben zeigt ja eindeutig, dass die Datei (sehr wahrscheinlich) nicht gefährlich ist.

Habe die fragliche Datei zu Virustotal hochgeladen: Es scheint sich um einen Fehlalarm zu handeln.

https://www.virustotal.com/de/…ec1e/analysis/1404738955/

Ich schicke die Datei an Kaspersky zur Analyse. Dann können die den Fehlalarm, sofern es einer ist, korrigieren.

Edit: Kaspersky hat geantwortet. Die Datei wurde zur weiteren Analyse ans Virus Lab weitergeleitet.

Kann ich bestätigen:

[Blocked Image: http://marvinbeer.de/miui/KAVFound.JPG]

Datei: miui-ger_MI3W_4.7.4_4.4.zip
CRC-32: 87ee8b74
MD4: 04f02c8409404989454844fe5a5140b6
MD5: c230fc905612a64896ce81abaa112b85
SHA-1: 3bdac3d1d570b15162b517595f47e3e5d44ab01c

Treiber, Linux, Kernel? Passt ja gar nicht.

Jetzt mal /Ironie off:

Warum postest du hier, wenn du dann doch auf den Schneid kommst, mal bing/google etc. zu benutzen?

Du hast Post.