érdekes packetek, mik ezek? encrypted? (tcp_dumpból)

Üdv!

Elkaptam pár érdekes packetet, amit vissza kéne valahogy fejtenem.

A felállás a következő:
Adott egy kliensprogram (win-es, wine alatt). Ez xy szerverrel z porton kommunikál. (Ha lehet az adott programot nem nevezem meg, magyar gyártmány, zárt forrás...)

Tcp-dump-pal elfogtam a kommunikációt. Ennek egy jó része sima plaintext, elsősorban, amit a kliens küld a szervernek. A szerver válaszainak is egy jó része plaintext, gyakorlatilag ezzel mennek a parancsok.

Ami számomra érdekes az maga az adat. Azt hogy milyen szerkezetben van, nem tudom, lehet akár xls is... Elsősorban táblázatszerű vagy xml adatokra számítok, vagy egy következő struktúrára: "]::[kulcs]::[érték]::[" (plaintext packetek alapján)
Az elkapott file-ok / packetek (a nem plaintextek) itt találhatóak: http://ebyte.hu/jan/fls.tar.gz

Alapvetően valami crypt-re gondoltam, de gondosabban megnézegetve a file-okat ehhez túlzottan egységes a fejlécük.
Neten se kliensre, se szerverre, se header hexekre se header format/size-ra nem találtam közelítőleg passzoló tippet se. Próbálkoztam már bit-es xor vagy shift műveletekkel, de nem jött össze semmi. (Mondjuk, csak egy bitre próbálkoztam, azon kiindulva hogy az első 4 byte az adat hosszát hivatott jelölni...) Próbáltam még a tömörítőket is, de se zip se gz nem segített (tudom, van még pár, de csak ezek voltak hirtelen kézenfekvők...)

Így aztán hozzátok fordulok, hátha találkoztatok már hasonló formattal vagy file-okkal.

Továbbá gondolkoztam, hogy esetleg megoldható-e az adott kliens megfelelő részének assembly visszafejtése (pláne, ha valami egyszerűbb megoldásról van szó), de mivel ilyet még nem csináltam, valszeg nem erőltetném...

A packetek visszafejtése egyébként nem lét kérdés, csak k*va macerás a napi (akár többszöri) >>megnyit->bejelentkezik->adatok letöltése xls-be->xls export cvs-be(open office)->cvs feltöltés szerverre(konzol->mc->ftp)->szerver frissítési script indít<< folyamat, szóval sokat segítene az esti lelki állapotomnak...

Remélem tudtok valamit mondani, legalább hogy adjam fel...

Hozzászólások

Hát szerintem nagyban segítene, ha elárulnád a program nevét, hátha valaki kisujjból kirázná, mi is ez.
Tipp: valami archive formátum splittelve? Minden fájl elején van némi közös bitérték, ami "hasonlít" (nagyon idézőjelben) ehhez. De ez csak szigorúan sötétben tapogatózós tipp.

Nem hiszem hogy splittelt, mert egy-egy packet egy kérésre válaszol. Sajna adott darab tartalmáról lövésem sincs. Valszeg a progi saját protokoljának elemei, de hogy micélból mi az már jó kérdés...

Lásd lentebbi hsz-t.

---
"Féljetek tőlem, vagy tiszteljetek, de könyörgök, higgyétek el hogy különleges vagyok. A függőségünk közös: elismerésfüggők vagyunk." /Ritchie/

Ez a téma így körülbelül ugyanolyan, mint a klasszikus "hány éves a kapitány?" kérdéskör. Semmi egyebet nem tudunk, minthogy a tarban lévő file-ok valamilyen adatok, és a hálózaton jelentek meg. De ezek az fl* file-ok milyen fileformátumban vannak, vagy a csomagok mely részét tartalmazzák, egyáltalán milyen típusú adat lenne ebben, vagy valami apró támpont...
Azt írod, tcpdumpból származik. De ez nem pcap:

# file fl*
fl:  data
fl2: data
fl3: data
fl4: data
fl5: data

Viszont inkább az adott problémát kellene megoldani, nem újat generálni.

"macerás a [...] >>megnyit->bejelentkezik->adatok letöltése xls-be->xls export cvs-be(open office)->cvs feltöltés szerverre(konzol->mc->ftp)->szerver frissítési script indít<< folyamat"
Csak erről van szó? Ez nem tűnik annyira bonyolultnak, hogy ehhez ismeretlen típusú hálózati forgalmat kelljen analizálni.

.xls -> cvs-be: xls2csv (97-2003 biztosan megy vele; az .xlsx-hez pedig valamilyen xml segédeszköz, például egy néhánysoros perl script)

CSV -> FTP szerver: ftp (nem, nem mc, hanem az ősi parancssoros ftp, vagy újabb hasonló társai)

script indítása: nem írtad a rendszert, de pl. cron, ssh stb.

És ha valamiért ezek bonyolultak lennének, még tartalékban ott lehet egy billentyűzet-egér makrorögzítő és -visszajátszó alkalmazás. Ebből is van választék.

"Adok egy támpontot: bináris!"
Köszönöm, de azt hiszem, nem értetted meg a kérdés lényegét, ami arra vonatkozott, hogy ez tisztán a legbelső ismert protokoll payloadja (azaz a megfejtendő adat), vagy pedig nem. Persze ha sok ideje van az embernek, játszhat manuális WireSharkot, és megnézheti, hogy az eleje egy általa ránézésre felismerhető protokollfejléc-e. Mindegy, most már tudom, hogy ez a puszta adat.

"pont ez a kérdése, hogy mik is lehetnek ezek"
Szerintem közülünk viszonylag kevesen foglalkoznak ismeretlen típusú adatok visszafejtésével, így többségünknek legalább arra az információra lenne szüksége a kérdezőtől, hogy mégis milyen adatok mászkálnak itt. És ezt csak a kérdező tudhatja jelenleg, mivel csak ő tudja, hogy milyen program által generált forgalom ez, és ez a program milyen adatokkal dolgozik.
Mivel nem mindegy, hogy 20 szám van ebben elrejtve, és ezek ábrázolását és sorrendjét kellene megfejteni, vagy pedig kitudja mennyi és milyen adatok bytehalmazából kellene ismeretlen cél alapján kihámozni valamit a sötétben tapogatózva. Megjegyzem, a másik hozzászólásodban ugyanerre kérdeztél rá más szavakkal. Túlragoztuk, csak egy egyszerű, de fontosnak vélt kérdés volt.

"hogyan lehetne őket értelmes formába önteni"
Erre próbáltam azt javasolni, hogy ne a kódfejtés irányába mozduljunk el, hanem meglévő eszközök alkalmazásával minimalizáljuk a rendszeres és érthetően egy idő után unalmassá váló humán munkaigényt. És nekem egyszerűbbnek tűnik ezen az úton haladni, mint olyan rejtvényt fejteni, ahol még a kérdést sem ismerjük.

Először is kösz, hogy egyáltalán vettétek a fáradságot hogy belenézzetek a fájlokba és írjatok! :)

Részletezett infók itt vannak: http://ebyte.hu/jan/leiras.utf8.txt

A makrórögzítős megoldás: annyira nem "elegáns", hogy akkor inkább majd kézzel vagy társammal megcsináltatom. Sokkal inkább az a problem, hogy se helyi se pesti szerveren semmilyen X vagy wine nincs, és nincs is tervben. Az asztali gépem pedig nincs 7/24-ben, pláne hétvégén. Külön ezért WOL és shutdown pedig... Nem a régi "The Impossible Machine"-t akarom utánozni :D

És ha más nem, már csak az a napi pár perc és watt spórolás (:p), és főleg a tudat, hogy ezt is meg lehetett oldani megéri (szerintem) a szenvedést a visszafejtésre. :D

A probléma továbbra is ilyen egyszerű: ismerős-e valakinek a fent bemutatott formátum? :D Tudtok-e tippet, hol keresgéljek ha vissza akarom fejteni? Megoldható-e egyáltalán értelmes energiaráfordítással?

---
"Féljetek tőlem, vagy tiszteljetek, de könyörgök, higgyétek el hogy különleges vagyok. A függőségünk közös: elismerésfüggők vagyunk." /Ritchie/

az adott kimenet egyértelműen vagy valami tömörített (ez a valószínűbb) vagy valami jófajta titkosítás lesz (statisztikai rendszert írtam a file-ra, de nincs benne olyan ismétlődés ami alapján bármire is rá lehetne jönni).
Amit tehetsz és segítene is a célig való eljutásban: nézd meg a programot milyen libeket, egyéb függőségeket húz be, esetleg marad a hex editor és az exe végén szétnézni, hátha nem vették ki a függvény neveket és a referenciáikat. Ha valami tömörítési megoldás és benne maradtak ezek az adatok, akkor jó esély van arra, hogy meglesz a megfejtés is
-szerk- Eddig? nem gzip, nem lzg és nem bz2;)

Szerintem, ha a parancsok nincsenek titkositva, akkor az adat sem lesz, nem bajlodnanak vele. Es ilyen kis adatoknal tomoriteni sem eri meg. Valoszinubbnek tartanam, hogy az elso ket byte az adat hosszat adja meg, a tobbi pedig egyszeru integer vagy float tomb.
A masodik byte egyedul a hosszu filenal nem nulla, de a harmadik negyedik byte mindig az. Ugy remlik, hogzy a tcp-nel mindig a magasabb byte van hatul, de igy sem stimmelnek a filehosszak az elso ket byte altal kiadott szammal.

Kicsit belenéztem az exébe (Delphi-ben csinálták, DeDével elég sok kiderült).
Egy-egy binarycompress és binarydecompress method van benne, azok végzik a csomagolást. Mindkettő 1-1 soros függvény, és a 'TLZH' classra hivatkozik, ami pedig (elvileg) delphiben beépített könyvtár...
Ha lesz majd időm, megpróbálom kicsit visszafejteni az asm adatokat (mert lehet jelszavas tömörítés... bár stringet csak kitömörítésnél láttam betömörítésnél nem), és megnézegetem a delphi lehetőségeit is.

A headerben első 4 byte minden valószínűséggel packet sizeot jelöl LE-vel (gondolom a decompressed méret), de ahogy nézegettem lzh-ra (lha) valahogy sehogyse stimmel a header szerkezet.
Másik, hogy stream data tömörítése és nem file-é, szóval ennyivel is változhat a szerkezet...

Ha még rájövök valamire majd megosztom :D

---
"Féljetek tőlem, vagy tiszteljetek, de könyörgök, higgyétek el hogy különleges vagyok. A függőségünk közös: elismerésfüggők vagyunk." /Ritchie/

Most talán jól meg hajigáltok kaviccsal, de akkor is kimondom:
Nem lehetne a programot gyártó cégtől segítséget, tanácsot kérni?
Mert még ha meg is haxolod a protokolt, nem fogsz licencet sérteni?
Abból kiindulva, hogy az adatforgalom egy része bináris (ami akár firebird db is lehet), a felhasználónév/jelszó, meg plaintext, titkosítás nélkül, nekem úgy tűnik valami egészen egzotikus öszvér megoldás lesz ez a protokol, amit vissza fejteni nem lesz egy sétagalopp.

Ja a segítség kérést, valamely céges formában intézd, úgy nyomatékosabb és talán gyorsabb lesz.

----
概略情報
http://molnaristvan.eu/

Gyártó céggel nagy valószínűséggel (99.9% prop.) nem érek el semmit.
Csak saját felhasználásra megy a cumó. Nincs sehol jelezve náluk, hogy licensz védené a kliens által használt adatcsatornát vagy akár a klienst... (Ingyenesen letölthető, használható szoftver, amit csak azért csináltak, hogy a fizetős szoftvereiket valaki végre használja is.)

És igen, ez egy érdekes része: felhasználó nevet / jelszót / ügyféladatot mindek védeni, de verziószámot "titkosítani" kell. Valszeg ez is csak egy .net-be (vagy amivel csinálták) vagy használt lib-jeikbe alapból benne levő funkció, amit a kliens megírásakor nem nagyon figyeltek, de a szerver oldalról "véletlenül" becsúszott, lib részéről meg transzparens, szóval észre se veszik...

FirebirdDB mondjuk megér egy kört utánanézni.

---
"Féljetek tőlem, vagy tiszteljetek, de könyörgök, higgyétek el hogy különleges vagyok. A függőségünk közös: elismerésfüggők vagyunk." /Ritchie/