Technische Diskussion zu KNOX - Sammelthread

  • 1.225 Antworten
  • Letztes Antwortdatum
JTag sind die stöpsel für den mUSB Anschluss oder???
 
Dass sind die USB-JIGs die du meinst.
Jtag wird soweit ich weiss direkt ans Mainboard gehalten.
 
Hallo zusammen, ich hatte mein S4 letztens bei der Reperatur (mit Knox 0x1). Dort wurde mir dann Android 4.3 aufgespielt, und alles lief soweit perfekt.

Seit gestern bekomme ich aber immer wieder diese Meldung
uploadfromtaptalk1383577985118.jpg

Und gerade eben hab ich mal nach evtl verfügbaren Updates gesucht und plötzlich bekomm ich diese Meldung
uploadfromtaptalk1383578087002.jpg

Ich hab seit dem mein S4 in der Werkstatt war an der Software nichts mehr gemacht, also weder root noch CFW oder der gleichen...

Weiß jemand was das sein kann?

LG ReiNi
Gesendet von meinem GT-I9505 mit der Android-Hilfe.de App
 
So, nachdem mein aus Italien bezogenes S4 nun auch endlich das Update auf 4.3 bekommen hat, hab ich kein Problem mehr mit dem Knox-Quatsch. Ich kann endlich Arduinos über ArduinoDroid beschreiben, wie es sein sollte :)
 
Also zur ersten Meldung von Knox kann ich sagen das wir die alle bekommen. Dagegen kann man nix machen aus für 30 Tagen ignorieren.
 
Es geht in diesem Thread im Übrigen um Informationen zu Knox, es geht nicht um Einzelfälle bei denen dieses oder jenes Problem auftritt, nachdem User dieses oder jenes getan haben.


Back 2 Topic:
Mit dem Einsatz von SE Android im Galaxy S4 soll verhindert werden, dass bei der Kompromittierung eines einzelnen Teils des Systems, auch die anderen Teile kompromittiert werden.
Im Klartext: spielt man z.B. am ROM herum, dürfen sich mögliche Veränderungen ( = potenzielle Gefahrenquellen) nicht auf den Kernel oder das OS selbst auswirken.
 
aber nicht mehr lustig wenn man keine NTFS Geräte einwerfen kann, wenn die exfat schaffen, sollen die auch NTFS hinbekommen. das Normale Linux das ich kenne kommt mit NTFS Platten klar aber nicht mit exfat, warum nimmt man sich net die NTFS Treiber der Linux Community???
 
hulkhardy1 schrieb:
Also zur ersten Meldung von Knox kann ich sagen das wir die alle bekommen. Dagegen kann man nix machen

:D... bitte nicht pauschalieren :cool:
Nur mit Knox Firmware nebst neuem Bootloader bekommt man diese nervigen Nag Screens zu sehen :rolleyes:
 
Weitere technische Details von .NetRoller 3D. Anscheinend sind viele S4 auf Qualcom Basis, also Snapdragon, mit einem eMMC in Version 4.5. Also ohne eFuse Support.

Apparently my RPMB theory is right then.

We know so far:
-Samsung can reset the flag without altering any hardware.
-The flag is in the eMMC.
-Apparently not in either the Boot or User partition areas.
-The flag is not a Samsung extension to eMMC, as some Qualcomm S4s have Toshiba eMMCs.

That leaves only RPMB, or unpartitioned boot or user space, both moddable.

Do we have decrypted bootloader images to analyze?

Sent from my GT-I9305 using xda app-developers app
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: raoul_duke, paddyonfire und Nightly
Es tut sich was, mit etwas Glück ist zumindest das Thema Knox Flag bald keines mehr. Fraglich, ob - sofern es einen workaround geben sollte - dann auch wieder nativ root möglich sein wird? :confused:
 
@ollborg

Woher hast du diese ganzen Infos? Habe bisher nicht so viel über RPMB und eMMC rausfinden können ;)
 
XDA Threads lesen ;-)
Google und Fachlektüre nutzen B-)
... lesen und lernen, vermutlich :p:cool:
 
  • Danke
Reaktionen: flosch1980 und ollborg
Ich möchte mich aus dem Samsung Forum verabschieden. Hatte jedes Samsung aus der Galaxy Reihe. Manche sogar doppelt. Mit Knox hat Samsung den Bogen überspannt. Hab mir heute ein schwarzes HTC ONE gegönnt.

over and out.
 
  • Danke
Reaktionen: atarifreak73, Cysign, HaPe1968 und eine weitere Person
Was soll denn der ganze OT und könnt ihr denn nicht einfach beim Thema bleiben?
Lange werden sich die Moderatoren nicht mehr mitmachen und den Thread komplett dichtmachen.
Es gibt auch noch Leute die einfach mehr über Knox erfahren möchten
und nicht ob du dir ein HTC gekauft hast!
ALSO einfach zurück zum Thema!
 
Ich denke da wird was kommen um dieses Flag zurückzusetzen, aber prinzipiell ist mir das zur Zeit egal. Mein KWVF steht auf 0x1 weil ich bewußt gerootet habe, es funktioniert ja auch bis auf KNOX alles ohne Probleme.
Ich sehe aber eher darin ein Problem das es eine Lösung geben wird und man das KWV Flag zurücksetzen kann.
Warum?
Weil dann im Prinzip KNOX komprimierbar wird, was nicht im Sinne von Samsung sein dürfte. Das wiederum bedeutet dass die versuchen werden neue Hürden einzubauen. Das wird dann ein Hin und Her geben, was keiner braucht, schon gar nicht der durchschnittliche Galaxy User und der ist sicherlich kein Enterprise User.
Samsung sollte um so etwas zu vermeiden eine Funktion einbauen (im Stock Recovery, oder sonst wo) die es jedem ermöglicht dieses Flag zurückzusetzen, dabei wird dann eben der KNOX Container gelöscht (inklusive Full Wipe wegen Root), so dass ein unberechtigter Zugriff auf diesen unmöglich ist.
Dies ist meiner Meinung nach der Grund warum Samsung das KNOX Warranty Void Flag geschaffen hat.
Ich glaube auch dass sich das Warranty Void auf KNOX bezieht und nicht auf die Geräte Garantie.
 
Wurde eben hiermit begrüßt :D

 
wozu n Fullwipe warum net Knox löschen und deaktivieren solange bis kein Root mehr da ist.
ein Full wipe ist kein unrot...
 
  • Danke
Reaktionen: Tanis64
@ADizzle
Diese Sicherheitsrichtlinie taucht dann auch unter SELinux-Status auf
Bei mir ist noch die 0011

@My1
Oder so,
aber leider wird Samsung so was eh nicht einbauen.
Wäre ja zu schön
 

Anhänge

  • uploadfromtaptalk1383721677306.jpg
    uploadfromtaptalk1383721677306.jpg
    41,8 KB · Aufrufe: 497
Zuletzt bearbeitet:
Hat jemand Informationen, was Bestandteil dieser Sicherheitsrichtlinien ist?
 
Nein leider bisher nicht, das ist ja das Problem. Was ist drin, wer steuert dies, wer kontrolliert diese Zugriffe? Wer bestimmt künftig darüber, welche Apps ausgeführt werden dürfen? Werden Dinge ausgeführt, von denen ich das nicht möchte? Leider alles nebulös.

Der Zugriff durch Samsung ist bestätigt, durch den Screenshot. Dieser Zugriff wird laut Screenshot (einmal bestätigt) dauerhaft (nach Ermessen von Samsung) Security Policy Updates einspielen und alte Policies automatisch ersetzen.

Ich würde mich wirklich sehr freuen, wenn jemand den Inhalt eines Security Policy Updates entschlüsseln und offen legen kann. Dies würde auch sehr helfen die Verschwörungstheorien zu entkräften.

originals4.jpg

Update: Habe jemanden gefunden, der sich schon einmal damit beschäftigt hat. Leider erfolglos. Er hat versucht dies auf einem Google Edition S4 herauszubekommen, scheint aber dem normalen S4 gleich zu sein.

http://securityblog.org/2013/07/08/se-for-android-gs4-gpe/

Interessant finde ich die Feststellung vom Verfasser, dass jede 3. Party App ein Update für SE Android Policies einspielen kann, von überall her. Durch die API ist dies, laut Verfasser, auch einfach über das Netz möglich.

Gescheitert ist der Verfasser letztendlich an einer digitalen Signatur. Mit Root Rechten konnte er seine Policy (per Zertifikat) zwar einlesen und die Policy tatsächlich einspielen nach /data/security/contexts. Aber sichtbar wurde nur ein "Current" Symlink, kein weiterer Code. Die eigene Policy wurde auch nicht beim Booten angezogen.

Signiervorgang per Zertifikat:

# cd /data/data/com.android.providers.settings/databases
# sqlite3 settings.db "INSERT into secure (name, value) VALUES('config_update_certificate','<your public DER cert>');

Wenn dies alles so stimmt, schließe ich daraus, dass der Mechanismus anfällig ist. Ist das Zertifikat der Signatur bekannt oder wird geknackt, können dritte SE Policy Updates durchführen.
Schade das nicht mehr über den Inhalt der Updates bekannt ist.....
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: My1

Ähnliche Themen

B
Antworten
3
Aufrufe
1.130
Blacky12
B
M
Antworten
3
Aufrufe
1.579
Julian23
Julian23
Kusie
Antworten
2
Aufrufe
1.951
558958
5
Zurück
Oben Unten