A 256bit használatát elvileg egyszerű lenne tesztelni úgy ha beleírunk a boot.img ezen részébe ha nem bootol akkor használja.Mindjárt ki is próbálom.

Én a VLRről annyit tudok, hogy mi a magic-je (0xE59FF052) meg hol van a mérete tárolva. Az a 256bit nekem kicsit kevésnek tűnik, szerintem 352 byte. Ebből 4 a magic, 4 a méret negyede.

[ Szerkesztve ]

A hackelés nem károkozás másnak, hanem valamit úgy használunk, ahogy arra készítésekor nem gondoltak.

Nos ha belenyúlok abba a 256bit-be a boot.img-ben akkor ahogy várható volt nem bootol.(usb logo)
Visszaolvastam a fórumban némi infóért és kíváncsiságból kipróbáltam az xImgTool-t. A splash.img-t szét tudja szedni, de összerakni már nem. A progi szerint a SIGN rész 480byte.
A boot.img-re is ráeresztettem, azt szétszedi és össze is rakja az eredmény megegyezik a szétszedés előtti változattal byte-ra pontosan.

Tehát a kérdés továbbra is az maradt, hogy mi pontosan ez a SIGN és megváltoztatható e splash.img bitmap része anélkül hogy újra kellene számolni.

Megpróbálom átírni a CMDLINE néven generált file-t a boot.img ben.
Ez van benne:
init=/init pci=noearly earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay watchdog.watchdog_thresh=60 androidboot.spid=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx androidboot.serialno=01234567890123456789012345678901 ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0n vmalloc=172M ehci_hcd.use_sph=1

Kíváncsi vagyok mi fog történni

[ Szerkesztve ]

Sajnos usb logó lett a kísérlet vége, viszont érdekes, hogy a progi által generált boot.img-ben 2 dolog változott meg.
Az egyik az átírt "watchdog.watchdog_thresh=50" ahogy az várható volt, a másik pedig a 256 bites rész amit korábban emlegettem.
Tehát a progi nem csak összefűzi és szétszedi a boot.img-t hanem számolja a 256 bites részt is valami alapján.

Igen a 352byte a tartalomhoz számolódik sajnos, a számoláshoz pedig soha nem lesz kulcsunk

Már csak azt kéne kipróbálni, mi van akkor ha pont az a rész nem változik meg...

Melyik ?
A 352byte maradt ugyanaz, a 256bit hash amit újraszámolt a progi amikor legeneráltam a módosított boot.img-t az változott csak.
Az eredeti boot.img-nél a 256bit hash be is belenyúltam és akkor se bootolt.

A 352byte meg az img tartalma alapján generálódik a titkos kulccsal.

Lehet hogy pont azt a 256 bitet nem kéne bántani, úgy értem!

@RoundRobin:

Fogalmunk nincs miért van... Már csak azért sem, mert a RazrI lemezképében nincsen, mégsem tudod módosítani zárt bootloader mellett, tehát abban van más. Akkor viszont ez itt minek? Ott is megoldották nélküle...

[ Szerkesztve ]

A működési elve ennek az egésznek szerintem a következő:
A rom-ra generál egy SHA256 hash-t, ezt eltitkosítja a privát kulccsal(352byte), és ezt a 2 dolgot és a rom-ot összerakja egy image-be.

Visszafele pedig:
Bootkor ellenőrzi a tablet bootloadere(UEFI?) az SHA hash-t a flash tartalmára, majd eltitkosítja a saját kulcsával a HASH-t (352byte az eredmény) és ha ez egyezik akkor mehet a boot.

Nyilván valahol a kulcsnak tárolva kell lennie a tableten illetve van valahol egy bootloader ami ezt végrehajtja.
Érdekes hogy a teclast kernel is bebootól.
Az UEFI secure boot működik hasonlóan ha jól tudom.

[ Szerkesztve ]

"Érdekes hogy a teclast kernel is bebootól."

Csak akkor, ha az a bootloader van mellé, vagy nem?

Már tudom miről beszélsz. Az csak egy SHA1 a tartalomról. Totál szükségtelen, és a legtöbb bootloader telibe leszarja. Annak, hogy nem megy az az oka, hogy az is benne van az aláírásban.

A teclast kernel bootol alap bootloaderel? Fordítva?

[ Szerkesztve ]

A hackelés nem károkozás másnak, hanem valamit úgy használunk, ahogy arra készítésekor nem gondoltak.

Nekem sikerült a teclast img-ket (factory, system, recovery, droidboot, boot, semmi egyebet) véletlenül beflashelnem és bebootolnom. Meg is lepett az orosz indulás és a fura boot logo

[ Szerkesztve ]

Sajnos ez ellenőrzi. Egy byte-ot átírva a boot.img-ben az SHA256/352byte változtatása nélkül ugyan úgy nem bootol.

Meg persze a moddolás ellen véd, integritáshoz nem kellene a 352byte

És ha legenerálsz egy SHA1 checksum-ot a tartalomról (képről)? Mindjárt látszódik, ez van-e előtte.

A splash.img-ből exportált bmp-n SHA256-ot számolva megkapom azt a bizonyos headert amit SHA256-nak véltem a splash.img-ben.(0x2AC offset)
Tehát a 256 bit eltérés az imgkben valóban egy SHA256 checksum.

Már csak az a kérdés, hogy a többiben mit számol ki. Pl. a boot.img-ben van minimum egy ramdisk.cpio és egy (b)zImage... no de hogy lesz ezekből egy sha kulcs?

A splash.img-n nem változtatok semmit mert félek hogy túl korán halna meg a boot folyamat és nem jutnék el a fastboot-ig. A boot.img-n variáltam és azt teszteltem bebootol-e az android vagy usb logo jelenik meg.

a boot.img nél próbáltam:
SHA256 rész 1byte átírás
352byte 1 byte átírás
rom rész 1 byte átírás
rom rész 1 byte átírás xImgTool-al újra összerakás (Ekkor az átírt 1 byte változott + SHA256 rész a generált boot.img-ben)
Mind a 4 esetben usb logo.

boot.img - xImgTools - boot.img esetén az eredeti boot.img-t kaptam.

Tehát nem marad más ami ismeretlen csak az a 352byte ami az adat részből számolódik.
Ez pedig ahogy leírtam valószínűleg az SHA256 titkos kulccsal titkosítva amit a tablet ellenőriz a saját titkos kulcsával ami valahol meg van a tableten. Persze a 352byte előállítása sem teljesen ismert így a kulcsot megtalálva is körülményes lenne tovább haladni.

Minden esetre ez is haladás.

Minden .img-nél így van generálva a file ahogy leírtam, legyen az boot logo, kernel, fastboot, factory flasher bootloader. A system.img nyilván nincs aláírva mert az már a kernel után van betöltve.

A többi file-ra még nem néztem rá, én csak az első boot logo-t akartam lecserélni.

Főleg, hogy ki is számoltam az SHA256-ot

androidboot.serialno=01234567890123456789012345678901
Ezzel arra célzol, hogy generálhatunk olyan boot.img-t amiben pl. más a kernel ha úgy variáljuk a tartalmat, hogy meglegyen az SHA256 helyes checksum ?
Ezzel bizonyítható lenne az is, hogy a 352byte az ami.

Ez szerintem simán megoldható valahogyan, biztos létezik rá program.

Ezt írtam át:
init=/init pci=noearly earlyprintk=nologger loglevel=0 kmemleak=off androidboot.bootmedia=sdcard androidboot.hardware=redhookbay watchdog.watchdog_thresh=60 androidboot.spid=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx androidboot.serialno=01234567890123456789012345678901 ip=50.0.0.2:50.0.0.1::255.255.255.0::usb0n vmalloc=172M ehci_hcd.use_sph=1

Erre:
watchdog.watchdog_thresh=50

Nem értek ehhez a részhez, de úgy gondoltam talán ez a legkevésbé fájdalom mentes.(Feltéve ha nincs erre is valami másik checksum)

Tiszteletem Urak!

Rengeteget olvastam a fórumot, szinte az összes hozzászólást elolvastam. Ennek ellenére sokszor egy árva mukkot nem értettem a bejegyzésekből. Na jó! ez enyhe túlzás, a kötőszavak azért megvoltak. Nyilván sokan jártak így rajtam kívül is. Viszont engem nem hagyott nyugodni a dolog egy kicsit kutakodtam. Ezt találtam: http://logout.hu/cikk/adattarolas_android_rendszeren/teljes.html
És még ezt is: http://logout.hu/cikk/android_terminal_parancsok/teljes.html
Nem mondom, hogy mindent értek most már, de legalább valami fogalmam van róla, hogy éppen miről folyik a szó. És éppen ezért köszönöm a befektetett munkát, aminek eredményeképpen most egy használhatóbb eszköz tulajdonosa vagyok.

Tedd vagy ne tedd! De ne próbáld! (Yoda mester)

"A splash.img-ből exportált bmp-n SHA256-ot számolva megkapom azt a bizonyos headert amit SHA256-nak véltem a splash.img-ben.(0x2AC offset)"

Ezt hogyan?

Az splash.bmp kulcsa:

a19d57ba96d3a4ceda2042dce3992110ffc2cdcc5f170a7ea9223a371b30aa5a

Ehhez képest a splash.img tartalma a megadott offszettől, karakteresen:

}#R\Uffffffffs\UffffffffC\Uffffffff_a>'\UffffffffD54Kxp\UffffffffX\Uffffffff0\u02921\Uffffffff\UffffffffE\Uffffffff\UffffffffB

Ebből látszik, hogy ez a mintázat csak az utolsó biten tér el és ismétlődik, tehát ez biztos nem egy SHA kulcs...

..vagy én értettem valamit félre?

A logo.bmp SHA256 általam számolva: 7d235214f825ec948f73c33943d57f5f613e278f4435344b077870ad58e07378
A számoló progi amit használok:
https://kanguru.zendesk.com/attachments/token/0xdkf3ohvnbjyd4/?name=sha256sum.exe

A splash.img-k összehasonlítva pedig (dott - modecom freetab 7800):

[link]

Nem tudom te mit és hol / hogyan nézel

[ Szerkesztve ]

Na most akkor?

Gondolom rossz a logo.bmp-d.
[link]

Honnan szeded ezeket? Te csinálod?

Már hogy lenne, mikor pontosan ugyan ott vágom el, ahol ti, ugyan azzal kiindulási fájllal....

Megnézted, hogy a linkelt bmp-m azonos e a tiéddel ?
Ha nem akkor nyilván az SHA-t számolja másképp a programod.

Nem azonos,mivel én nem vágtam le a végén azokat az "FF"-eket, amiket te igen. Ebből adódik az eltérés. Nálam a dd végig ment a maradék fájlon, csak az elejét vágta le. Láthatóan azonban ez a képfeldolgozót nem zavarja...

Tudna segíteni valaki? Próbáltam feltelepíteni a gltoolst, de csak fekete képernyőt csinál a tabnak. Hogyan kell ezt működésre bírni?

x86on nem működik.

<< "stabil, de mégse" >> << MX440 FTW! >>

Az LG smart keyboard szerintetek működésre bírható? Leszedtem xda-ról a recoveryből felrakható verziót, de mivel nem akartam vele szenvedni, kiszedtem az apk-kat és beraktam őket a rendszerappok közé, beállítottam az engedélyeket, a beállítások szépen működnek is, viszont használatnál jön folyamatosan az FC... a lib-eket hiányolhatja, amik a zip-ben voltak? (egyébként azoknak mi a "hasznuk"? sajnos, ehhez nem értek)

Siemens C35-> Siemens MT50-> Motorola E398-> SE K750i-> Nokia 6220 Classic-> ZTE Blade-> SE Xperia Mini Pro-> Samsung Galaxy S Advance -> Sony Xperia SP -> Huawei P8 Lite -> Xiaomi Redmi Note 4 -> Xiaomi Redmi Note 6 Pro ->Xiaomi Redmi Note 9 -> Xiaomi Redmi Note 11

Tudsz x86-os LG-t ami androidos? Én nem ez lesz a fő baja szerintem

– Yet, thou serves with thine eyes clouded in chaos. Thou, bound in the cage of madness. I am he who commands those chains – Fate/Zero Berserker Mad Enchantment

A recoveryből felrakható zipeket nem kib.szásból csinálták meg így.
Ha meg lib-ek vannak mellette, és nem teszed fel őket, nincs min csodálkozni. Amúgy szerintem nem az x86-on múlik a dolog, az viszont lehet, hogy vmi lg specifikus függősége van, ami nélkül nem működik.

Köszönöm, hogy anélkül hülyézel le, hogy utánanéztél volna, hogy maguk a készítők is írták, hogy nem feltétlenül kell recoveryből felrakni, mert lehetnek olyan eszközök, ahol pont a libek miatt nem biztos, hogy működni fog, ilyenkor kell az apk-helyezgetős móka... De tényleg köszi...

Amúgy a sony telómon hibátlan, szóval nagy eséllyel az x86 nem tetszik neki...

[ Szerkesztve ]

Siemens C35-> Siemens MT50-> Motorola E398-> SE K750i-> Nokia 6220 Classic-> ZTE Blade-> SE Xperia Mini Pro-> Samsung Galaxy S Advance -> Sony Xperia SP -> Huawei P8 Lite -> Xiaomi Redmi Note 4 -> Xiaomi Redmi Note 6 Pro ->Xiaomi Redmi Note 9 -> Xiaomi Redmi Note 11

Ha a /system/lib/arm mappába teszed a libeket, akkor menni fog.
Ide jönnek a houdini fájlai.
(A houdini egy intel által fejlesztett arm emulátor x86-ra.)
Ha itt nem megy akkor próbáld a /system/lib mappát.

[ Szerkesztve ]

A hackelés nem károkozás másnak, hanem valamit úgy használunk, ahogy arra készítésekor nem gondoltak.