file + hash maar algoritme onbekend..

[sharkzor]

Ik denk dat dit het meest relevante forum hiervoor is.

Ik heb een bestand met daarbij een onbekende hash/crc van 32bits in lengte. maar ik weet niet welk algoritme erbij hoort.
Ik heb al verschillende tools op het bestand losgelaten om te kijken of ik dezelfde hash/crc of wat dan ook eruit krijg, maar geen resultaat.
heeft iemand misschien een idee hoe ik hierachter ga komen?

[writser]

Gewoon veel proberen. Andere manier gaat je niet lukken imho. Hier een lijstje met de meestgebruikte algoritmes: http://en.wikipedia.org/wiki/List_of_hash_functions .

[ATS]

Errr... vragen aan degene waar je je file vandaan hebt?

[Hydra]

Als het 32 bits is, is het hoogstwaarschijnlijk CRC-32 of Adler. Heb je die al gechecked?

[Verwijderd]

32-bits, dus de hash is slechts 4 bytes? bijna zeker dat het CRC-32 is.

of bedoel je 32 bytes? zitten er ook hex getallen in? dus alleen nummers en A t/m F dus geen G of andere letter. dan is de hash dus 16 bytes binair en dus 128-bit lang.

de enige hash algorithmes die 128-bit lang zijn zijn: Haval, MD2, MD4 en MD5. MD5 heb je waarschijnlijk al uitgeprobeerd, MD4 wordt nog gebruikt op het Edonkey netwerk en MD2 is zogoed als uitgestorven. Haval ken ik zo niet.

andere oorzaak zou kunnen zijn dat als het een tekst bestand is dat elke \n vervangen is voor een \r\n. FTP doet dit bijvoorbeeld als het bestand als ASCII wordt overgedragen. de hash klopt dan niet meer en dus moet je elke \r\n weer vervangen voor \n.

maarja, dat blijft zoeken in het duister. waar heb je het bestand vandaan?

[leuk_he]

Google eens naar "hash calculator" Dan vind je diverse tools die een rij popularish hash methoden ondersteunen.

[sharkzor]

het is een .exe bestand en daar hoort bijvoorbeeld zo'n checksum bij 982eb047.
hier word op gecontrolleerd door een programma. Het is niet voor hackers praktijken, maar voor een onderzoekje wat ik aan het doen ben.

alle hash calculators heb ik al geprobeerd. het is niet crc32 en ook niet adler.

[Verwijderd]

982eb047 is waarschijnlijk hex, dus 8bytes = 4bytes binary = 32bit inderdaad.

heb je al gekeken of de grote klopt ofzo. er hoeft maar 1 extra byte aan die exe te zijn toegevoeg door een of ander programma waardoor die hash/crc al niet meer klopt natuurlijk. ik weet niet hoe groot het bestand is maar je zou het eens in notepad kunnen openen en kijken of je wat raars tegenkomt. een header of zeer grote stukken die gewoon leeg zijn bijvoorbeeld.

desnoods kun je een rainbow tabel gebruiken, wie weet zit er een match in.

[leuk_he]

dus hash (.exe programma) wordt 982eb047 en die wordt gecontroleerd dor een ander programma? of door zichzlef? Als het door zichzelf wordt gecontroleerd dan kan hij niet de hele exe file inlezen,tenzij de hash in een extern bestand zit.

Als het een soort van licentiecode/firmware check is dan wordt behalve de .exe waarschijnlijk nog iets anders in de hash gestopt (b.v. datum of aantal gebruikers)

aangezien de mogelijkheden hiervoor heel groot zijn zul je waarschijnlijk het programma dat de hash genereert/checkt moeten reverse engineeren?

[Hydra]

Iets meer info over wat je probeert te bewerkstelligen zou handig zijn

[Verwijderd]

dat een programma zijn eigen .exe niet zou kunnen hashen is natuurlijk bullshit. het is gewoon een bestand. een reeks bytes die op dat moment welliswaar in gebruik zijn en dus niet kunnen worden gewijzigd, maar inlezen gaat wel hoor. gewoon openen in read-only modus en niks aan de hand.

ik ben eigenlijk vooral benieuwd naar hoe het bestand is vervoert? welke programma's heb je gebruikt om tot deze .exe te komen. elk kunnen ze namelijk een subtiel verschill hebben gemaakt. maak bijvoorbeeld maar eens een md5checksum van een bestand. upload het met FTP in text of ASCII modus en check de hash nogmaar een keer. bijna zeker dat je een andere hash krijgt terwijl het bestand zelf verder goed kan functioneeren. veel executable's doen niet moeilijk over wat new-line bytes aan het eind van het programma maar voor je hash is het een wereld van verschil.

dit wordt inderdaad zoeken naar een comeet in de melkweg zonder iets meer te weten over de oorsprong van het bestand en de hash. waar komt het vandaan en wie hebben er aan gezeten?

[sharkzor]

ok, excuses.
ik doe een onderzoekje naar de veiligheid van update mechanismen en ben voor de grap ook eens naar de updater van command & conquer 3 gaan kijken.
Dit blijkt heel simpel inelkaar te zitten. Via http doet hij een request naar een server waarvan hij een simpele plain text lijst terug krijgt.

Dit haal ik dus met wireshark op:

code:

GET /servserv/cnc3/cnc3_english_1.4.patchinfo?value=d92c40 HTTP/1.1
User-Agent: ea_rts_launcher
Host: servserv.generals.ea.com
Cache-Control: no-cache
Cookie: com.pogo.unid=6456937868733571


HTTP/1.1 200 OK
Date: Mon, 11 Jun 2007 17:22:53 GMT
Server: Apache/1.3.26 (Unix)
Last-Modified: Thu, 07 Jun 2007 16:42:21 GMT
ETag: "3a273-1f0e-4668356d"
Accept-Ranges: bytes
Content-Length: 7950
Content-Type: text/plain

ftp://ftp.ea.com/pub/eapacific/cnc3/patch15

patch_self |  | | | 

run | patchprepare.exe |     99856 | 982eb047 | 

local_copy | RetailExe\1.0\config.txt | | | RetailExe\1.5\config.txt

local_copy | RetailExe\1.0\dbghelp.dll | | | RetailExe\1.5\dbghelp.dll

local_copy | RetailExe\1.0\Data\Cursors\Beam.ani | | | RetailExe\1.5\Data\Cursors\Beam.ani

local_copy | RetailExe\1.0\Data\Cursors\ForceAttackMove.ani | | | RetailExe\1.5\Data\Cursors\ForceAttackMove.ani

local_copy | RetailExe\1.0\Data\Cursors\SCCAttackMove.ani | | | RetailExe\1.5\Data\Cursors\SCCAttackMove.ani

local_copy | RetailExe\1.0\Data\Cursors\SCCAttackNew.ani | | | RetailExe\1.5\Data\Cursors\SCCAttackNew.ani

<en nog meer tettie>

local_copy | CNC3_english_1.0.SkuDef | | | CNC3_english_1.5.SkuDef

patch | SKUDEFS-ENGLISH-1_5.RTP |      1873 | 068d2ba3 | 

run | patchupdate.exe |     98304 | a9a31a47 | 

*

Zoals je ziet staat er gewoon een ftp site in waar hij het vandaan kan halen + per bestand filesize en over de .exe files nog een soort hash. De filesize word met het FTP commando SIZE gecontrolleerd, dus das simpel.

Ik wil dus door DNS spoofing die updater naar mijn eigen server laten wijzen waardoor hij dus spullen van mijn ftp server afhaalt. Dat heb ik al voorelkaar, alleen nu wil ik mn eigen .exe laten ophalen + uitvoeren. Alleen moet je daarvoor dus een hash berekenen.. zou niet weten hoe ze dat doen. Maar als ik dit mechanisme zo bekijk, kan dat nooit moeilijk zijn.

Voor de volledigheid, ik kan c&c3 nu al vanaf mijn eigen server compleet updaten. Heb zelf de ftp gemirrord. Ook de cnc3.exe vervangen in dit bovenstaande lijstje door de hash van patchprepware waarbij ik pathprepare cnc3.exe op mn server heb genoemd werkt gewoon.

wou in het begin niet al teveel info geven omdat we dan misschien weer een legaal/niet legaal discussie krijgen...

ik weet dus nogsteeds niet wat het hashalgoritme zou moeten zijn. na een paar keer zo'n bestand heen er weer gekopieerd te hebben werkt hij nogsteeds via mijn eigen ftp server. De hash word gewoon gevalideert.

[Janoz]

Het punt is dat je onmogelijk kunt bepalen hoe dit werkt. Al zouden ze CRC gebruiken, het resultaat XOR-en met een willekeurige geheime sleutel en jij kunt er al weer helemaal niks mee (en met niks bedoel ik ook dat je niet kunt checken of het daadwerkelijk een CRC is).

Simpel maar wat loslaten op het bestand in de hoop er dezelfde hash uit te krijgen is onbegonnen werk. De enige werkbare manier is C&C in een debugger te draaien danwel te decompileren om te zien wat ze nu eigenlijk in het update proces doen. En ja, dat is minder legaal inderdaad .

[Verwijderd]

het zou kunnen dat ze een salt gebruiken. wel zo veilig eigenlijk omdat je daarmee dus corrupte exe's eruit kan vissen en crackes zonder die salt nog wel druk zijn om de zelfde hash te krijgen.

het feit dat de hash maar 4 bytes is doet mij vermoeden dat het inderdaad om CRC32 met waarschijnlijk een salt gaat. zonder die salt zul je nooit tot de zelfde hash komen en dat verklaart het eigenlijk wel.

@Janoz: sinds wanneer is decompilen/debuggen illigaal? voor eigengebruik mag je alles wel decompilen/debuggen. de ge-decompilede code weer opnieuwe publicieeren dat mag niet inderdaad maar je mag er gerust een stuk documentatie over schrijven. anders mocht tweakers.net ook niet die review over de USB sticks publicieeren zeker? daar hebben ze ook de code binnestebuiten gekeerd.

[ Voor 32% gewijzigd door Verwijderd op 20-06-2007 12:02 ]

[Hydra]

Verwijderd schreef op woensdag 20 juni 2007 @ 11:57:
@Janoz: sinds wanneer is decompilen/debuggen illigaal? voor eigengebruik mag je alles wel decompilen/debuggen. de ge-decompilede code weer opnieuwe publicieeren dat mag niet inderdaad maar je mag er gerust een stuk documentatie over schrijven. anders mocht tweakers.net ook niet die review over de USB sticks publicieeren zeker? daar hebben ze ook de code binnestebuiten gekeerd.

Je mag niet zondermeer code reverse-engineeren, helemaal als het de bedoeling is om beveiligingen te omzeilen.

[Janoz]

Verwijderd schreef op woensdag 20 juni 2007 @ 11:57:
@Janoz: sinds wanneer is decompilen/debuggen illigaal? voor eigengebruik mag je alles wel decompilen/debuggen. de ge-decompilede code weer opnieuwe publicieeren dat mag niet inderdaad maar je mag er gerust een stuk documentatie over schrijven. anders mocht tweakers.net ook niet die review over de USB sticks publicieeren zeker? daar hebben ze ook de code binnestebuiten gekeerd.

Illigaal is het niet, maar illegaal wel. Check de EULA van C&C maar eens. Nu weet ik wel dat de EULA niet boven de wet staat, maar er is helemaal geen recht op het decompileren, dus daarmee kan het ook helemaal niet in conflict zijn.

[.oisyn]

Ik vraag me af hoe illegaal het is. Sowieso is het in Nederland niet per definitie verboden om te reverse engineeren. Wat niet mag is beveiligingen omzeilen (dat doe je nog niet gedurende het reverse engineeren) en de boel aanpassen zonder toestemming (aangezien het gewoon auteursrechtelijk beschermd werk betreft). Je mag bijvoorbeeld weldegelijk reverse engineeren om een product te maken wat compatible is met het product in kwestie. Er is niets mis met debuggen, dat verbieden is zeggen dat je niet mag kijken hoe je eigen PC iets uitvoert, terwijl je het wel mag laten uitvoeren. Gelukkig is de wet in Nederland niet zo compleet achterlijk

[ Voor 19% gewijzigd door .oisyn op 20-06-2007 14:10 ]

[Verwijderd]

maar is de review van Tweakers.net over de beveiliging van de USB sticks dan een overtreding van de wet? zonder die review, zouden wij nu nog in de waan zitten dat die beveiliging wel oke is.

het gaat eigenlijk om een aantal verschillende termen,
1) decompilen. het omzetten van executie code naar broncode. eigenlijk doen vrijwel alle debuggers dit ook, en dit is volstrekt legaal. het verbieden zou eigenlijk ook absurds zijn omdat software ontwikkeling dan namelijk zogoed als onmogelijk wordt.

2) debuggen, debuggers maken een analyze van de code. zodoende kun je een programma stap voor stap doorlopen en een overzichtelijke inzicht krijgen en hoe een programma zijn werk doet. hier geldt het zelfde voor als voor decompilen. het verbieden heeft geen nut en dat is het dan ook niet. volstekt legaal.

3) documentatie. documentatie is eigenlijk simpel het voor mensen begrijpbaar op papier zetten van hoe een programma doet wat het zegt te doen. deze documentatie kan erg nuttig zijn voor als iemand een her-implementatie wil maken van een bepaald stuk software. documentatie wordt gezien als een eigenwerk van de auteur die het heeft geschreven en mag vrijelijk worden verspreid zoals de auteur dat wenst. de review van Tweakers.net kan worden gezien als een stuk documentatie en mag daarom worden gepubliceerd. de code die in bij het decompilen en debuggen is onstaan zijn afgelijde werken en vallen daarom onder het zelfde auteurs recht als het stuk software zelf. deze mogen daarom niet worden gepubliceerd. deze stukken voor eigengebruik gebruiken is volstrekt legaal.

4) clean-room. cleanroom is een methode waarbij 1 persoon de code debugged/decompiled en daar een stuk documentatie overschijft. waarnaar 1 of meerdere personen aan de hand van deze documentatie een her-implementatie kunnen schrijven. deze her-implementatie is dan het auterswerk van deze personen en niet van de auteur van de software waar de documentatie van is gemaakt. een voorbeeld hiervan is bijvoorbeeld wine. de cleanroom methode is de enige toegestane methode om te reverse-engineeren in de USA en de EU. hoe het precies in de nederlandse wet zit weet ik niet maar het zal waarschijnlijk dezelfde richtlijn volgen waarbij je alleen mag reverse-engineeren middels de clean-room methode met als doel om een incompatibiliteit te overbruggen.

kort samengevat:
1) decompilen: volstrekt legaal. publicatitie verboden
2) debuggen: ook legaal. publicatie verboden
3) documentatie: legaal. geen afgelijde dus eigenwerk van de schrijver
4) her-implementaite: legaal. publicatie toegestaan mits middels clean-room methode om incompatibiliteit te overbruggen.

in alle gevallen is het dus voor eigengebruik volstrekt legaal. als de TS de C&C 3 exe wil decompilen om zodoende de salt te achterhalen en een her-implementatie te maken van de auto-update functie dan is dat volstrekt legaal zolang de TS niet de gedecompilde code danwel de her-implementatie van de auto-update functionaliteit her-publiceert. de documentatie mag de TS zelf bepalen aangezien dat weer zijn werk is. als de TS ook zijn versie vande auto-update functie wil publiceern doet de TS er goed aan of middels de clean-room methode te werken of eerst iemand te raadplegen dit precies weet hoe dit in het nederlands auteursrecht is geregeld.

de EULA heeft hier niks mee te maken nog afgezien van het feit de de EULA een contract is waarvan de status in nederland waarschijnlijk niet eens rechtsgeldig is. het zou kunnen dat de TS door decompilen contracts-breuk pleegt maar danog is de TS niet in overtreding van de wet. volstrekt legaal dus.

[alx]

Er zijn wel eens mensen weggekomen met het omzeilen van computer gerelateerde beveiligingen via het argument dat de "beveiling" in kwestie op geen enkele manier effectief te noemen was en eigenlijk de naam "beveiling" niet waardig was. Ik weet niet meer welke zaak; ik dacht niet in NL. Zo'n argument kan wellicht geldig zijn, maar je begeeft je al gauw in een zeer grijs gebied. Dit zou wel of niet op kunnen gaan voor de USB sticks.

Maar volgens mij heeft T.net gewoon toestemming gekregen om de beveiliging te testen. Dan is er niets aan het handje.

Wat decompilatie en disassemly betreft is dat dacht ik in NL verboden, maar er zijn een aantal uitzonderingen, zoals interoperabiliteits- en educatieve doeleinden e.a. Wat de TS uiteindelijk van plan is, bepaalt denk ik of het legaal is. Overigens is voor veel software decompilatie out-of-the-question; het boomerang project is de enige echte decompiler van machine specifieke code die ik ken en dat schiet meestal niet echt op. Echte decompilatie is in de meeste gevallen een ondoenlijke klus. Wellicht dat disassemblers als IDA Pro of de aanstaande ollydbg 2 wat hulp kunnen bieden door standaard functieaanroepen/inlines en constructies te herkennen voor een aantal veel gebruikte compilers. Het terugdraaien van compilatie naar intermediate bytecode is veel eenvoudiger en bruikbaarder, maar ik denk niet dat dat van toepassing is op de cnc3 updater.

Wellicht kan de TS statisch of dynamisch de hash functie in kwestie identificeren. Het lijkt op een check op transfer schade, want een 32 bits hash is al lang niet meer afdoende voor crypto doeleinden. Mijn gok is ook (een variant van) crc32.
Als er een salt gebruikt wordt, moet dat een constante in het programma zijn en dan is het niet veel waard. Of het is dat unid of de ETAG van het http request/response, maar daar geloof ik eerlijk gezegd niet zo in.
Zijn die hashes van de echte cnc server iedere keer hetzelfde voor dezelfde file en size?
Wat zegt de client als de hash niet klopt? Gewoon transfer error? Probeert ie t opnieuw?

Verwijderd schreef op woensdag 20 juni 2007 @ 21:21:
[...]
de cleanroom methode is de enige toegestane methode om te reverse-engineeren in de USA en de EU. hoe het precies in de nederlandse wet zit weet ik niet maar het zal waarschijnlijk dezelfde richtlijn volgen waarbij je alleen mag reverse-engineeren middels de clean-room methode met als doel om een incompatibiliteit te overbruggen.
[...]

Volgens mij is dat niet zo, tenminste, als in "niet zeker". Niemand weet hoe het precies zit, zowel in de VS en de EU. Om problemen te vermijden gaat iedere serieuze reverse-engineerer via de cleanroom methode te werk, zeker als het gaat om software waarbij de oorspronkelijke producent al vele malen heeft geweigerd om info te verstrekken of zelfs van tijd tot tijd harde taal uitslaat (eenvoudig te herkennen aan de 3 letterige term "sue" (geen idee wat die dame ermee te maken heeft)
Volgens mij wordt de cleanroom methode niet in de NLse wet genoemd, maar dat weet ik niet zeker. De literatuur waaruit ik mij het denk te herinneren heb ik niet meer binnen handbereik en ik kan de wetten in kwestie niet vinden op wetten.overhead.nl.

[Thralas]

PEiD kan een flink aantal crypto en hashalgoritmen herkennen. Rechtsonderin op het pijltje, Advanced > KANAL na een bestand te hebben geladen.

Of het je veel verder helpt betwijfel ik, waarschijnlijk zul je met een debugger de code in moeten duiken om te zien wat er 'under the hood' gebeurt. Verdere discussie van reversing valt (helaas) buiten de policy - dit soort 'targets' reversen is juist leuk en leerzaam.

[tss68nl]

Dus....als ze niet rechtstreeks de hash berekenen maar een vaste prefix(of salt) voor de input, dan kan het best zijn dat je het correcte algoritme hebt geprobeerd. Alleen zal je dan zeker niet dezelfde hash hebben gekregen. Kortom...onmogelijk Is gebaseerd op puur geluk, en ik wens je veel succes met raden!

[Voutloos]

Verwijderd schreef op vrijdag 15 juni 2007 @ 10:41:
desnoods kun je een rainbow tabel gebruiken, wie weet zit er een match in.

Een rainbowtabel gebaseerd op inputstrings van de lengte van een beetje bestand is onmogelijk groot.