Opbouw binbestand

[realist]

Wanneer ik bijv. een DVB 2000 bin bestand open, dan krijg ik in wordpad een tekst die bestaat uit letters, cijfers en de meest vreemde Ascii-tekens. Maar verreweg de meeste tekens bestaan uit vierkantjes.

Wat betekenen die vierkantjes eigenlijk en heb ik met een programmeertaal te maken?

Hoe wordt ik in deze wat wijzer. Elk verhelderend antwoord is welkom.

BVD, de realist

 

[Ome Merde]

is inderdaad een programmeer taal, volgens mij C++. Om dat te compilen zal je de source moeten hebben en ik denk niet dat Uli die afstaat <img src="/ubbthreads/images/icons/smile.gif" alt="" />

 

 

groet,

merde

[prutsie]

Een bin of hex bestand zoals bv. dvb2000 is een geassembleerd (samengesteld) programma voor de Nokia MediaMaster. Hier zit een 68000 of afgeleide processor in. wat je te zien krijgt is dus de machinecode voor deze specifieke processor.

Hier heb je eigenlijk weinig tot niets aan, of je moet op dit niveau kunnen programmeren. Het is moeilijk, maar er zijn mensen die dat echt kunnen, en alle instructies ook echt begrijpen.

 

De code is echter niet zo geweest.

Men is begonnen in bijvoorbeeld de programmeertaal Cobol, of een plusversie hiervan een programma te schrijven. dit ziet er een beetje basic achtig uit. Als je dus vroeger ooit programmatjes in basic hebt gemaakt dan weet je hoe dit eruit ziet.

 

Helaas kan de processor hier niets mee. je zal een vertaler nodig hebben, van Cobol naar machinecode. dit is de enige taal die de processor begrijpt.

In de oude commodore 64, en andere homecomputers die je in basic kon programmeren zat een zogenaamde basic interpreter. Dit is dus het vertaalprogramma wat de basic instructies omzet naar machinecode, de enige "taal" die de processor begrijpt.

 

Nadat het programma is geschreven (wat er dus uitziet als een soort basicprogramma) wordt dit door een debuggerpeogramma gecontroleerd op eventuele fouten, en als deze eruit zijn kan je het door het vertaalprogramma laten vertalen naar machinecode. dit vertaalprogramma wordt ook wel compiler genoemd.

Uit de compiler komt het programma zoals jij dat van het internet hengelt.

Het vervelende is dat alle op en aanmerkingen die de programmeur als geheugensteuntjes in het originele niet vertaalde programma heeft gezet bij deze vertaalslag door de compiler worden verwijderd.

 

In principe is het niet noodzakelijk een programma weer terug te vertalen van machinecode naar bijvoorbeeld cobol. Het originele niet vertaalde programma is immers in het bezit van de schrijver.

Nu zijn er echter handige jongens die voor bepaalde vaak populaire processoren programma's hebben gemaakt die de vertaalslag van machinecode naar cobol kunnen maken. Dit zijn de zgn. Decompilers. deze zijn er voor bv. de pic16F84, en de 68000 gebaseerde processoren.

nadeel is wel dat je de opm en aanmerkingen van de programeur niet terug kan halen, deze zijn verloren gegaan met de vertaalslag van cobol naar machinecode.

 

Degene die dus de machinecode decompileert naar cobol zal dus heel wat zoekwerk te wachten staan.

 

je hebt dus in principe stappen

1/schrijven programma in bekende programmertaal, bv Cobol.

2/vertalen (compileren) naar voor de gebruikte processor begrijpelijke instructies.

 

Het maken van een zogenaamde patch kan dus ook op 2 manieren.

1/het veranderen van opdrachten in machinecode.

2/het decompileren van de software, vervolgens doorgronden van de werking, vervolgens aanpassen naar jou wensen, vervolgens debuggen, vervolgens compileren.

 

De eerste optie is vele malen lastiger dan de tweede, maar omdat er voor hele generaties moderne processoren geen decompilers (die door hackers worden gemaakt) zijn gebeuren de eerste patches vaak op de eerste manier.

 

een goed voorbeeld is de Humax patch. de eerste versie die Irdeto en Betacrypt kaartjes in de embedded cam mogelijk maakte is zeer waarschijnlijk rechtstreeks in de machinecode gemaakt.

Later is er door iemand een decompiler gemaakt voor de processor die in de Humax wordt gebruikt en is de machinecode gedecompileerd. Hierna is het moeilijke proces begonnen van het doorgronden van de software, en het aanpassen ervan. Het resultaat is bekend, een perfecte patch die dingen mogelijk maakt die een jaar geleden nog tot hoongelach zouden leiden als je dit zou voorspellen.

 

Als je zelf eens wat wilt stoeien met deze materie begin dan met een simpele processor zoals de PIC16F84. De debugger, en compiler zijn gratis van internet af te hengelen, en op de website van de fabrikant staan zelfs diverse voorbeelden van programma's en protocollen.

er is mijns insziens geen betere en goedkopere manier om wat meer van programmeren te weten te komen. de processor kost (bijna) niets, maar een handjevol instructies die je in een uurtje uit je hoofd kent, en een gratis debugger en compiler. Ook de DEcompiler kan je op internet vinden voor deze chip.

 

Mijn verhaal is hier en daar wat kort door de bocht, maar om het enigszins beknopt te houden noodzakelijk.

Groeten,

 

Peter.

[marlb64]

Mag ik aan de uitstekende uitleg van Prutsie nog toevoegen dat, afgezien of het verstandig <img src="/ubbthreads/images/icons/confused.gif" alt="" /> is om in een bin of hex bestand te rommelen als je niet EXACT <img src="/ubbthreads/images/icons/shocked.gif" alt="" /> weet wat je doet,wordpad niet het geschikte programma is om dat te doen.Om een binaire file te kunnen bewerken dien je in ieder geval binaire editor zoals bv ultraedit oid te gebruiken.

 

GRTZ <img src="/ubbthreads/images/icons/grin.gif" alt="" /> <img src="/ubbthreads/images/icons/grin.gif" alt="" />

[Gast]

Prutsie,

zou mooi zijn als we die Pic dingen in een 2, 3 of 4e GL konden proggen.

Helaas zullen we het toch met de assembler voor die specifieke pic moeten doen.

En dat lijkt niet echt op bsic hoor.

Verder een goede uitleg hoor.

Avensis

[realist]

@Bill, Bedankt.

@Peter,

Allereerst bedankt voor deze voltreffer.

Na hem meerdere keren gelezen te hebben kom ik uiteindelijk weer tot een paar vragen:

((ik ben helaas (nog) geen programmeur)).

1). Je hebt het over de machine code v/d processor. Hier dus in de vorm van symbolen en naar ik begrijp is dit assembleertaal.

Nu dacht ik dat een processor uiteindelijk alleen maar overweg kan met machine instructies, bestaande uit énen en nullen. Dit zou dus inhouden dat er tussen de machine code en de machine instructies nog een medium moet zitten die dit bewerkstelligt. Zie ik dit goed en krijgt een programmeur hier mee te maken?

2). Als ik een Pic 16f84 hex bestand open, dan krijg ik alleen en alleen maar hexadec. getallen te zien. Moet ik dit ook zien als machine code?en is dit ook een geassembleerd programma? M.a.w. Is dit assemblertaal?

3). De Eeprom v/d bekende goldwafer wordt zowel in een bin- alswel in een hexbestand aangeboden terwijl de Pic volgens mij altijd een hex bestand is. Waardoor wordt die keuze bepaald?

Nogmaals ten zeerste bedankt enne......

4).Wie is toch die vermaledijde "Boets"?

@marlb 64 Bedankt.

Ik zoek feitelijk de binaire editor Ultraedit.

@avensis. "zou mooi zijn als we die Pic dingen in een 2, 3 of 4e GL konden proggen."

Volgens mij is dit broncode tussen 2 specialisten onder elkaar.

 

 

 

 

 

 

 

 

[Gast]

Ok Realist zal een en ander verduidelijken voor de leek.

BIN staat voor binair een code die uitsluitend uit symbool 1 en 0 bestaat

Hex staat voor hexadecimaal cijfer 0-9 en dan A, B, C, D, E en F(0-15 is 16=Hexad.)

Assembler de taal die voor ons mensen iets makkelijker leesbaar is als binair en hexadecimaal. De assemblertaal bestaat uit zgn. mnenomics die voor ons een betekenis hebben of op een afkorting lijkt die wat voor ons betekent.

B.v. BYTE MVC etc.

Iedere PIC kent zijn eigen assemblertaal en om daar machinetaal van te maken is er een programmma nodig die vaak ook ASSEMBLER heet of de naam COMPILER draagt.

De "nieuwere" talen zoals COBOL, PL1, ALGOL, PASCAL, BASIC, C, C++ en b.v. DELPHI

worden de 2e t/m 4 GL talen genoemd(Generation Language).Deze talen zijn voor ons nog makkelijker leesbaar.

Het stukje v.d. ASSEMBLER/COMPILER miste je nog.

Hoop dat alles nu duidelijk is.

Avensis

 

Die getallen die je ziet zijn de eigelijke instrukties aan de processor met de eventuele data die er bij hoort. Iedere mnenomic(instruktie) heeft een biniare/hexadecimale code, en dat is wat je ziet.

In principe zou je die getallen terug kunnen brengen naar de mnenomics mbv een decompiler(moet je wel weten voor welke PIC). Hier gebruik ik IDAPRO en ben daar meer als tevreden over. Het leren vd mnenomics valt best mee dat zijn er meestal niet zoveel, ergens in de orde van 30 a 40). Het leren programmeren en een ander zijn manier van denken uit de code te halen vergt echter wel de nodige tijd.

Een firmware zoals voor de Hummie bestaat uit meerdere duizenden instrukties.

Daar komt dan nog bij dat je ook een gedegen kennis vd crypt algo's moet hebben.

Ik heb dan ook bijzonder veel respekt voor mensen als Ulli en PH die resp. DVB2000 en de patches hebben gemaakt. Die hebben daar echt honderden uren werk in zitten.