Signatur doch überlisten?

[Spacefish]

folgende Übersicht über das NAND zeigt das der z.B. mbmloader und mbm (motorola boot manager) ihre signaturen von einer festen Adresse offset im NAND nehmen. Die baseband software nimmt z.B. ihre sig von 0x643ff800 - 0x643fffff, Die ganzen SignatureAdressen liegen ja irgendwie weit verstreut rum wenn man sich die adressbereiche des NAND so anschaut (0x00000000-0x20000000). Vermtl. weisen die Adressen entweder auf zusätzliche Speicherbausteine oder auf Zellen im NAND die von der MMU gemappt werden.. evtl. sind es aber auch efuses / speicher die direkt im Silizium des Prozessors verarbeitet sind (was doof wäre). Was mir jetzt noch auffält, ist, dass für alle Signaturen die die Baseband SW betreffen die Adressen 0x6* sind und bei den anderen 0x8* b.z.w. 0xffff...
Würde es gelingen die MMU zu hacken oder irgendwie auf den Adressbus des Systems einfluss zu nehmen, könnte man einen gefakten key injecten und eigenst signierten Code laden..

Weiß einer von Euch ob es in linux eine möglichkeit gibt per syscall speicheradressen auszulesen?

CG_num: 63
CG_name: mbmloader
signature_type: 0
start_addr: 0x00000000
end_addr: 0x00020000
signature_start_addr: 0x8701ff80
signature_end_addr:  0x8702077f

CG_num: 30
CG_name: mbm
signature_type: 0
start_addr: 0x00020000
end_addr: 0x000c0000
signature_start_addr: 0x8f34f800
signature_end_addr:  0x8f34ffff

CG_num: 55
CG_name: mbmbackup
signature_type: 0
start_addr: 0x000c0000
end_addr: 0x00160000
signature_start_addr: 0xffffffff
signature_end_addr:  0xffffffff

CG_num: 56
CG_name: bploader
signature_type: 0
start_addr: 0x00160000
end_addr: 0x001c0000
signature_start_addr: 0xffffffff
signature_end_addr:  0xffffffff

CG_num: 31
CG_name: cdt.bin
signature_type: 1
start_addr: 0x001c0000
end_addr: 0x00220000
signature_start_addr: 0x8f073800
signature_end_addr:  0x8f073fff

CG_num: 38
CG_name: pds
signature_type: 0
start_addr: 0x00220000
end_addr: 0x003a0000
signature_start_addr: 0xffffffff
signature_end_addr:  0xffffffff

CG_num: 34
CG_name: lbl
signature_type: 1
start_addr: 0x003a0000
end_addr: 0x00400000
signature_start_addr: 0x80d03800
signature_end_addr:  0x80d03fff

CG_num: 57
CG_name: lbl_backup
signature_type: 1
start_addr: 0x00400000
end_addr: 0x00460000
signature_start_addr: 0x80d03800
signature_end_addr:  0x80d03fff

CG_num: 43
CG_name: cid
signature_type: 0
start_addr: 0x00460000
end_addr: 0x004c0000
signature_start_addr: 0xffffffff
signature_end_addr:  0xffffffff

CG_num: 41
CG_name: sp
signature_type: 0
start_addr: 0x004c0000
end_addr: 0x00640000
signature_start_addr: 0x8f1af800
signature_end_addr:  0x8f1affff

CG_num: 61
CG_name: devtree
signature_type: 1
start_addr: 0x00640000
end_addr: 0x006a0000
signature_start_addr: 0x8f0af800
signature_end_addr:  0x8f0affff

CG_num: 42
CG_name: logo.bin
signature_type: 0
start_addr: 0x006a0000
end_addr: 0x00740000
signature_start_addr: 0x8eeaf800
signature_end_addr:  0x8eeaffff

CG_num: 44
CG_name: misc
signature_type: 0
start_addr: 0x00740000
end_addr: 0x007a0000
signature_start_addr: 0xffffffff
signature_end_addr:  0xffffffff

CG_num: 35
CG_name: boot
signature_type: 1
start_addr: 0x007a0000
end_addr: 0x00b20000
signature_start_addr: 0x813bf800
signature_end_addr:  0x813bffff

CG_num: 45
CG_name: bpsw
signature_type: 2
start_addr: 0x00b20000
end_addr: 0x00ee0000
signature_start_addr: 0x643ff800
signature_end_addr:  0x643fffff

CG_num: 47
CG_name: recovery
signature_type: 1
start_addr: 0x00ee0000
end_addr: 0x01360000
signature_start_addr: 0x814bf800
signature_end_addr:  0x814bffff

CG_num: 33
CG_name: cdrom
signature_type: 5
start_addr: 0x01360000
end_addr: 0x01c80000
signature_start_addr: 0x827df800
signature_end_addr:  0x827dffff

CG_num: 39
CG_name: system
signature_type: 5
start_addr: 0x01c80000
end_addr: 0x0cc80000
signature_start_addr: 0x8ca1f800
signature_end_addr:  0x8ca1ffff

CG_num: 40
CG_name: cache
signature_type: 0
start_addr: 0x0cc80000
end_addr: 0x13680000
signature_start_addr: 0xffffffff
signature_end_addr:  0xffffffff

CG_num: 37
CG_name: userdata
signature_type: 0
start_addr: 0x13680000
end_addr: 0x1fba0000
signature_start_addr: 0xffffffff
signature_end_addr:  0xffffffff

CG_num: 36
CG_name: cust
signature_type: 5
start_addr: 0x1fba0000
end_addr: 0x1fd80000
signature_start_addr: 0x8211f800
signature_end_addr:  0x8211ffff

CG_num: 53
CG_name: kpanic
signature_type: 0
start_addr: 0x1fd80000
end_addr: 0x1ff80000
signature_start_addr: 0xffffffff
signature_end_addr:  0xffffffff

CG_num: 54
CG_name: rsv
signature_type: 0
start_addr: 0x1ff80000
end_addr: 0x20000000
signature_start_addr: 0x00000000
signature_end_addr:  0x00000000

 

[prodigy7]

Vielleicht verstehe ich dich falsch ... aber /dev/mtd... sollte das von dir gesuchte sein oder? Oder meinst du /dev/mem ?

 

[Spacefish]

hm /dev/mtd bietet nur Zugriff auf bestimmte Teile des NAND und nicht auf das komplette (man müsste andere Parameter im Bootloader für den Kernel setzen) /dev/mem bietet auch nur Zugriff auf den Bereich, der dem linux das läuft zugeordnet ist falls ich mich nicht irre. Adressen wie 0x8701ff80 lassen sich darüber vermtl. nicht ansprechen, aber ich versuchs mal.

 

[Spacefish]

/dev/mem schickt nur ne kernelmessage mit "bad adress" wenn man probiert drauf zuzugreifen. /dev/kmem löst kernelpanic aus oder so und der Stein startet neu.

 

[the_tool]

Dass du da eine Kernel-Panic bekommst wundert mich nicht -- schliesslich sind das Adressen die im R0 laufen, die Du nicht so einfach im R3 auslesen kannst. Was einen Versuch wert wäre ist, dass Du versucht ein kleines Kernel-Modul zu schreiben dass im Kernel-Mode läuft und so die Adressen dann direkt im Speicher verändert.

 

[Spacefish]

denkst du nicht das Ring0 in dem Fall auch nur gemappt wird? also nur auf einen bestimmten speicherbereich? Kernelmodule laden ob das geht`!

 

[KurrKurr]

Off-Topic (sorry, muss sein ;D ):
Kurze Zwischenfrage: die Rede ist immer vom "NAND"... ist das nicht einfach ein Flash-Speicher, der mit NAND Gattern realisiert worden ist?
Für mich hört sich das immer so an, als ob man vom BIOS sprechen würde. Ist der NAND-Speicher das Pendant zum BIOS beim ausgewachsenen PC?

Chris

 

[sharky]

der nand flash ist einfach nur der angeschlossene speicher, wo bootloader, os usw usw drauf sind.

spacefish laden von kernelmodulen geht problemlos.
im recovery hast du übrigens über /dev/mtd weitaus mehr zugriff als im "normalzustand".
Eventuell könnte für dich auch ein blick auf start [And Developers] interessant sein

 

[Spacefish]

@sharky danke für den Link!

 

[Spacefish]

Off-Topic (sorry, muss sein ;D ):
Kurze Zwischenfrage: die Rede ist immer vom "NAND"... ist das nicht einfach ein Flash-Speicher, der mit NAND Gattern realisiert worden ist?
Für mich hört sich das immer so an, als ob man vom BIOS sprechen würde. Ist der NAND-Speicher das Pendant zum BIOS beim ausgewachsenen PC?

Chris

Naja da hast du prinzipiell recht ein NAND Speicher ist einfach ein Speicher in dem daten in NAND Gattern gespeichert werden, im milestone ist der 512MB groß und es ist eben fast alles auf ihm gespeichert was an software im Stein läuft, auch die Software des Baseband Prozessors u.s.w.

 

[Luke]

Wir könnten Linus einen Stein spendieren, er würde es bestimmt schaffen das Ding zu knacken ;-)
Er sollte doch da durchblicken können.
Sorry fürs OT...

 

[kniffo80]

Wir könnten Linus einen Stein spendieren, er würde es bestimmt schaffen das Ding zu knacken ;-)
Er sollte doch da durchblicken können.
Sorry fürs OT...

Der Herr Torvalds wird da auch nix machen können ... hehehe. Okay, back to topic please. Und macht macht hinne mit der Signatur-Überlistung

 

[mattmaso]

Was ist denn jetzt mit dem Custom Recovery?
Gibts da irgendwelche fortschritte?
Will mit dem rom cocking anfangen. *finger jucken*

 

[Koala]

Ich poste das der Übersicht halber auch nochmal hier...

Ich weiß nicht ob das hier auch funktionieren würde, aber aus anderen Bereichen kenn ich das so:
Das Programm tut nicht alles was man will, also wird es um Funktionen ergänzt.
So kann man bei Windows .exe-Dateien zum Beispiel .dll-Files attachen, die dann bestimmte Anfragen abfangen (Hook), dort ihre Magie einsetzen, und das gewünschte Ergebnis zurückgeben.
Sofern Source-Code vorhanden ist wird das sogar deutlich einfacher.

Also mein Ansatz.
Könnte man den Bootloader nicht um eine Funktion erweitern die erkennt, wenn die Signatur gefordert wird und dann den richtigen (fest vorgegebenen) Wert zurückgibt.
Zur Not müsste man alle Programme der Boot-Chain so abändern/ergänzen.
Ich bin da jetzt nicht so in der Materie drin um das definitiv sagen zu können.
Keine Ahnung ob das so beim Milestone und Android möglich ist, aber ich dachte ich schlag's mal vor...

 

[DooMMasteR]

nein, das ganze beginnt schon davor, der OMAP checkt in Hardware die Signatur des Bootloaders, ist sie nicht korrect, so akzeptiert er das bootimage nicht
daraufhin ist die Bootchain bis zum kernel durchsigniert
einziger angriffspunkt ist der loader selbst (bisher)
jedoch:
* ist uns weder private noch public key bekannt
* wissen wir nicht ob ggf das DROID die gleiche signatur fuer den loader verwendet
* würde ein fasch signierter loader das Milestone bricken

problem ist, dass man an das OMAP nicht so einfach drann kommt, das teil icht verdammt sicher gebaut und laesst sich nichtmal nach dem sleepstate code in den gesicherten speicherbereich unterjubeln (auch der wird vor dem sleepen on time signiert, wie ist jedoch unbekannt)

unterschied zum DROID: da hoert die gesicherte bootchain schon beim loader auf, er ist zwar signiert und das OMAP laeuft im HS mode, aber der loader selbst checkt die signaturen der files die er laed nur dann, wenn es deren header erfordert, es laesst sich also auch ein custom rom ausfuehren
alles in allem ist das OMAP SoC verdammt sicher, weshalb es auch fuer fast jedes MIL-Cert Zertifiziert wurde, was moeglich ist ok nicht unseres, sondern andere versionen, aber die technik dürfte identisch sein


also großses Problem ist immo, dass man keine unsignierten Code drauf ausgefuehrt bekommt (abgesehen von userland code)
ursache dafuer: die bootchan ist vom loader an sicher, denn das OMAP befindest sich im high-security mode

 

[akay]

gibts nich viele möglichkeiten, oder wie?

1. zufällig exploit finden

2. zufällig signatur rausfinden (und dabei ne imposante menge an stones bricken)

3. die hardware irgendwie so bearbeiten, dass sie signaturen nich mehr prüft

erstes is wohl ziehmlich unwahrscheinlich
zweiter punkt im grunde auch, ausser es gibt ne möglichkeit das bricken rückgängig zu machen oder zu umgehen und den ganzen vorgang zu automatisieren
der letzte punkt könnte am SoC scheitern, wenn man hardwaremässig garnicht mit nem lötkolben ran kommt.

sieht düster aus

 

[KurrKurr]

Ich denke wir sind hier an einem Dead-End... ich überleg schon, ob ich nicht mein MS verkaufe und mir ein ähnliches Gerät besorge...

Chris

 

[kniffo80]

man...ich kann es erst in einem halben jahr verkaufen...und eigentlich finde ich das gerät klasse...
erstmal abwarten kurr...

 

[janus_01]

Bitte geht alle auf die links im umfrage thread im Milestoneforum und unterschreibt im motoforum sowie die umfrage auf diesem forum! link kann ich leider nicht geben bin mit dem stone unterwegs

 

[KurrKurr]

Ich finds auch toll... nur is es zu langsam. Viele Force-Closes. Ich kann damit nicht machen, was ich will...

Ich weiß nicht... C.