Dotaz: Špatně zabalené CPIO

[joseff]

Dobrý den,

již dlouho řešíme jeden problém v našem open source projektu.

Provádíme aktualizaci Firmware do jednoho set-top-boxu, aby mohl přijímat HDTV a IPTV.

Napřed byl problém tento balíček rozbalit. To se po delší době povedlo.

Ale nyní je opačný problém.

Rozbalíme ho, provedeme úpravu, zabalíme, do boxu se překopíruje, ale před rozbalením to vypíše, že nesouhlasí kontrolní součet, nic nerozbalí a tím šou končí, box je zatuhlý, dokud se neprovede reboot.

Pokud se do boxu nahraje ta samá verze, ale bez našeho zásahu, tak jí tam rozbalí a perfektně funguje, pouze do ní není přístup ani přes konzoli, protože to chce heslo pro root.

To znamená, že program (Firmloader napsaný asi ve Visual Basicu) který k překopírování používáme, funguje, zde chybu nehledat.

Ale pokud to rozbalíme, neuděláme žádný zásah a opět zabalíme, tak tato verze nefunguje.

Ta chyba je určitě na naší straně.

1) moc tomu nerozumíme

2) nepoužíváme čistě Linux, ale Windows a v něm přes nějaký emulátor nebo něco podobného Linux, takže i zde je hodně příležitostí pro chyby

- buď nevhodná verze Linuxu, nebo nevhodná nebo starší verze zabalovacího programu

Je možno nějak zjistit, pomocí jakého programu, jakou verzí a s jakým nastavením to bylo zabaleno?

Zde to řešíme, jsou tam volně ke stažení všechny potřebné soubory a naše poznatky a výpis z konzole:

http://forum.ican3800.zajsoft.net/viewtopic.php?f=5&t=309

Pokud někdo tuší, jak na to, tak to může též zkusit rozbalit, nebo použít již rozbalené,

v souboru /etc/shadow odstranit řetězec (heslo) pro root, zabalit a nahrát třeba na uloz.to.

Já to otestuji a budu informovat, co to dělá.

Předem děkuji za pomoc.

---

---

Odpovědi

[Jendа]

Rozbalíme ho, provedeme úpravu, zabalíme, do boxu se překopíruje, ale před rozbalením to vypíše, že nesouhlasí kontrolní součet, nic nerozbalí a tím šou končí, box je zatuhlý, dokud se neprovede reboot.

Hele, já nevím, ale tohle by podle mě mohlo znamenat, že nesouhlasí nějaký kontrolní součet.

Ten FW si nejspíš někde v tom archivu drží ještě checksum a ta pochopitelně po změně nesouhlasí. Musíš zjistit, kde ta checksum je a jak ji přepočítat, nebo alternativně v tom flasheru najít, kde se kontroluje, a zařídit, aby se nekontrolovala. Možná by pomohlo zjistit, kdo že vypíše tu hlášku o nesouhlasícím součtu. Pokud je to ten flasher, od kterého máš zdrojáky, tak to tam prostě zakomentuj.

[joseff]

Ano, přesně toto víme již 2 měsíce, bohužel vůbe netušíme, co s tím. Hodně pokusů se zabalením bylo provedeno, ale žádný úspěch.

Na ABCLINUXU jsem se obrátil až nyní, protože již dál nevíme a projekt tímto bohužel končí.

Což by byla škoda, protože nějaká ta stovka uživatelů tohoto boxu doufá v novou verzi. Bohužel nikdo z těch uživatelů nám nepomohl, protože se jedná o běžné uživatele.

[Jendа]

Tak kdo hlásí ten špatný kontrolní součet?

[joseff]

Na set-top-box jsem napíchnut přes konzoli (COM PORT) a putty zobrazuje hlášky z boxu.

Z PC se to pomocí Firmloaderu překopíruje do set-top-boxu. Po překopírování se Firmloader ukončí. Zatím OK, ale do této doby putty vůbec nic nevypisuje.

Po rebootu to sice chtělo rozbalit, ale...

A nyní to teprve začíná psát text:

RebootLinux version 2.6.11.12_stm20-33 (A.Mielcarek@autogrator1) (gcc version 3.4.3 (STMicroelectronics/Linux Base 3.4.3-19) [build Mar 10 2006]) #1 Wed Sep 8 11:32:36 CEST 2010
ADB STB initialisation
STb7100 version 3.x
Built 1 zonelists
Kernel command line: console=ttyAS0,115200 splasharea=4096,0x0B000000           
PID hash table entries: 512 (order: 9, 8192 bytes)
Calculated peripheral clock value 65108 differs from sh_pclk value 66000000, fixing..
PLL1     : 531.00MHz
PLL2     : 402.00MHz
ST40 CPU : 265.50MHz
ST40 BUS : 132.75MHz
ST40 PER :  66.37MHz
SLIM     : 265.50MHz
ST231    : 402.00MHz
STBUS    : 201.00MHz
EMI      : 100.50MHz
LMI      : 201.00MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 67712k/126976k available (1898k kernel code, 59196k reserved, 227k data, 39412k init)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: STb710x
Kernel panic - not syncing: invalid compressed format (err=1)

[Jendа]

Tohle podle mě není chyba nějakého CRC, ale jako kdyby byl ten soubor/filesystém zabalený tak, že ho kernel prostě nedokáže namountovat. Problémů může být spousta - parametry cpio, flasher to špatně zapíše do flashky…

[MadCatX]

Schválně jsem zkusil ten firm.gzip rozbalit a znovu zabalit, aniž bych v obsaženém CPIO něco měnil. Je zajímavé, že mnou vytvořený archiv má jinou velikost než archiv originální - stupněm komprese to není, to jsem zkoušel. Kontrolní součty CPIO ale sedí z obou archivů. Můžete zkusit nahrát do STB ten můj archiv. Pokud ani ten nebude fungovat, napadají mě v podstatě dvě možnosti. Buď je už originální archiv chybný, nebo se něco stane až při kompresi do gzip. Link

Pochopil jsem z vámi odkazované diskuse správně, že je potřeba ten rozkuchaný firmware po modifikaci zase poskládat zpátky? Pokud ano, máte jak ověřit, že nevzniká problém až tam?

[MadCatX]

Zkusil jsem ještě jednu věc, a sice to CPIO rozbalit, v ./images přidat jeden řádek do README.txt a zase ho složit zpátky. Vzniklý CPIO jsem zagzipoval a doplnil nulami tak, aby seděla velikost gzip archivu. Momentálně mám z jádra vyřazenou podporu JFFS2, takže přímo ten image upravovat nemůžu. Pokud by vám ale aspoň jeden z mých pokusů zafungoval, zaktivním JFFS2 a zkusím upravit i ten image.

FW pokus 2

[jeninicicek]

Příloha:

• Zabalovani.txt (568 bytů)

ahoj všem,

Josef mi hodil odkaz, že pro radu s boxem šel i sem, trošku zkusím nastínít líp, co máme a co jede a co už ne. Rozbalení není problém a zabalení, které používám je momentálně viz příloha. 
Pokud při postupu neudělám žádné změny ve firmware dostanu identický soubor s originálním. Pokud však udělám jakoukoli sebemenší změnu už to nefunguje. Já osobně mám na virtuálním stroji debian a občas fedoru, postup funguje vždy. Ale stačí kdekoli změnit čárku (např. jsem zkusil do jednoho z readme přidat písmeno) a spadne to...

[MadCatX]

Na podobný postup jsem přišel včera taky, nicméně všiml jsem si několika případných zádrhelů.

• Kontrolujete při rozbalování toho CPIO, že se rozbalí skutečně celé, tedy všech 83574 bloků? Obsažený adresář /dev se mi rozbalil, až když jsem cpio spustil pod rootem.
• Pokud pro balení zpět do CPIO používáte doporučený postup

     find . -depth | cpio -ova -H newc > ../myfirm.cpio
    

  vytvoří se archiv, kde budou soubory v jiném pořad. Tomu se dá zabránit např. tím, že sestavíte seznam souborů obsažených v originálním CPIO:

      cpio -it < orig.cpio > flist.txt
      cat ../flist.txt | cpio -ova -H newc > ../myfirm.cpio
    

  Netvrdím, že by to mělo vadit, ale určitě to stojí za pokus.
• mkfs.jffs2 mi též vytvořil jiný RAW soubor, i když jsem v původím přímountovaném image nic neměnil. To jsem vyřešil tím, že jsem nakopíroval RAW do /dev/mtdblock0, ten mountnul, upravil /etc/shadow a přes dd vytvořil RAW

     modprobe mtdblock
     modprobe mtdram total_size=39000 erase_size=16
     dd if=NAND.raw of=/dev/mtdblock0
     mount -t jffs2 -w /dev/mtdblock0 /media/raw
     ...
     umount /media/raw
     dd if=/dev/mtdblock0 of=modNAND.raw
    

  Výsledný soubor bude větší než originál, ale přebývající 0xFF na konci by mělo být možné useknout.

Tímto způsobem jsem dal dohromady poslední pokus, tak uvidíte:)

Celý firmware i s úvodním souborem, padovaný na velikost firmbcrc
Pouze CPIO s upraveným image

[Milan Roubal]

Neni potreba po tom poslednim dd provest jeste toto?

jffs2dump -r -e modNAND.raw -l new_modNAND.raw

Tedy prevest mezi sebou little a big endian?

[MadCatX]

Tohle mě taky napadlo, ale SH4 procesory jsou bi-endianové a původní NAND.raw a můj modNAND.raw jsou až na úpravu paddingu na konci a obsah /etc/shadow stejné, v tom bych problém tedy nehledal; kontroloval jsem to vbindiffem.

Ještě jsem zkusil toto:

1. Rozbalit gzip
2. Rozbalit CPIO
3. Přepsat pár znaků v images/README.txt
4. Zabalit, zagzipovat, přidat úvodní soubor a napadovat na velikost původního FW, na NAND.raw jsem vůbec nesahal

Pokud nefunguje ani tohle, něco se zprasí buď už při rozbalování nebo při zpětné kompresi(link).

[jeninicicek]

Pod rootem pracuji vždy, tohoto problému jsem si všiml dřív, co se týče pořadí programů, tak mi to nepřijde důležité, pokud je verze ověřována bude to po změně vždy špatně, je-li to balením tak ne tímto, protože jinak by těžko vydávali časem nové verze firmware... příkaz mkfs.jffs2 mi taky háže pod novými liny jiný výsledek, ale to je asi jinou verzí, naučil jsem se používat systém(starší debian), ve kterém se podařilo upravit jednu ze starších verzí firmware španělům(http://forum.ican3800.zajsoft.net/download/ican3800--1.45GB.rar). Potom dostanu identický raw. popřípadě stejně jako ty jsem měnil věci přímo v mountnutém obraze. Takže testovat a radit další možnosti dále a dále, jednou na to přijdem a já se rád něčemu přiučím...

[Milan Roubal]

Na tom postupu je zajimava ta cast

Otevøeme v hexeditoru a pøepiseme datum vytvoøeni (jde o 5-8 byte souboru gzip).

bez toho ten firmware nejede? Tedy pokud se vezme ten jejich originalni soubor a prepsou se mu bajty 5-8 treba na dnesek, tak to funguje ci nikoliv?

[jeninicicek]

A ještě poprosím, posíláte-li nám soubory na zkoušku, posílejte už komplet firmware, ne jen gzip soubor bez úvodní části a nedoplněný na originál velikost firmware. Někteří z těch co to testují se to zatím neumějí dát dohromady. Pokud jste jako výchozí soubor již použili gzip(ten je na foru icanu pro ty co ho neuměli z firmware dostat) napište to do příspěvku, aby to někdo doplnil a mohli testovat všichni ochotní majitelé boxů. Jinak pokud sami nevíte co doplněním myslím, vyzkoušejte si vše včetně rozbalování od začátku, třeba najdete chybu už tam(vše potřebné i s návodem, abyste nestrávili noc na foru icanu zde http://uloz.to/xCq6aWv/jaknao2czfirmware-zip)...

[jeninicicek]

Ano firmware je rozkuchaný, komplet i s návodem jak jsem dal níže. Já osobně předpokládám, že to bude někde tam, bohužel těch co dokáží firmware kuchat na gzip a zbytek a složit zpět mezi námi moc není... Kdyby mi někdo popsal co přesně dělá část firmware před gzipem, byl bych moc rád...

[joseff]

Zkusil jsem nahrát mdzf_firm od MadCatX.

Dobré je, že po překopírování do boxu a rebootování to chtělo rozbalit.

Bohužel opět stejný problém.

Nerozbaluje se to, box zatuhne a konzola zobrazí skoro stejnou závadu:

RebootLinux version 2.6.11.12_stm20-33 (A.Mielcarek@autogrator1) (gcc version 3.4.3 (STMicroelectronics/Linux Base 3.4.3-19) [build Mar 10 2006]) #1 Wed Sep 8 11:32:36 CEST 2010
ADB STB initialisation
STb7100 version 3.x
Built 1 zonelists
Kernel command line: console=ttyAS0,115200 splasharea=4096,0x0B000000           
PID hash table entries: 512 (order: 9, 8192 bytes)
Calculated peripheral clock value 63520 differs from sh_pclk value 66000000, fixing..
PLL1     : 531.00MHz
PLL2     : 402.00MHz
ST40 CPU : 265.50MHz
ST40 BUS : 132.75MHz
ST40 PER :  66.37MHz
SLIM     : 265.50MHz
ST231    : 402.00MHz
STBUS    : 201.00MHz
EMI      : 100.50MHz
LMI      : 201.00MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 67712k/126976k available (1898k kernel code, 59196k reserved, 227k data, 39412k init)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: STb710x
Kernel panic - not syncing: invalid compressed format (err=1)

[joseff]

Zkusil jsem nahrát verzi mdz_nomod od MadCatX.

Bohužel naprosto stejná závada i výpis je naprosto stejný, proto ho nepřidávám.

[joseff]

Hledal jsem další informace a nechal to v tomto stavu bloknuté asi déle jak 10 min a ono to najednou vyhodilo další informace, asi to moc nepomůže, ale dávám to sem:

RebootLinux version 2.6.11.12_stm20-33 (A.Mielcarek@autogrator1) (gcc version 3.4.3 (STMicroelectronics/Linux Base 3.4.3-19) [build Mar 10 2006]) #1 Wed Sep 8 11:32:36 CEST 2010
ADB STB initialisation
STb7100 version 3.x
Built 1 zonelists
Kernel command line: console=ttyAS0,115200 splasharea=4096,0x0B000000           
PID hash table entries: 512 (order: 9, 8192 bytes)
Calculated peripheral clock value 65108 differs from sh_pclk value 66000000, fixing..
PLL1     : 531.00MHz
PLL2     : 402.00MHz
ST40 CPU : 265.50MHz
ST40 BUS : 132.75MHz
ST40 PER :  66.37MHz
SLIM     : 265.50MHz
ST231    : 402.00MHz
STBUS    : 201.00MHz
EMI      : 100.50MHz
LMI      : 201.00MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 67712k/126976k available (1898k kernel code, 59196k reserved, 227k data, 39412k init)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: STb710x
Kernel panic - not syncing: invalid compressed format (err=1)
 <1>Unable to handle kernel NULL pointer dereference at virtual address 0000000c
pc = 84438808
*pde = 00000000
Oops: 0000 [#1]

Pid : 1, Comm:              swapper
PC is at __queue_work+0x28/0xa0
PC  : 84438808 SP  : 86df7eac SR  : 400081f0 TEA : 0000000c    Not tainted
R0  : 00000000 R1  : 00000008 R2  : 845f4634 R3  : 00000000
R4  : 00000001 R5  : 845f4634 R6  : 86cab044 R7  : 86cab03c
R8  : 845f4634 R9  : 00000000 R10 : 00000000 R11 : 86df6000
R12 : 86df7ed0 R13 : 86caad3c R14 : 844251a0 R15 : 86df7eac
MACH: 0000008b MACL: 000000c0 GBR : 00000000 PR  : 84438800

Call trace:
[<844388dc>] queue_work+0x5c/0xe0
[<8442f95c>] run_timer_softirq+0xdc/0x260
[<844f6e20>] blank_screen_t+0x0/0x20
[<84445852>] handle_IRQ_event+0x52/0xe0
[<8442ac7a>] __do_softirq+0x5a/0xe0
[<8442ad46>] do_softirq+0x46/0x60
[<844d1980>] __const_udelay+0x0/0x20
[<844170c0>] do_IRQ+0x0/0x60
[<8442ae66>] irq_exit+0x46/0x80
[<8441ee80>] sub_preempt_count+0x0/0xa0
[<844170ee>] do_IRQ+0x2e/0x60
[<8441406e>] ret_from_irq+0x0/0x12
[<844d1960>] __delay+0x0/0x20
[<844d1980>] __const_udelay+0x0/0x20
[<844d1962>] __delay+0x2/0x20
[<84424398>] panic+0xb8/0x100
[<84411112>] init+0x32/0xf20
[<84412004>] kernel_thread_helper+0x4/0x20

Kernel panic - not syncing: Aiee, killing interrupt handler!

[joseff]

Kolega již přišel na postup, jak to zabalit:

Tak po dlouhém testování, konečně dokáži zabalit firmware pro box tak, aby s ním šlo flashovat. Takže tady je doufám srozumitelný návod:

Co potřebujeme:

Já jsem vycházel z originál firmwaru O2, ale většina návodu funguje i pro ostatní verze. Pracoval jsem s hexeditorem xvi32 pod windows a potřebné části pod Fedora 17. Celé by to mělo jít provést pod libovolným linux systémem i třeba na virtuálních mašinách.

1) Rozbalíme O2 firmware na části vmlinux(tak se oficiálně nazývá část firmwaru před gzip souborem) a gzip soubor.

2) V hexeditoru odřízneme ze souboru gzip nuly na konci(potřebujeme vědět jeho velikost bez nich). Soubor tím nijak nepoškodíme.

Odtud je doporučené a místy potřebné pracovat jako root pod linuxem.

3) Rozbalíme gzip soubor do nové složky pomocí příkazu

cat _gzipsoubor_ |gunzip| cpio -i --make-directories

4) Nyní potřebujeme získat místo(sami si vyzkoušejte, že nedokážete beze změn vytvořit stejně velký gzip jak originál-jako originální velikost beru velikost gzipu bez nul). Bohužel jsem nepřišel na způsob jak omezit velikost souboru NAND.raw(ten bude upravován v dalších krocích, ale i po upravách v něm se mi neměnila jeho velikost). Stejně tak většina souborů je zde potřebných. Bez problémů můžeme odstranit soubor README ve složce images, ale to nestačí, takže jsem ještě(ač je to prasárna) odstranil téměř všechny komentáře v souboru \etc\init.d\rcS. Pokud provedete tyto úpravy zkuste si vytvořit(podle návodu dále) pokusný gzip a ověřte zda má menší velikost než originál. Pokud ano můžeme pokračovat k té pravé editaci.

5) Nyní budeme editovat budoucí systém boxu, ten je ukryt v jffs2 obrazu \images\NAND.raw. Zkopírujeme si ho na jiné místo(je lepší mít originál v záloze)a namountujeme zkopírovaný obraz pomocí příkazů: mknod /dev/mtdblock0 b 31 0 modprobe mtdblock modprobe mtdram total_size=65536 erase_size=256 modprobe jffs2 dd if=_zkopirovanyobraz_ of=/dev/mtdblock0 mount -t jffs2 /dev/mtdblock0 \_složka,kekterechcempripojit_

6) El artista ve svých návodech doporučoval nepracovat přímo na mountované složce, já však měk s následným vytváření jffs problémy a proto jsem pracoval přímo v ní. Mnou testované úpravy zatím spočívaly v odstranění hesla. Tedy upravíme potřebně soubory \etc\passwd a \etc\shadow. Popřípadě můžeme přidat další věci jako telnet, části mediacentra, atd... Omezeni jsme velikostí...

7) Pomocí umount odmountujeme složku s obrazem.

8) Prací ve složce jsme vlastně přímo upravovali soubor obrazu, takže ho teď nakopírujeme zpět do složky \images v rozbaleném gzipu.

9) Vytváříme nový gzip:

Po dlouhých problémech jsem došel k závěru, že nevhodnější je vytvořit si jednoduchý script, kterým vytvoříme cpio archiv a ten následně zagzipujeme.

script:

#!/bin/bash
echo "Menim opravneni init"
chmod 0755 /_slozkasrozgzipem_/init
CPA=`pwd`
echo "Tvorim cpio"
cd _slozkasrozgzipem_ && find . | cpio -o -H newc > $CPA/newfirmware.cpio
echo "Tvorim gzip"
cd $CPA && cat newfirmware.cpio |gzip -nfcr9 >> newfirmware.gzip)
echo "Mazu nepotrebne cpio"
rm newfirmware.cpio
echo "Hotovo"

Spustíme script jako root: sudo ./_nasscript_

Vytvoří se nám soubor newfirmware.gzip.

10) Zkontrolujeme, zda je newfirmware.gzip menší nebo roven originálnímu gzipu bez nul, pokud ano, pokračujeme dále, pokud ne musíme něco oželet, promazat....

Odteď je už opět jedno na jakém systému pracujeme.

11) Před newfirmware.gzip vložíme v hexeditoru zpět vmlinux, a na konci ho doplníme na originální velikost firmwaru nulami(důležité).

12) Máme hotovo můžeme flashovat (doporučuji novou univerzální verzi flashovacího nástroje)...

--------------------------------------------------------

Po neúspěších s úpravou NAND tak aby neobsahovala crc chyby jsem se rozhodl nepoužít NAND.raw ale obyčejný tar.gzip...

Systém spočívá v upravení rcS souboru a místo souboru NAND.raw jsem tam dal firmout.gzip, myslím, že ten by jste měli být schopni upravit každý, je to teď velmi jednoduché... soubor je také menší než s použitím NAND.raw..., takže další výhoda...

Takže postup:

1) Stáhněte firmware níže (nutno, je v něm upravený soubor rcS a pár dalších změn)

2) provedeme s ním kroky 1-3

3) ve složce images je soubor firmout.gzip, je to běžný tar-gzip archiv, rozbalte ho a můžete upravovat...

4) po upravení zabalíme (já použil: tar cf - * |gzip -9 >> ../firmout.gzip)

5) vzniklý soubor překopírujeme do složky images

6) Pokračujeme od kroku 9

---------------------------------------------------------

Napadlo mne to při rozbalování cybervacy, kterej používá bzip kompresi, prostě jsem si řek, že když to šlo jemu, nám musí taky...

Tady posílám první beta test-test verzi s funkčním telnetem a přístupem na placené IPTV od O2, je do ní nakopírováno i mediacentrum.

Obsahuje upravené Flashovací instrukce, takže opakované Flashování je možné bez potíž.

- v této verzi zatím nejsou odchytané chyby, ale docela funguje, v této verzi USB zatím nefunguje, ale v další verzi bude

http://uloz.to/xDcuiSu/o2damectelnet-rar

Obrana proti O2 updatu:

OPCH musí být ta od O2, aby jela O2TV, ale port nastavit špatně.

O2TV běží, ale firmware O2 nejde updatnout...

Nyní by mělo být možné provádět v boxu úpravy a používat IPTV bez nutnosti Flashovat zpět na nepoužitelnou O2 verzi.

Kdo má zájem, tak se může připojit.