Hipoteza: datoteka je šifrirana
1. Odsutnost potpisa kompresije
Relevantni formati kompresije koje Binwalk otkriva su sljedeći: bzip2, lzop, lzip, lrzip, LZO, 7z, gzip, rzip, LZMA , zlib i LZ4. Budući da pokretanje Binwalka protiv H201LV2.0_Cur_config.bin ne daje rezultate, iako će Binwalk normalno prepoznati bilo koji od ovih formata kompresije, prvi je pokazatelj da se događa nešto drugo osim ili pored kompresije.
Međutim, svaki alat ima svoja ograničenja, pa sam pokušao pronaći sekvence bajtova unutar zaglavlja datoteke koje ukazuju na početak niza komprimiranih bajtova ručno koristeći informacije iz posta foruma zenhax.com pod nazivom Kako prepoznati algoritmi kompresije vašim očima, posebno tražeći Bzip2, zlib, gzip, LZMA, LZMA 86 glava, LZMA 86 dec, LZMA 86 dec glava, LZMA efs, LZMA bez zaglavlja, LZMA2 i LZMA2 bez zaglavlja. Evo prvih nekoliko bajtova svakog potpisa kompresije:
- zlib:
78 da - gzip:
1f 8b - LZMA, LZMA 86 glava, LZMA 86 dec, LZMA 86 dec glava, LZMA efs:
5d 00 00 00 - LZMA bez zaglavlja:
00 44 94 a6 - LZMA2:
18 e0 07 ce - LZMA2 bez zaglavlja:
e0 07 ce 02
Informacije o kompresiji u odgovorima na ovo pitanje o SO-u također su bile korisne: Kako otkriti vrstu kompresije koja se koristi u datoteci? (ako nije navedeno proširenje datoteke)
Pod "zaglavljem datoteke", mislim na prvih 300 bajtova ili tako nekako (ovo je pitanje korišteno kao referenca: RE komprimirana sigurnosna kopija datoteka, usmjerivač na Linuxu, pa je li komprimiran sa zlib? budući da je i ovo pitanje, također Vido, uključivao firmware ZTE usmjerivača i pronađen je njegov potpis kompresije). Na žalost, buljenje u heksadecimalni izvadak datoteke nije dalo korisne informacije.
2. Dokazi iz dodatnih izvora
Stranica 3 niti pod nazivom ZTE zxv10 h201 na crnogorskom forumu uključivala je neke relevantne postove, kao i ovu skrivenu programsku skriptu s greškom:
uvoz reimport sysimport zlibimport structime_fajla = 'H201LV2.0_Cur_config.bin'def extract_config_xml (config_bin): config_xml = b' 'za zlib_chunk u re.finditer (' \ x78 \ xda ', config_bin): zlibrt_k.k zlib_chunk_header = config_bin [zlib_chunk_start - 12: zlib_chunk_start] xml_chunk_length, zlib_chunk_length, config_bin_length = \ struct.unpack ( '', >LLL zlib_chunk_header) ako xml_chunk_length == 0x10000 ili config_bin_length == 0: zlib_chunk_end = zlib_chunk_start + zlib_chunk_length zlib_chunk = config_bin [zlib_chunk_start: zlib_chunk_end ] xml_chunk = zlib.decompress (zlib_chunk) potvrditi xml_chunk_length == len (xml_chunk) config_xml + = xml_chunk vratiti config_xmls otvorenim (ime_fajla, 'rb') kao f: ispis ekstrakt_konfig_xml (f.read ()) Popravljeno izgleda ovako:
# decompress.pyimport reimport sysimport zlibimport structfilename = "H201LV2.0_Cur_config .bin "def extract_config_xml (naziv datoteke): config_xml = b '' za zlib_chunk u re.finditer ('\ x78 \ xda', naziv datoteke): zlib_chunk_start, zlib_chunk.start = () zlib_chunk_header = datoteka: zlib_chun_k_z_start_k_k_z_start_k_k_z_start_k_k_z_k_stak , zlib_chunk_length, config_bin_length \ struct.unpack ( '> LLL' zlib_chunk_header) ako xml_chunk_length == 0x10000 ili config_bin_length == 0: zlib_chunk_end = zlib_chunk_start + zlib_chunk_length zlib_chunk = filename [zlib_chunk_start: zlib_chunk_end] xml_chunk = zlib.decompress (zlib_chunk) tvrditi xml_chunk_length == len (xml_chunk) config_xml + = xml_chunk vrati config_xmls otvorenim (naziv datoteke, 'rb') kao f: print extract_config_xml (f.read ())
U ovom slučaju ova skripta ne pomaže, uglavnom zato što traži redoslijed bajtova 78 da , potpis zlib kompresije, koji nije prisutan u datoj datoteci, H201LV2. 0_Cur_config.bin .
Slične datoteke config.bin bile su prilično oskudne i teško ih je pronaći, ali neke su pronađene i istražene. Najzanimljivija i najkorisnija bila je datoteka pod nazivom H201LV2.0.bin , podijeljena putem DropBox. Evo razlike zaglavlja dviju datoteka:
Zanimljivo je da postoji 16-bajtna sekvenca kojoj su zajedničke na offset 0x00003214 (je li to moguće ako su datoteke stvarno šifrirane? Čini se neobično):
Kada Binwalk se pokreće protiv H201LV2.0.bin , slično je i neuspješan:
$ binwalk H201LV2.0.bin DECIMALNI ŠESTAKSIMALNI OPIS --------- -------------------------------------------------- ---------------------
Uz to, postoji još jedan post RE.SE pod naslovom ZTE šifrirana datoteka sigurnosne kopije u vezi sa ZTE sigurnosnim kopijama drugog proizvoda, ZTE Speedport Entry 2i, za koje se također sumnja da su šifrirane. Jedna datoteka config.bin podijeljena na poveznici u komentarima pod ovim pitanjem također ima strukturu zaglavlja sličnu H201LV2.0_Cur_config.bin , ali čini se da je iz starije verzije firmvera . Čini se da drugi imaju poteškoća s istim problemom.
3. Entropija podataka i analiza entropije
Postoji zanimljiv članak o kompresiji i šifriranju na blogu SE superuser. Evo dviju točaka iz teksta:
- Kompresija traži uzorke i zamjenjuje ih manjim tokenima koji predstavljaju te uzorke
- Šifriranje zamračuje podatke idealno stvarajući izlaz s u njemu nema uočljivih obrazaca
Razlikovanje kompresije od enkripcije može se pokušati koristiti statističkim metodama. O tome je u kontekstu analize firmvera raspravljao devttys0 u 2 članka:
Iz prvog članka:
... postoji nekoliko testova koje se mogu izvesti za kvantificiranje slučajnosti podataka. Dvije koje sam smatrao najkorisnijima su hi kvadratna raspodjela i Monte Carlo aproksimacija. Ovi testovi mogu se koristiti za mjerenje slučajnosti podataka i osjetljiviji su na odstupanja u slučajnosti od vizualne analize entropije.
i
Postojeći alati, kao što je ent, izvršit će ove izračune umjesto nas. Pravi je problem kako protumačiti rezultate; koliko su slučajni šifrirani podaci u odnosu na komprimirane? To će ovisiti i o korištenom šifriranju / sažimanju, kao i o veličini vašeg skupa podataka (više podataka općenito znači točnije rezultate). Primjena ovih testova na (doduše malom) uzorku datoteka različite veličine koje su stavljene kroz različite algoritme kompresije / šifriranja pokazale su sljedeće korelacije:
-
Velika odstupanja u hi kvadratnoj raspodjeli , ili veliki postotak pogreške u Monte Carlo aproksimaciji sigurni su znakovi kompresije.
-
Vrlo precizni izračuni pi (< .01% pogreška) sigurni su znakovi šifriranja.
-
Niže vrijednosti chi (< 300) s većom pogreškom pi (> .03%) pokazatelji su kompresije.
-
Veće vrijednosti chi vrijednosti (> 300) s nižim pogreškama pi (< .03%) indikativne su za šifriranje.
Ti se rasponi vrijednosti mogu koristiti kao heuristika u analizi datoteke.
Ovo je rezultat upotrebe Binwalka za provođenje analize entropije H201LV2.0_Cur_config.bin :
$ binwalk -E -J H201LV2.0_Cur_config.bin DECIMALNA ŠESTAKSETNA ENTROPIJA ------------------------------ -------------------------------------------------- 1024 0x400 Rast entropije u porastu (0.972587)
I pomoću ent :
$ ent H201LV2.0_Cur_config.binEntropy = 7,981641 bita po bajtu. Optimalna kompresija smanjila bi veličinu ove datoteke od 19716 bajtova za 0 posto. Raspored Chi kvadrat za 19716 uzoraka iznosi 650,33, a slučajno bi premašio ovu vrijednost manju od 0,01 posto puta. Aritmetička srednja vrijednost bajtova podataka je 126,7613 (127,5 = slučajno). Monte Carlo vrijednost za Pi je 3,133292757 (pogreška 0,26 posto). Koeficijent serijske korelacije je 0,039397 (potpuno neusklađeno = 0,0).
Sadržaj: Prema grafikonu, raspodjela entropije između pomaka bajtova (decimalna) ~ 1000 do ~ 19000 prilično je ujednačena. To se očekuje kod šifriranih podataka:
Šifrirani podaci obično su ravna linija bez varijacija
Hi kvadratna distribucija je 650,33 a pi pogreška je 0,26 . Vrijednost hi kvadrat je ciljana za ono što se očekuje s šifriranim podacima, ali vrijednost pogreške pi je vrlo daleko od cilja, prema devttys0:
Veće vrijednosti chi ( > 300) s nižim pogreškama pi (< .03%) ukazuju na šifriranje.
Dio problema je mala veličina datoteke od ~ 20 KB i mala entropija u zaglavlju datoteke, što znamo da nije šifrirano. Izuzimanje podataka za koje je poznato da nisu šifrirani iz analize povećat će točnost. Izgleda da šifriranje započinje s pomakom 0x00000124 , tako da se python skripta može napisati da preskoči prvih 292 bajta, a ostatak zapiše u pomoćnu datoteku:
#! / usr / lib / pythons otvorenim ("H201LV2.0_Cur_config.bin", "rb") kao ulaznom_datotekom: s otvorenim ("pomoćni_H201LV2.0_Cur_config.bin", "wb") kao izlaznom_datotekom:
output_file.write (input_file.read () [292:])
Sada se analiza može provesti samo na (sumnjivom) šifriranom bloku podataka bez nešifriranog zaglavlja datoteke:
$ binwalk -E -J pomoćni_H201LV2.0_Cur_config.bin DECIMALNA ŠESTAKSETNA ENTROPIJA ------------------------------- ------------------------------------------------ 0 0x0 Rast entropije u porastu (0.973372)
S ent :
$ ent auxiliary_H201LV2.0_Cur_config.binEntropy = 7.990521 bita po bajtu. Optimalna kompresija smanjila bi veličinu ove datoteke od 19424 bajta za 0 posto. Raspored Chi kvadrat za 19424 uzorka iznosi 256,03, a nasumično bi premašio ovu vrijednost 47,01 posto od puta.Aritmetička srednja vrijednost bajtova podataka iznosi 128,0505 (127,5 = slučajno) .Monte Carlo vrijednost za Pi iznosi 3,143651529 (pogreška 0,07 posto). Koeficijent serijske korelacije je 0,011183 (potpuno neusklađen = 0,0).
Ovi su rezultati zanimljivi: graf pokazuje približno jednoliku entropiju u cijeloj datoteci, ali sada su hi kvadratna distribucija ( 256,03 ) i pogreška aproksimacije pi ( 0,07% ) i u granicama onoga što se očekuje za komprimirane podatke!
Niže vrijednosti chi (< 300) s većom pi pogreškom (> .03%) pokazatelji su kompresije.
Uz to, ove nove vrijednosti relativno su blizu svojih rubnih uvjeta. Odnosno, 256,03 je relativno blizu graničnog stanja od 300 za hi kvadratnu raspodjelu, a 0,07% je relativno blizu graničnog uvjeta od 0,03% za pogrešku aproksimacije pi, pa je teško sa sigurnošću reći da je datoteka stvarno šifrirana ili ako se komprimira na temelju ovoga.
Zaključak
Dokazi koji potkrepljuju hipotezu da je datoteka šifrirana zbunjuju su neki od rezultata analize entropije. Stoga ću se usuditi da je datoteka šifrirana, ali to ne mogu dokazati pomoću ovdje opisanih metoda.
Nadam se da će se ovi nalazi (ili njihov nedostatak) pokazati korisnima drugima koji provode vlastitu istragu ove datoteke. . Možda će stručnjak moći definitivno odgovoriti na ovo zanimljivo pitanje.
Prijedlozi, drugi putovi
Imate li prijedlog što da pokušam?
1. Stroža statistička analiza
Analiza entropije, iako korisna, nije dovoljna; treba upotrijebiti dodatne statističke metode:
Entropija informacija često se koristi kao preliminarni test slučajnosti. Općenito govoreći, slučajni podaci imat će visoku razinu informacijske entropije, a niska razina informacijske entropije dobar je pokazatelj da podaci nisu slučajni. (Niska razina entropije nije konačni dokaz da podaci nisu slučajni, ali to znači da biste trebali biti razboriti i predati generator daljnjim ispitivanjima.)
Međutim, obratna veza ne držite, što znači da visok stupanj entropije informacija nije jamstvo slučajnosti. Na primjer, komprimirana datoteka (npr. ZIP datoteka) ima visoku razinu entropije informacija, ali je zapravo visoko strukturirana i neće uspjeti na mnogim drugim testovima slučajnosti. Stoga morate biti malo pažljiviji koristeći se entropijom podataka kao metrikom slučajnosti. Da biste dobili značajne rezultate, stvarno ih trebate kombinirati s drugim testovima.
2. Oporavak modula za šifriranje
Ova spekulacija u odgovoru na ZTE šifriranu datoteku za konfiguraciju sigurnosne kopije može pružiti put istrage:
Pretpostavljam da je osnovna funkcionalnost za izvršavanje šifriranja jednaka na svim ZTE reuterima (uobičajeni config.bin to predlaže), pa zamislite da je to samo slučaj otkrivanja metode i koji se ključevi / iv koriste za dešifriranje opet ...
Ako se pronađe modul u firmware-u odgovoran za izvođenje šifriranja, algoritam šifriranja može se obratno inženjerirati. Mislim da je za to potreban pristup uređaju, s obzirom na to da nema lako dostupnih slika firmvera ZTE usmjerivača.
3. Analiza šifrenog teksta
Nešto čime se nisam bavio bila je analiza (sumnjivog) šifreteksta s alatima poput bfcrypt ili FindCrypt kako bih utvrdio algoritam šifriranja koji se koristi za šifriranje datoteke. Popis više alata možete pronaći na fwhacking.blogspot.com.br.
Kad smo već kod analize šifriranog teksta, mislim da je ovo pitanje na Security.SE bilo zanimljivo: Kako utvrditi koja je vrsta kodiranja / šifriranja korištena?, posebno odgovor.
brzo ažuriranje:
ove su biblioteke šifriranja dinamički povezane s binarnim cspd MIPS ELF:
$ readelf --dyn-syms cspd | grep AES 484: 0053ab50 1248 FUNC GLOBAL DEFAULT 8 AES_set_encrypt_key 630: 0053b9d0 1600 FUNC GLOBAL DEFAULT 8 AES_decrypt 1187: 0050d470 552 FUNC GLOBAL DEFAULT 8 DecryByAES 1527: 0053b390CEN ALEX 8CEN ALEBONEC 8OB FSC >
kao i ove biblioteke kompresije:
$ readelf --dyn-syms cspd | grep oblog 92: 0053c110 208 FUNC GLOBAL DEFAULT 8 raspakiranje 1064: 0053c010 216 FUNC GLOBAL DEFAULT 8 compress2
raspakiranje i compress2 povezani su s zlib.