Pitanje:
Utvrdite kompresiju ove konfiguracijske datoteke sigurnosne kopije ZTE ZXV10 H201L V2
Vido
2017-02-22 05:22:23 UTC
view on stackexchange narkive permalink

Ova datoteka config.bin je iz ZTE usmjerivača. Želio bih ga dekomprimirati, ali nisam prepoznao kompresiju koja se koristi u datoteci. Možda netko može.

  00000000 99 99 99 99 44 44 44 44 55 55 55 55 aa aa aa aa | .... DDDDUUUU .... | 00000010 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 | ................ | 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ..... ........... | 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 | ............... @ | 00000040 00 02 00 00 00 00 00 80 00 00 4c 84 00 00 00 00 | .......... L ..... | 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ | * 00000080 04 03 02 01 00 00 00 00 00 00 00 10 5a 58 56 31 | ............ ZXV1 | 00000090 30 20 48 32 30 31 4c 20 56 32 2e 30 01 02 03 04 | 0 H201L V2.0 .... | 000000a0 00 00 00 02 00 00 00 00 00 00 4c 68 00 01 00 00 | .... ...... Lh .... | 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ | * 000000d0 00 00 00 00 00 00 00 00 00 00 4c 20 00 00 4c 20 | .......... L ..L | 000000e0 00 00 00 00 5d a2 a4 6e d6 94 bc 97 07 1b 38 17 |. ...] .. n ...... 8. | 000000f0 ab 66 e7 bc f4 9b 4 e 3f cd 89 b0 c3 b2 11 4a f4 | .f .... N? ...... J. | 00000100 40 88 2c a1 90 e4 4d 32 d7 9b fa bd ec 39 42 ae | @.,. ..M2 ..... 9B. | 00000110 e6 a9 2f 26 03 6e 70 f4 e5 0f 88 55 3b 1c b0 bb | ../ &.np .... U; ... | 00000120 b6 04 3e 73 99 15 ef 65 39 8d 85 52 6e 37 0b 5d | ..>s ... e9..Rn7.] | 00000130 6e c2 39 75 a4 94 0c c7 79 72 86 dc 25 38 38 e0 | n.9u ... .god ..% 88. | 00000140 8f 54 5b 18 a4 76 15 e4 f7 b3 c6 0f d8 91 19 e0 | .T [.. v .......... | 00000150 00 22 1d 9c 7d a0 08 42 6f 87 ab 73 4b 17 4c 25 |. "..} .. Bo..sK.L% | 00000160 40 2f ea 30 6b 80 27 72 db 2b 30 7a 2a 2f 3d b0 |@/.0k. ' r. + 0z * / =. | 00000170 46 ca 50 0e ad 99 9a 70 3e 23 b4 b4 e0 ee 3a b3 | FP ... p> # ....:. | 00000180 a8 6a 9d 7c a2 29 17 51 9f 7a 0a 14 90 41 3f e2 | .j. |.). Qz..A?. | 00000190 dc 63 52 c8 01 24 6b 46 31 ac 4e c6 54 cb 18 70 | .cR .. $ kF1.NT.p |
000001a0 33 67 0c 06 7e db 00 od 22 ec a1 37 98 01 ef ae | 3g .. ~ ... ".. 7 .... | 000001b0 9b 47 30 48 e3 6d 18 87 ab 34 2d 2b 4e b9 5b eb | .G0H.m ... 4- + N. [. | 000001c0 55 5f 61 ab da eb 39 7e df 7e 79 fe fd f8 11 66 | U_a ... 9 ~. ~ y .... f | 000001d0 b3 48 fc f8 33 38 fd 1b 1d 00 bd 83 f8 b8 2b 9f | .H..38 ........ +. | 000001e0 cf 1e ae 69 ff 5d e3 04 8c 6d cc 19 12 f4 95 03 | ... i.] ... m ...... | 000001f0 3d c8 67 e2 c2 52 d3 a4 44 eb af f5 a0 63 0a ef | = .g..R..D .... c .. | 00000200 d2 3d 82 9e 95 d1 f4 1c ce 0c 5f 60 49 ab c3 d5 |. = ........_ ʻI ... | 00000210 89 d5 53 82 f7 4e ba ae d3 3c 09 e9 od 52 29 e9 | ..S..N ... < ... R). | 00000220 d5 9b 02 54 91 e9 ae 0e 12 26 3b ca ca 4e 8f 01 | ... T .... .&; .. N .. | 00000230 a4 52 e1 4e f8 42 7e 0d 9c 99 76 7d 5f 3c de 67 | .RNB ~ ... v} _<.g | 00000240 82 fc 38 97 7b db 06 b3 0a 44 95 64 ab 02 71 1a | ..8. {.... Dd.q. | 00000250 08 cc ca 88 f8 b6 bb 12 d4 fd 4d dd 9b 3f c1 57 | .......... M ..?. W | 00000260 bb 54 9c b7 99 c3 9c 69 86 91 ea 82 b7 38 b3 c1 | .T ..... i ..... 8 .. | 00000270 f3 71 30 b7 06 82 ea c3 04 93 30 d4 83 56 50 b5 | .q0 ... .... 0..VP. | 00000280 93 39 7a ea a7 1b 38 f0 3a f0 95 57 cb 79 e2 91 | .9z ... 8.: .. Wy. |  

Evo datoteke

UREDI: Promijenio sam lozinku za wifi na usmjerivaču i sigurnosno je kopirao, a na donjoj slici je razlika.

enter image description here

EDIT2: Pri pomaku 0xE4 započinje prvo zaglavlje završava pri odmaku 0x105, čini se da podaci ovog zaglavlja počinju od 0x134?

EDIT3: Uključeno moj usmjerivač ZTEZXV10 H201L V2 postoji uslužni program koji je zadužen za db dackup (zove se cspd) i evo ga pa možda netko može "vidjeti" kako je sigurnosna kopija šifrirana: DBbackupXML

A ovdje je dbFileSave . Ne znam tko je odgovoran za spremanje datoteke. enter image description here Imate li prijedloga što bih trebao probati?

Nadam se da je vaš Tajvanac dobar (pogledajte odjeljak za komentare) http://blog.leexiaolan.tk/pwn-huawei-hg8120c-ont-upgrade-pack-format-part-3
Tnx @Nordwald Jesam je pročitao, ali nisu rekli podudaranje o samoj sigurnosnoj kopiji
Pokušao sam binwalk, signrch, quickbms, offzip, ali bez sreće
Bok. Nisam zapravo upoznat sa firmware-om usmjerivača, ali samo zbog interesa: o kakvoj je datoteci riječ? (npr. postavke ili bilo što drugo)
Da, ispravne su sigurnosne kopije postavki usmjerivača
čini se da nije komprimiran, već samo šifriran / zamućen.
Bi li pomogao deponij mtd0 (cijela bljeskalica) sličnog zte uređaja?
Bok, Milane, ne razumijem što bi "odbacilo", možeš li objasniti i napisati naziv svog zte uređaja
četiri odgovori:
#1
+14
julian
2017-03-01 15:45:39 UTC
view on stackexchange narkive permalink

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:

diff

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):

diff 2

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)  

entropy 1

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)  

aux entropy

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.

Dakle, sugerirate taj mybe / vjerojatno AES_encrypt-ed?
Još istražujem. Brojne su funkcije u cspd binarnom ELF-u koje su povezane sa spremanjem db datoteka ili šifriranjem. Pokušavam pronaći vezu između njih ako postoji. Šifriranje AES-om čini se vjerojatnim, ali još nisam pronašao u kojem se trenutku odvija šifriranje konfiguracijske datoteke
Will done @SYS_V ovdje je funkcija AES_set_encrypt_key http://www.upslike.net/image/5853W
Kako ste iz usmjerivača preuzeli datoteke config.bin i cspd? Zapisuje li ih usmjerivač na USB stick?
Ne, ne piše ih na usb, omogućio sam ftp i kopirao ih na / mnt / putem telneta i preuzeo putem web preglednika
#2
+8
user20993
2017-07-25 19:25:09 UTC
view on stackexchange narkive permalink

Kodiranje za nedavne ZTE usmjerivače config.bin je AES ECB (Elektronička knjiga kodova). Ključ je pohranjen na otvorenom u / bin / cspd pored niza /cfg/db_backup_cfg.xml . Odgovorna funkcija je CspDBInitPdtInterface , zadnji snprintf poziv. Ključ je podstavljen na nulu ako nema 128 bita.

Ključ je možda jedinstven za ISP: vaš H201L V2 je Renjx% 2 $ CjM , Hyster H298N V1.4 bio je Wj% 2 $ CjM (ali ne radi), lokalni H118N V2.3 imao je [email protected]%qJZf.

https://jsfiddle.net/dpc2o6kf/

Tnx @user20993 za dijeljenje, ali ta skripta kod mene ne radi, kaže loša magija. Ne znam što nije u redu?
`loša magija` znači da ne prepoznaje` 01 02 03 04` na 0x9c u vašoj datoteci (pogledajte hexdump). IDK zašto ste pogriješili, Chrome 48 donio mi je lijepi XML iz [vaše datoteke] (https://mega.nz/#!wVg1gJKQ!PGZaqaaeKanYqxFtNw5FNsmh_R5UR75Nr0rC8MihJJ0). BTW, trebali biste maknuti datoteku što prije jer sadrži osjetljive informacije! > _ <
Zašto dobivam drugačiju binarnu datoteku prilikom šifriranja db_user_cfg.xml s openssl enc -aes-128-ecb -nosalt?
Upravo sam naletio na [ovu] (https://pastebin.com/tS1ZiDH3) skriptu u kojoj je ključ za H298N naveden kao `Wj`, a ne` Wj% 2 $ CjM` zbog greške
#3
+2
user33502
2020-06-09 23:46:03 UTC
view on stackexchange narkive permalink

je naišao na ove ključeve i dijeljenje

Poznati AES ključevi:

  zxhn h118n ert5 - 'MIK @ 0STzKpB% qJZe' zxhn h118n V2.1.3_ROSCNT? - 'MIK @ 0STzKpB% qJZf' zxhn h168n v3 - '402c38de39bed665' zxhn h298n hv17_fv116_mts? T1 - 'Wj' (zbog buga, izvor je 'Wj% 2 $ CjM') zxhn h298a hw1.1.20_f.wf.1.20 - '' M8 96&ZG3Nm7N&Iz' zxhn h108n hw1.2_fw2.5.4_eg1t8_ted, zxhn h108n hv11_fv2_5_4_ * -' GrWM2Hz&LTvz&f ^ 5'zxhn h168n hv10_fv310t3_belt - 'GrWM3Hz&LTvz&f ^ 9' zxhn h208n hv10_fv1010_belt16t1 - 'Renjx% 2 $ CjM' zxhn h267n hv10_fv100t3_belt - " tHG @ Ti&GVh @ ql3XN ' 
#4
  0
Vido
2017-03-02 00:25:53 UTC
view on stackexchange narkive permalink

Na mojem usmjerivaču ZTEZXV10 H201L V2 postoji uslužni program koji naplaćuje db dackup i unajmljuje ga, možda netko može "vidjeti" kako šifriraju sigurnosno kopiranje

DBXMLSAVE

Hvala što ste podijelili ove informacije. Možete li to staviti u pitanje? Na taj će ga način svi odmah vidjeti, umjesto da se moraju pomicati do dna mog vrlo dugog posta da bi ga vidjeli
Ovdje sam također objavio sliku funkcije dbcCfgFileDecry
Zanimljiva je i funkcija `šifriranja`. Možete li postaviti novo pitanje s pitanjem kako dešifrirati datoteku config.bin i uključiti `cspd` ELF binarnu datoteku kao i informacije o zanimljivim funkcijama u njoj? Ovdje se radilo o identificiranju kodiranja `config.bin`, pa bi možda bilo dobro imati novo pitanje samo o procesu šifriranja / dešifriranja u` cspd`
Da, mogu, hvala vam što ste pomogli @SYS_V
Nema na čemu. Uživao sam. Puno sam naučio pokušavajući odgovoriti na vaše pitanje pa bih možda i vama trebao zahvaliti.


Ova pitanja su automatski prevedena s engleskog jezika.Izvorni sadržaj dostupan je na stackexchange-u, što zahvaljujemo na cc by-sa 3.0 licenci pod kojom se distribuira.
Loading...