hi ich beisse gerade, rboot nur eine funktion zu lernen, die in der libmain steckt, die libmain kann ich nicht komplett gegen linken da diese sonst den bootloader zerstört und bereits user_start enthält. ok die funktion könnte man patchen und anders benennen, aber dann kommen die nächsten doppelt definierten typen und so weiter. daher hab ich die funktion die ich einbauen will in rboot mir über asm rausgesucht und in meinem c code mal provis. eingebaut, den return muss ich nochmal überdenken ob das so funktioiert, wenn es jemand weiss, was anders zu machen ist, freue ich mich auf den típ. jedenfall findet LUNA ide die dword reference nicht würde bedeuten, dass ich wieder die libmain dagegen linken muss? wie sage ich dem compiler dass er alles andere aussen vor lassen soll? oder macht man das ganz anders? drehe im moment am rad ;-) anbei screen prints. konnte es abe rjetzt nicht als png speichern sorry - ja ja - wer es bemerkt hat, rijndalelEnrypt läuft da immer mit im esp, aber das ist erst mal zweitranging, die funktion ist schon gesichtet. tips? bin später wieder da, versuche noch ein paar andere sachen, aber ich denke so komme ich nicht weiter in rboot, schade eigentlich, denn wieder die api gegenlinken? das würde das projekt aufblähen und den bootloader sinn kaputt machen. lg ;-)
Angehängte Dateien:
-
idapro.JPG
63 KB -
asm_test.jpg
89 KB
Dem Speichermapping nach (https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map) liegen deine Adressen alle im SPI Flash. Da ist nicht sicher ob die Funktionen jeweils an der gleichen Stelle landen.(hängt vom makefile ab lol).Eine Chip ID hätt ich aber eher im internen ROM vermutet.Ansonsten kann man feste Adressen per Linkerscript einschleusen. Schau mal in die Datei eagle.rom.addr.v6.ld da wird das gemacht. m.f.G. Dieter
Dieter Graef schrieb: > Dem Speichermapping nach > (https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map) liegen deine > Adressen alle im SPI Flash. Da ist nicht sicher ob die Funktionen > jeweils an der gleichen Stelle landen.(hängt vom makefile ab lol).Eine > Chip ID hätt ich aber eher im internen ROM vermutet.Ansonsten kann man > feste Adressen per Linkerscript einschleusen. Schau mal in die Datei > eagle.rom.addr.v6.ld da wird das gemacht. > > m.f.G. > Dieter man Dieter - wenn ich dich nicht hätte - wie duselig ist denn das von mir, klaro sind das spi speicheradressen ... man ... schreib gleich wieder..die lösung.. der mit dem makefile ist gut ;-) ich habs rausgeworfen und hab selber eins angefangen ;) hey danke für den touch am 'hintern' . da stand ich wohl auf der leitung..
wer damit was anfangen kann, wer nicht, einfach nicht beachten: hier weil ihr alle mitgelesen habt und gedanklich dabei ward. hab mich da in den adressen versteift, brauchts ja gar nicht. ist ja im rom
1 | uint32 id = ((*(volatile uint32*)(0x3ff00050) & 0xff000000) >> 24) | |
2 | ((*(volatile uint32*)(0x3ff00054) & 0x00ffffff) << 8); |
3 | |
4 | ets_printf("Chip Id: %lu", id ); |
fliest jetzt in rboot mit ein. thanks! lg ;-)
muss sein : euphorie an danke fürs teachen im µC.net und www @Karl Heinz ( c ) @Richard ( asm ) euphoroie aus
Heiner schrieb: > Wozu braucht man im Bootloader eine Chip-ID? -> bootloader kommuniziert mit der cloud chip id wird übertragen, abgleich dbs berechtigung update -> bootloader kommuniziert mit der signed firmware firmware wird geprüft, ob original, ob berechtigt ..
-> bootloader kommuniziert mit der netz structure (DHCP..) bootloader überbringt packet anfrage mit chip id und bekommt eine ip zugewiesen wenn berechtigt. die mac adresse ist änderbar im ESP8266, nicht aber die chip id. die ist fest im ROM bereich. die chip id ist die uid des ESP8266. wenn die chip id über die api abgefragt wird, muss gegen das gesamte sdk ( libmain ) gelinkt werden. code dann > 150 kb dieser thread zeigts wie er nur nur 2k klein bleiben kann, mit eigener aes256 und ein paar anderen routinen liegt er bei 7780 bytes. es können mehrere 'abschnitte' aufgerufen werden, (weitere bootloader ) und mehrere user bins bis max 1 mb das original SDK kennt nur einen bootloader und zwei user bins. der bootöoader ist opensource der von espressif closed lg ;-)
Hmm, aber ist es nicht sicherheitstechnischer Unfug, eine ID, die jeder auslesen kann, als Schlüssel zu verwenden?
Heiner schrieb: > Hmm, aber ist es nicht sicherheitstechnischer Unfug, eine ID, die jeder > auslesen kann, als Schlüssel zu verwenden? Gegenfrage ( nicht böse gemeint! ) : Ist es nicht ein Unfug, in jeder eMail seinen öffentlichen PGP Key mitzugeben? Denk einen Schritt weiter. Die Chip ID identifiziert lediglich den CHIP eindeutig. Du kannst die ID nicht auf einen anderen CHIP übertragen. Nur Softwaremässig 'klonen' lg ;-)
Nein. Bei PGP hast du einen öffentlichen Schlüssel zum Verschlüsseln und einen privaten (geheimen) zum Entschlüsseln. Das Verfahren ist so konstruiert, dass es nur so funktioniert. Bei AES hast du für beides den gleichen Schlüssel. Aber auch den musst du natürlich geheim halten. Beim ESP8266 hast du allerdings keinen "geheimen" Speicherbereich, in dem du den Schlüssel zum Entschlüsseln hinterlegen kannst. Genau das ist aber nötig. Schau dir mal die Videos von Atmel zu seinen Cryptochips an. Die haben sowas und genau deswegen funktioniert es. Aber beim ESP... alles, was einen solchen Schlüssel bilden könnte, ist entweder im Flash (als sein geflashter Inhalt oder auch IDs) oder im ESP8266EX selbst (irgendwelche IDs, Mac-Adressen). An das kommt man aber von außen immer dran. Wenn der Bootloader drankommt, kommt jeder dran. Was der Bootloader macht, kann ein Angreifer nachbilden (mit den passenden IDs und Mac-Adressen).
Heiner schrieb: > Nein. Bei PGP hast du einen öffentlichen Schlüssel zum Verschlüsseln und > einen privaten (geheimen) zum Entschlüsseln. Das Verfahren ist so > konstruiert, dass es nur so funktioniert. ok. angenommen die chip id wird blank verwendet: also ohne zusätzlichen verknüpften aufgeblähten volume key tables ect.. damit er masse bekommt : aus 8 char machen wir 2048 usw. also mal nur 8 chars mit dem öffentlichen schlüssel ( chip id ) kann man nun im werk mit einem nichtöffentlichen schlüssel gesendete daten entschlüsseln, wenn es das schlüsselpaar ergibt, stimmst du mir zu? die daten kann nur der entschlüsseln, der den nichtöffentlichen schlüssel besitzt. stimmst du mir auch da zu? dieser nicht öffentliche schlüssel, die companion id - bekommt der, der eine serienproduktion machen will. man kann auch eine produkt id nehmen als untergeordnete id.. in der firmware arbeitet dieses verfahren genau entgegengesetzt PGP in dem fall. und lässt sich über signing auch anderwaitig andersrum einsetzten. klingt erstmal irrsinnig - ist aber so. :) > Bei AES hast du für beides den gleichen Schlüssel. Aber auch den musst > du natürlich geheim halten. der aes key wird nicht mit klartext vorgehalten sondern eben in dem verfahren ( s.v. ) passphere versehen und fliesst da mit rein. damit das keying auch sicher wird. https://www.youtube.com/watch?v=2RqG_T-iinE > > Beim ESP8266 hast du allerdings keinen "geheimen" Speicherbereich, in > dem du den Schlüssel zum Entschlüsseln hinterlegen kannst. mhm. sicher? dann sag mir du mehr über die tables und das pharsing darüber: http://bbs.espressif.com/viewtopic.php?f=49&t=965 > Genau das ist aber nötig. nicht zwingend, wenn du protected register verwendest wie bei der SDHC und das flash nur als mitläufer verwendest. > Schau dir mal die Videos von Atmel zu seinen Cryptochips an. Die haben > sowas und genau deswegen funktioniert es. schauh dir mal meine beiträge an: http://bbs.espressif.com/viewtopic.php?f=7&t=936#p3152 ich beziehe mich auch u.a. auf SHA204, damit die leute das signing besser verstehen. hier fertige ausschnitte: https://www.youtube.com/watch?v=eVfmBTm5Isg > Aber beim ESP... alles, was einen solchen Schlüssel bilden könnte, ist > entweder im Flash (als sein geflashter Inhalt oder auch IDs) oder im > ESP8266EX selbst (irgendwelche IDs, Mac-Adressen). An das kommt man aber > von außen immer dran. das soll ja auch so sein ;-) das ist ja der clou ... ich schrieb irgendwo " weiss nicht ob das jetzt ein bug oder future ist" .. > Wenn der Bootloader drankommt, kommt jeder dran. > Was der Bootloader macht, kann ein Angreifer nachbilden (mit den > passenden IDs und Mac-Adressen). aber nicht an den nichtöffentlichen schlüssel mehr infos gibt es derzeit leider nicht, Heiner. das "verfahren" steht derzeit auf dem prüfstand - wie sicher es wirklich ist oder ob alles unfug ist. http://bbs.espressif.com/viewtopic.php?f=7&t=911#p3089 mit leisem aber respektvollen ton vor dir: wenn man stehen bleibt, dreht sich die welt allen trotz weiter Heiner wer aufgehört hat, zu forschen, hat aufgehört zu leben ;-) lg ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.