- DIGI Mobil
- Samsung Univerzum: Az S23-at is megbabonázta a Galaxy AI
- Samsung Galaxy Z Fold5 - toldozás-foldozás
- Magisk
- Honor Magic V2 - origami
- Android alkalmazások - szoftver kibeszélő topik
- Huawei Mate 10 Pro - mestersége az intelligencia
- Realme 8 - az igazi nyolcas
- Itt az első kép a 2024-es Nokia 3210-ről
- Telekom mobilszolgáltatások
Hirdetés
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Dragon Ball: Sparking! Zero - Mester és tanítvány
gp Egyelőre még mindig nem kaptunk megjelenési dátumot a játékhoz.
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
-
Mobilarena
Ezt a fórumot azért hoztuk létre,hogy ne zavarjuk azon felhasználókat, akik még csak most ismerkednek a tablettel, vagy akár az Android rendszerrel.
Új hozzászólás Aktív témák
-
balika011
senior tag
É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.
-
NePee
csendes tag
válasz balika011 #2902 üzenetére
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=1Kíváncsi vagyok mi fog történni
[ Szerkesztve ]
-
NePee
csendes tag
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. -
NePee
csendes tag
válasz RoundRobin #2905 üzenetére
Igen a 352byte a tartalomhoz számolódik sajnos, a számoláshoz pedig soha nem lesz kulcsunk
-
NePee
csendes tag
válasz Keeperv85 #2907 üzenetére
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.
-
Keeperv85
nagyúr
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 ]
-
NePee
csendes tag
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 ]
-
balika011
senior tag
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.
-
RoundRobin
aktív tag
Nyilván valahol a kulcsnak tárolva kell lennie a tableten
Vagy a Soc-ban.
Talán érdemi infó értékkel bír, a teclast ROM tartalma:
2014.04.24. 18:55 99ÿ296 AZ2_FW_DnX_20.28_CWAK_[B]signed[/B].bin
2014.04.24. 18:55 99ÿ296 AZ2_OS_DnX_20.28_CWAK_[B]signed[/B].bin
2014.04.24. 18:55 880 AZ2_Soft_Fuse_CWAK_[B]signed[/B].bin
2014.04.24. 18:55 7ÿ749ÿ632 boot.bin
2013.12.10. 16:26 2ÿ031ÿ484 clvp_ifwi_patch_engineering.bin
2014.04.25. 16:18 2ÿ031ÿ484 clvp_ifwi_patch_production.bin
2013.12.10. 16:24 99ÿ296 dnx_fwr.bin
2013.08.30. 15:40 99ÿ296 dnx_osr.bin
2014.04.24. 18:55 10ÿ388ÿ480 droidboot.img
2014.04.24. 18:55 10ÿ388ÿ480 droidboot.img.POS.bin
2014.04.24. 18:55 6ÿ035 flash.xml
2014.04.24. 18:55 2ÿ360ÿ832 logo.img
2014.02.10. 14:32 1ÿ161 partition.tbl
2014.04.24. 18:55 9ÿ546ÿ752 recovery.img
2014.04.24. 18:51 306ÿ468ÿ623 system.img.gzVennék: 286-os (esetleg XT) alaplapot.
-
NePee
csendes tag
válasz RoundRobin #2916 üzenetére
Meg persze a moddolás ellen véd, integritáshoz nem kellene a 352byte
-
NePee
csendes tag
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.
-
NePee
csendes tag
válasz Keeperv85 #2923 üzenetére
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.
-
RoundRobin
aktív tag
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.
Ez szinte 100 %.
a boot.img-ből (32 byte (=256 bit)):
androidboot.serialno=01234567890123456789012345678901Vennék: 286-os (esetleg XT) alaplapot.
-
NePee
csendes tag
válasz RoundRobin #2927 üzenetére
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.
-
RoundRobin
aktív tag
válasz RoundRobin #2929 üzenetére
Aryes egyébként 'mond valamit'.
Ha a boot kód code szegmensét írod át, akkor bármelyik byte-ot változtatod meg, a kód nem fog lefutni. Az adatszegmensnél is elég nagy szerencse kell hozzá, hogy ne USB jel legyen a történetből.
Nem azért írom, hogy rábírjalak a splash editálására, flashelésére, csak azért, mert tényleg így van.Vennék: 286-os (esetleg XT) alaplapot.
-
NePee
csendes tag
válasz RoundRobin #2930 üzenetére
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=1Erre:
watchdog.watchdog_thresh=50Nem é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)
-
RoundRobin
aktív tag
Az az érték lehet lényegi is. Nem tudom. Feltételezem hexaeditorral írtad át.
Nekem mindenesetre valahogy nem áll össze a kép, egy dolog előttem nem tiszta, de most már nem is lesz az, megyek aludni, mert már nem látok ki a fejemből. Holnap, frissebben átgondolom az egészet. Jó éjt.Vennék: 286-os (esetleg XT) alaplapot.
-
sepyi
aktív tag
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)
-
Keeperv85
nagyúr
"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?
-
NePee
csendes tag
válasz Keeperv85 #2934 üzenetére
A logo.bmp SHA256 általam számolva: 7d235214f825ec948f73c33943d57f5f613e278f4435344b077870ad58e07378
A számoló progi amit használok:
https://kanguru.zendesk.com/attachments/token/0xdkf3ohvnbjyd4/?name=sha256sum.exeA splash.img-k összehasonlítva pedig (dott - modecom freetab 7800):
[link]Nem tudom te mit és hol / hogyan nézel
[ Szerkesztve ]
-
RoundRobin
aktív tag
válasz Keeperv85 #2942 üzenetére
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...
A programok elolvassák a headert, abban ott a hosszúság, szélesség. Ebből már tudják, hogy meddig tart a file-ban a bittérkép.
Vennék: 286-os (esetleg XT) alaplapot.
-
sinya123
csendes tag
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?
-
Simba86
senior tag
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
-
nagyúr
válasz Simba86 #2946 üzenetére
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. -
Simba86
senior tag
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
-
balika011
senior tag
válasz Simba86 #2949 üzenetére
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.