Předchozí díl byla taková malá lekce, jak se vůbec v binárních souborech vyznat. Dnes už se dostaneme k tomu, jak naše nově načerpané schopnosti použít. Stáhněte si BNL soubor, otevřete hexaeditor a pojďte si teorii vyzkoušet v praxi.
První pohled do BNL souboru
Začal jsem tím, že jsem postahoval všechny možné BNL soubory od Albi a upřel na ně pátravé oko. Pro účely tohoto článku jsem vybral miniknihu “Denní činnosti“ (jméno souboru minikniha-denni-cinnosti.bnl, MD5 73db7f5ab77836afd987ea046ebf9be3), abyste si v průběhu čtení mohli taky „sáhnout“ na všechny ty bity a bajty.
V hlavičce je na první pohled patrné, že se nejedná o jednoduchá počitadla nebo ukazatele. Na druhou stranu jsou vidět opakující se 32bitové hodnoty (dword). To jsem si nechal na později a posunul se o něco dále.
Zde je pro změnu zcela krásně vidět, že se jedná o 32bitové ukazatele někam dál do souboru, ve formátu little-endian. Na adrese 0x10BA4 je ukazatel 0x118DE, následuje 0x0118EA atd.
Na úkoly jste si určitě v minulém díle již zvykli, takže si zde můžete vyzkoušet a ověřit své znalosti. Obě otázky se vztahují k obrázku č.2
- Jaký ukazatel se nachází na adrese 0x10CA8?
- Na jaké adrese je poslední ukazatel?
- Na adrese 0x10CA8 je ukazatel 0x11BEA
- Poslední ukazatel je na adrese 0x10D10
Listuji dál souborem a vidím, že se na těchto místech nachází něco, co by mohla být tabulka 16bit hodnot. Prozatím ji nebudu interpretovat a podívám se ještě o kousek dál.
Ha! MP3!
A tam je už něco, kde si můžu být téměř jist, že je to MP3 soubor, který se dal v bnl souboru očekávat. Daly se očekávat i jiné zvukové formáty (WAV, Ogg), ale z popisu SoCu Sonix víme, že MP3 podporují.
Problém s MP3 soubory je v tom, že se dá obtížně odhadnout, zda jsou šifrované, protože jsou téměř bez hlaviček. Každý frame (rámec) je samostatný, obsahuje hlavičku, která se skládá jen z pár bitů nastavených na 1 a mp3 soubor je jen několik za sebou jdoucích samostatných rámců, bez nějakých kontejnerů a povinných metadat.
Poslední věta je téměř pravdivá. Ale postupem času se začala do mp3 souborů přidávat metadata. Buď starým způsobem, na konci souboru uvozené magicem TAG nebo novým způsobem, na začátek uvozené magickou konstantou ID3. A co vidím na začátku – 1D3, takže částečně pozměněný. Všechny další zvýrazněné kousky ukazují na to, že se jedná o mp3 soubor, vytvořený pomocí audio kodeku LAME, kde se dají očekávat textové řetězce Lavf, Lavc, LAME s čísly verzí. Ale vidím, že vždy jsou zašifrované jen některé bajty a v bloku nulových bajtů (např. mezi 0x12AE0 až 0x12B5F) nejsou změněné žádné. Z toho můžu usoudit, že autor šifry byl do jisté míry vychytralý a snažil se omezit snahu o analýzu.
Protože mp3 je vysoce komprimovaný formát, není možné odhadnout, jak má vypadat nešifrovaný a pak z rozdílu mezi nešifrovaným a šifrovaným odvodit způsob šifrování. Jedna z metod dešifrování je soustředit se v neznámém binárním souboru na „prázdná“ místa, tj. obsahující 0x00 nebo 0xFF a podívat se, co s nimi šifra provede. Zde ovšem vidím, že blok nul je uniformní. Tahle šifra jistě tyto bajty přeskakuje. To mi radost neudělalo.
Při kontrole německé dokumentace k TipToi formátu jsem se dočetl, že moje teorie byla správná – i jejich šifra přeskakuje 0x00, 0xFF, hodnotu klíče a negovanou hodnotu klíče. Ale obecně BNL šifrování není stejné. Vidím zde, že dost informací z MP3 není zašifrováno. Musí to být tedy jinak. Postoupím dál, ale zapamatuji si offset prvního MP3 souboru – je to 0x12A00.
Další zjevný začátek MP3 nalézám na offsetu 0x2A600.
A co vy? Dokážete také najít začátek MP3 v nějakém BNL souboru? Zkuste to na následujících 2 úkolech.
To bylo snadné, viďte? Tak teď sami.
Stáhněte si soubor „Básničky z lesa“ a najděte první MP3. Na jakém začíná offsetu?
První MP3 začíná na offsetu 0xE400
Tabulka MP3 souborů
Protože je zjevné, že tato druhá MP3 začíná stejně, jako 1. MP3 na offsetu 0x12A00 a šifruje stejné bajty stejně, usuzuji, že šifrování se restartuje pro každý MP3 soubor zvlášť. Poznamenám si druhý offset – 0x2A600 a jdu zkusit něco hledat do hlavičky. Protože už jsem dříve v souboru viděl platné 32bitové offsety v little endianu, zkusím hledat:
A voilà, na offsetu 0x1224E vidím obě moje zapamatované hodnoty – 0x12A00 a 0x2A600. Následuje řada ukazatelů, které stoupají. Další jsou 0x30A00 a 0x35000. Z letmého pohledu je zřejmé, že tyto offsety ukazují na další MP3 soubory. Můžu tedy udělat závěr, že na offsetu 0x1224E začíná tabulka MP3 souborů.
A když jedu souborem níže, uvidím, že tabulka končí na offsetu 0x129C2 hodnotou 0x026BDA00. Toto číslo je zároveň délkou souboru – pokusy dělám na 40MB dlouhém BNL souboru (soubor má přesně 40 622 592 bajtů, což je v šestnáctkové soustavě 0x026BDA00) . Z toho se dá usoudit zhruba toto: To, co jsem si teď prohlížel, je tabulka všech MP3 souborů. Tyto jsou uloženy hned za touto tabulkou na nějakém zarovnaném offsetu (vždy končí 0x00, takže teoreticky na adrese dělitelné 256) a MP3 soubory jsou naskládány jeden za druhým až do konce souboru. Takže všechno před tím obsahuje veškeré informace o knize. Podle délky tabulky snadno spočítáme počet mp3 souborů: ( 0x129C2 – 0x1224E ) / 4 = 0x1DD = 477 mp3 souborů.
Čas na úkol? Jasně! Jdeme na něj. Soubor „Básničky z lesa“ už máte stažený, takže v něm hledáme dál.
- Díky předchozímu úkolu už znáte offset prvního MP3 souboru. Najděte začátek druhého MP3 souboru.
- Teď pomocí offsetů na 1. a 2. MP3 soubor najděte offset tabulky MP3 souborů.
- Najděte konec tabulky MP3 souborů a zjistěte zde zapsanou hodnotu.
- Spočítejte počet obsažených MP3 souborů.
- Zkuste použít vyhledávání, namísto listování souborem. Pokud váš hexaeditor neumí vyhledávat, vyměňte ho.
- Nezapomínejte na endianitu, všimněte si, že v příkladu výše, se hodnota 0x12A00 hledá jako řetězec 002A0100
- Jednoduše listujte tabulkou a pozorujte, jak 32bit hodnoty rostou.
- Offset konce tabulky mínus offset začátku tabulky, to celé děleno čtyřmi (protože 4 bajty)
- První MP3 začíná na offsetu 0xE400, druhý začíná na 0x28600
- Vyhledáním řetězce 00E4000000860200 jste se dostali k offsetu 0xD9A4
- Tabulka končí na offsetu 0xE220 hodnotou 0x23B3A00
- (0xE220 – 0xD9A4) / 4 = 0x21F = 543 MP3 souborů
Dešifrování MP3 souborů
Bez rozšifrovaných MP3 souborů se dál nepohnu, jenže jak dešifrovat něco, k čemu neznám „plain text“, tj. nešifrovaný soubor? Navíc je to soubor, kde nelze snadno poznat, který bajt je vlastně šifrovaný, i kvůli vysoké entropii komprimovaných rámců. Naštěstí se ukázalo, že se sice autor šifrování snažil být vychytralý, ale dopadlo to jako obvykle, když se o to snaží amatér. Slabinou té šifry je naštěstí to, že každý bajt je šifrovaný nezávisle od předchozího, tj. když se trefí do monotónního bloku, „uvidím“ jak se šifra opakuje. Tomu se sice snažil vyhnout tím, že nešifruje dva nejčastější monotónní bloky, tj. 0x00 a 0xFF, ale zapomněl se podívat na MP3 soubory. Ty totiž dost často končí tichem, a ačkoli dost často je enkódováno jako 0xFF (což mi kazí moje snahy), dost často se enkódují jako řada bajtů 0x55 nebo 0xAA.
A ano, v mém souboru je opravdu na konci řada bloků s hodnotou 0x55. Vyznačil jsem bajty, které jsou nejspíše šifrované. (Cca 20 bajtové bloky dat, které jsem přeskakoval, jsou nějaké hlavičky režie MP3 souboru). Na první pohled je vidět, že jsou změněny 4 bajty na jednom 16 bajtovém řádku, jejich offsety různě poskakují. Nejjednodušší „šifrování“ je logická funkce XOR – kvůli jejím vlastnostem. Když přexoruji celý blok hodnot 0x55 hodnotou 0x55, zůstanou mi v nezašifrovaných místech hodnoty 0x00 a v zašifrovaných hodnoty vlastního dešifrovacího klíče. Zkusím:
Je to tak. Zběžným pohledem vidím, že hodnota klíče se opakuje po 16 hodnotách. Tedy v hexu:
78 CA D9 EA – B7 AD DB 0C – 05 9D 0C E3 – 07 9D 0C E3
V tuto chvíli nevím, kde klíč začíná, ale to přeci zjistím jednoduše. Místo ID3 mám na začátku MP3 souboru hodnotu 1D3. Hexa hodnota znaku ‚1‘ je 0x31, hexa hodnota znaku ‚I‘ je 0x49. 0x31 xor 0x49 je 0x78. A shodou okolností je to první hodnota klíče, kterou jsem si vypsal výše. Takže teď už vím, jakým klíčem odšifrovat soubor, a vím, kde klíč začíná.
Můj další myšlenkový postup byl tento:
- Platí tatáž šifra i pro jiný MP3 soubor ve stejném BNL souboru?
- Platí tatáž šifra i pro jiný BNL soubor?
Odpovědi na tyto otázky se dozvíte v příštím díle. Než vyjde, můžete to zkusit zjistit sami.
Související články
- Jak funguje Albi tužka
- Jak fungují BNL soubory pro Albi tužku
- Základy zpětného inženýrství
- Hacking a cracking BNL souborů pro Albi tužku – 1. část (právě čtete)
- Hacking a cracking BNL souborů pro Albi tužku – 2. část
- Jak vytvořit vlastní knížku pro Albi tužku
Super, diky za clanek
Dobrý den, pro mě jsou tyto věci těžko pochopitelné, ale chtěla bych zeptat ohledně úpravy tohoto BNL souboru. Dostali se ke mě dvě polské albi knížky a to Kouzelné hodiny a Atlas světa. Kouzelné hodiny jsou totožné jak ty naše české, atlas světa má vše stejné, mimo text a poslední dvoustránka je jiná. Knížky ale nejdou s českým BNL souborem načíst, pouze s polským souborem. Mě by zajímalo, zda je nějak možné změnit v českém BNL souboru pouze tu načítací první část, vyměnit jí za polskou tak aby se kniha načetla ale dál jela v české verzi. Nebo je to nemožné? Děkuji za váš názor
U mně na Githubu je přehled vydaných knih:
Znam godziny mají book_id 0xCA1, Kouzelné hodiny mají 0xBD5, takže nejsou kompatibilní.
TE-O-RE-TI-CKY by mělo stačit přepsat book_id v tomto případě v českém souboru. Buď tedy tak, že se použijí utility bnl_dis.pl, změní se ta hodnota v yaml souboru a pak se použije bnl_creator.pl, nebo přímo hexaeditorem, na offsetu 0x5C v českém souboru zapsat dva bajty 0xA1, 0x0C. Ale nejsem si takhle bez těch knih jist. Tedy, existuje ještě třetí řešení, a to vytisknout si samolepku s OID kódem 0xBD5 a nalepit si ji vedle polského zapínacího tlačítka. Generátor je dostupný na githubu, ale tisk není jednoduchá záležitost.
U Atlasu světa je to podobné, ale liší se dost – český soubor obsahuje méně OIDů, ale více zvuků, takže nevím, zda by to vůbec spolu běželo.
Instrukce jsou podobné, polské book_id je 0x9BD, české je 0x7BA.
Připouštím, že ačkoli jsou v článcích o Albi tužce všechny informace o tom, jak to udělat, že to může být pro méně technické lidi nezvládnutelné, ale věřím, že je vždy v okolí nějaká nešťastná oběť, „která dělá do počítačů“ 😉
https://m.loupak.fun/obrazky/vlastni/49305/
Mockrát děkuji za odpověď, zkusím se na to podívat. Jde mi především o ty hodiny, ty jsou naprosto totožné a dle mě by fungovat mohli. 🙂
Tak jsem to zvládla! Nebylo to tak těžké jak jsem si myslela. Nakonec jsem změnila dle vašeho návodu hodnoty na offsetu 0x5C a nyní mi fungují i hodiny i atlas světa. 🥳 U atlasu jak jsem tušila nefunguje pouze poslední dvoustránka, ta je jiná než naše česká. Ještě jednou vám moc děkuji. Polských atlasů světa mám více a ráda bych vám jeden věnovala jako poděkování. Pokud máte zájem, prosím kontaktuje mě přes email.