andi1203
Ambitioniertes Mitglied
- 6
ich kann das nicht mal wählen, das es 30 tage ruhe geben soll... immer wenn ich drauf tippe verschwindet es nur... mehr passiert da nicht... 
Technische Diskussion zu KNOX - Sammelthread
- 1.225 Antworten
- Letztes Antwortdatum
M
My1
Dauer-User
- 208
manchmal regt der sich in groß auf und da kannste dem aber HDF sagen...
Nightly
Inventar
- 4.908
HDF? :what:
andi1203
Ambitioniertes Mitglied
- 6
also seit der aktuellen firmware habe ich nur diese meldung. bei der firmware davor hatte ich immer die mit den 30 tagen weg klicken. allerdings auch öfters als es jetzt der fall ist. jetzt habe ich es immer nur, wie gesagt, wenn ich wlan an mache.
M
My1
Dauer-User
- 208
@nightly HDF ist eine deutsche abkürzung für ein Synonym für sei still...
Nightly
Inventar
- 4.908
... Ich kenne noch eine andere Definition, bei der mir das Blut in die Augen quillt, deswegen die Nachfrage / OT off
andi1203
Ambitioniertes Mitglied
- 6
Hat denn hier keiner dieses Problem? Oder weiß irgendwer, wie ich die Meldung weg bekomme?
M
My1
Dauer-User
- 208
hast du root? wenn ja nimm wanam xposed und das xposed framework und dann kannste für ruhe sorgen...
andi1203
Ambitioniertes Mitglied
- 6
Nein, ich habe kein root. Das ist das erste Handy von Samsung, bei dem ich kein root / custom rom brauche. Bin sonst von der Leistung ect. sehr zufrieden. Was ich vom s1/s2/s3 nicht behaupten konnte.
M
My1
Dauer-User
- 208
dann schreib mal den Support an und frag die was es sein könnte, weil es ist ja echt nervig und ich hatte es ja anfangs auch...
Wolf Hamburg
Erfahrenes Mitglied
- 59
Ich bekomme diese Meldung auch, sobald ich mich mit meinem WLan verbinde. Und ich habe definitiv nur Apps aus dem PlayStore. Leider habe ich auch keinen blassen Schimmer, welche App das sein könnte, die sich da unautorisierten Zugriff verschaffen will.
Ich habe zwar die Möglichkeit diese Meldung für 30 Tage zu unterdrücken, lieber wäre mir allerdings wenn mir betroffene App angezeigt würde, um gezielt solche Apps auszufiltern...
EDIT: Ich hab eine ungerootete MJ5 StockRom am Start (KNOX 0x0)
Ich habe zwar die Möglichkeit diese Meldung für 30 Tage zu unterdrücken, lieber wäre mir allerdings wenn mir betroffene App angezeigt würde, um gezielt solche Apps auszufiltern...
EDIT: Ich hab eine ungerootete MJ5 StockRom am Start (KNOX 0x0)
M
My1
Dauer-User
- 208
MJ5? ist aber keine DBT, und ich glaub jemand sollte mal den Samsung Support anschreiben weil da jaemandem sogar nach nem Werkreset kam, kann man deen ja sagen weg mit der Bloatware...
mahd
Dauer-User
- 868
Mj5 ist die Initial JB4.3 für Dbt.
Wolf Hamburg
Erfahrenes Mitglied
- 59
Seit wann ist denn die MJ5 keine DBT 
EDIT: mahd war schneller
EDIT: mahd war schneller
Nightly
Inventar
- 4.908
MÄDELS ^^Back on Topic PLEASE! B-)
mecss
Ehrenmitglied
- 11.925
ollborg
Dauer-User
- 506
Neueste technische Informationen von Chaifire und .NetRoller 3D.
Das Knox Flag wird im eMMC abgelegt und kann durch physikalischen Tausch des eMMC zurückgesetzt werden. Der Einsatz von eFuse wird immer unwahrscheinlicher, da manche S4 eMMCs 4.5, ohne eFuse Support, von Toshiba verbaut haben. ( eFuse wird erst ab Version 5.0 unterstützt) Es ist inzwischen bekannt das Samsung das Knox Flag per Software zurücksetzen kann.
Aber lest bitte selbst nochmal genau die englischen Texte, ist noch mehr interessante Info drin.
Chainfire schreibt:
There are multiple things at play here. There is definitely mention of eFuses in the bootloader, close to the KNOX related code. That is why I first suspected eFuses may be involved. It could well be KNOX bootloaders use eFuses if available and uses a software counter if not (like the original flash counters). It may of course also be the case that it's indeed just a few bits somewhere that get flipped (possibly inside an encrypted section).
The big difficulty here is that the KNOX counter is only settable once. So it is very difficult to pin down where this value is stored, if even in a user-accessable place, which doesn't need to be the case at all. Remember that on Exynos4 devices it was an engineering mistake that even made us find the counter the first time (and then the cat was out of the bag). Anyway, you'd need an exact flash dump of before and after, then maybe it would be easier to pin down.
The next problem however becomes write protections. One reason I stopped working with Triangle Away on the Note 3, is that certain areas of the flash memory are write protected. These protections are set inside the bootloader (== protected code) and cannot be unset, they cover the sections containing the flash counter data. Even if we knew where the data was stored and how (assuming it's not an eFuse), we'd still have to beat those write protections. These protections were also used in the Exynos S4, which is why there is no Triangle Away for that specific device. I'm not completely sure if all the devices that are getting KNOX support this hardware feature, but I believe so - it's fairly common.
Mind you, I know a theoretical exploit that may beat the write protection, but I have not worked it out in practise (not even attempted), as it'll be lengthy, device model specific, difficult, and probably dangerous. As long as those write protections are there, we can't reset the status, but as long as we don't know where or how the KNOX data is stored, it is of no use trying to crack the write protections. That is, even assuming that data we want is even accessable from kernel and/or userland, which doesn't have to be the case at all.
RIFF boxes and ORT connectors have raw access to the flash, by the way, that's why it would be trivial to do with that equipment if you know where the data is at. Of course, you can also use a RIFF box to downgrade bootloaders due to said access. When we were hacking the original Samsung Galaxy Tab's locked bootloaders that's exactly how we tested things
Weitere Infos von .NetRoller 3D
What we know so far:
-The Knox flag is physically stored in the eMMC, not in the SoC. Replacing the eMMC resets the flag.
-Some phones with Knox have Toshiba eMMCs supporting only eMMC v4.5, meaning, a standard eMMC 4.5 feature is being used (not a Samsung extension or something new to eMMC 5.0). This alone excludes an efuse - eMMC 4.5 doesn't have efuse support.
-Samsung can reset the flag using software only. This also rules out an efuse.
-Restoring a full eMMC backup (including boot and user partitions) doesn't clear the flag, even if done via JTAG or direct eMMC programming. So, the flag is not in the user or boot areas of the eMMC.
That leaves only the RPMB or the eMMC partition table.
Anmerkung von mir RPMB= Replay Protected Memory Block
http://forum.xda-developers.com/showthread.php?t=2504258
Das Knox Flag wird im eMMC abgelegt und kann durch physikalischen Tausch des eMMC zurückgesetzt werden. Der Einsatz von eFuse wird immer unwahrscheinlicher, da manche S4 eMMCs 4.5, ohne eFuse Support, von Toshiba verbaut haben. ( eFuse wird erst ab Version 5.0 unterstützt) Es ist inzwischen bekannt das Samsung das Knox Flag per Software zurücksetzen kann.
Aber lest bitte selbst nochmal genau die englischen Texte, ist noch mehr interessante Info drin.
Chainfire schreibt:
There are multiple things at play here. There is definitely mention of eFuses in the bootloader, close to the KNOX related code. That is why I first suspected eFuses may be involved. It could well be KNOX bootloaders use eFuses if available and uses a software counter if not (like the original flash counters). It may of course also be the case that it's indeed just a few bits somewhere that get flipped (possibly inside an encrypted section).
The big difficulty here is that the KNOX counter is only settable once. So it is very difficult to pin down where this value is stored, if even in a user-accessable place, which doesn't need to be the case at all. Remember that on Exynos4 devices it was an engineering mistake that even made us find the counter the first time (and then the cat was out of the bag). Anyway, you'd need an exact flash dump of before and after, then maybe it would be easier to pin down.
The next problem however becomes write protections. One reason I stopped working with Triangle Away on the Note 3, is that certain areas of the flash memory are write protected. These protections are set inside the bootloader (== protected code) and cannot be unset, they cover the sections containing the flash counter data. Even if we knew where the data was stored and how (assuming it's not an eFuse), we'd still have to beat those write protections. These protections were also used in the Exynos S4, which is why there is no Triangle Away for that specific device. I'm not completely sure if all the devices that are getting KNOX support this hardware feature, but I believe so - it's fairly common.
Mind you, I know a theoretical exploit that may beat the write protection, but I have not worked it out in practise (not even attempted), as it'll be lengthy, device model specific, difficult, and probably dangerous. As long as those write protections are there, we can't reset the status, but as long as we don't know where or how the KNOX data is stored, it is of no use trying to crack the write protections. That is, even assuming that data we want is even accessable from kernel and/or userland, which doesn't have to be the case at all.
RIFF boxes and ORT connectors have raw access to the flash, by the way, that's why it would be trivial to do with that equipment if you know where the data is at. Of course, you can also use a RIFF box to downgrade bootloaders due to said access. When we were hacking the original Samsung Galaxy Tab's locked bootloaders that's exactly how we tested things
Weitere Infos von .NetRoller 3D
What we know so far:
-The Knox flag is physically stored in the eMMC, not in the SoC. Replacing the eMMC resets the flag.
-Some phones with Knox have Toshiba eMMCs supporting only eMMC v4.5, meaning, a standard eMMC 4.5 feature is being used (not a Samsung extension or something new to eMMC 5.0). This alone excludes an efuse - eMMC 4.5 doesn't have efuse support.
-Samsung can reset the flag using software only. This also rules out an efuse.
-Restoring a full eMMC backup (including boot and user partitions) doesn't clear the flag, even if done via JTAG or direct eMMC programming. So, the flag is not in the user or boot areas of the eMMC.
That leaves only the RPMB or the eMMC partition table.
Anmerkung von mir RPMB= Replay Protected Memory Block
http://forum.xda-developers.com/showthread.php?t=2504258
Zuletzt bearbeitet:
M
MeisterPanse
Stamm-User
- 379
Kouya1600
Stamm-User
- 138
@Panse
Du bist mir zuvorgekommen
Wollte das auch posten.
BTT.
Das lässt ja noch die Hoffnung aufkommen das in naher Zukunft die hacker von XDA da was feines auf die Beine stellen werden.
Ich zumindest freue mich schon drauf
Du bist mir zuvorgekommen
Wollte das auch posten.
BTT.
Das lässt ja noch die Hoffnung aufkommen das in naher Zukunft die hacker von XDA da was feines auf die Beine stellen werden.
Ich zumindest freue mich schon drauf
ollborg
Dauer-User
- 506
Bitte korrigiert mich aber ich glaube das geht nur mit einem JTag oder der Riff Box. Diese Hardware kann das auslesen.
Natürlich kann man auch sein Phone aufschrauben und nachschauen, sollte anhand der Typenmarkierung auf den eMMC Chips in Suchmaschinen gefunden werden können.
Hier ein Beispiel für Samsung eMMC 5.0 Chips
Natürlich kann man auch sein Phone aufschrauben und nachschauen, sollte anhand der Typenmarkierung auf den eMMC Chips in Suchmaschinen gefunden werden können.
Hier ein Beispiel für Samsung eMMC 5.0 Chips
Zuletzt bearbeitet:
Ähnliche Themen
- Bananenboost
Blacky12
