M
My1
Dauer-User
- 208
JTag sind die stöpsel für den mUSB Anschluss oder???
Kouya1600
Stamm-User
- 138
Dass sind die USB-JIGs die du meinst.
Jtag wird soweit ich weiss direkt ans Mainboard gehalten.
Jtag wird soweit ich weiss direkt ans Mainboard gehalten.
ReiNi1281
Ambitioniertes Mitglied
- 25
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
Und gerade eben hab ich mal nach evtl verfügbaren Updates gesucht und plötzlich bekomm ich diese Meldung
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
Seit gestern bekomme ich aber immer wieder diese Meldung
Und gerade eben hab ich mal nach evtl verfügbaren Updates gesucht und plötzlich bekomm ich diese Meldung
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
C
Cysign
Stamm-User
- 72
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 
HCD
Senior-Moderator
Teammitglied
- 38.996
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.
S
Steb
Gast
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.
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.
M
My1
Dauer-User
- 208
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???
Nightly
Inventar
- 4.789
hulkhardy1 schrieb:
... bitte nicht pauschalieren 
Nur mit Knox Firmware nebst neuem Bootloader bekommt man diese nervigen Nag Screens zu sehen
ollborg
Dauer-User
- 506
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
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:
Nightly
Inventar
- 4.789
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? 
S
Steb
Gast
@ollborg
Woher hast du diese ganzen Infos? Habe bisher nicht so viel über RPMB und eMMC rausfinden können
Woher hast du diese ganzen Infos? Habe bisher nicht so viel über RPMB und eMMC rausfinden können
Nightly
Inventar
- 4.789
XDA Threads lesen ;-)
Google und Fachlektüre nutzen B-)
... lesen und lernen, vermutlich
Google und Fachlektüre nutzen B-)
... lesen und lernen, vermutlich
B4ckup
Erfahrenes Mitglied
- 78
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.
over and out.
sventehf
Stamm-User
- 371
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!
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!
Tanis64
Ehrenmitglied
- 1.882
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.
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.
A
ADizzle
Neues Mitglied
- 19
Wurde eben hiermit begrüßt
M
My1
Dauer-User
- 208
wozu n Fullwipe warum net Knox löschen und deaktivieren solange bis kein Root mehr da ist.
ein Full wipe ist kein unrot...
ein Full wipe ist kein unrot...
Tanis64
Ehrenmitglied
- 1.882
HaPe1968
Enthusiast
- 1.222
Hat jemand Informationen, was Bestandteil dieser Sicherheitsrichtlinien ist?
ollborg
Dauer-User
- 506
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.
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.....
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.
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:
Ähnliche Themen
- Bananenboost
Blacky12
