Processortype / -familie achterhalen uit (E)EPROM-dump

[raoulduke]

Ik probeer te achterhalen welk processortype of -familie wordt gebruikt in een embedded systeem, zodat ik de machinecode in een (E)EPROM kan disassemblen en kan aanpassen. Jammer genoeg heb ik op korte termijn geen toegang tot de hardware en kan ik daaruit niets afleiden. Wel heb ik meerdere versies van de volledige binaire dump die in het Flash-geheugen wordt geladen.

Zijn er bepaalde methodieken, zoals analyseren van een byte histogram, of herkenbare patronen om stap voor stap te identificeren welke instructieset / processorfamilie gebruikt is?

Het standaard UNIX 'file' commando herkent het bestand slechts als 'data'. In de romdump (128Kb) zijn leesbare ASCII-strings opgenomen, waaronder ook C-achtige sprintf()-opmaaktekens zoals %s en %d. De header van de ROM-dump begint als volgt (excuses voor het uitrekken van de layout):

code:

00000000  fa 00 fc 42 00 00 00 00  00 00 00 00 00 00 00 00  |...B............|
00000010  fa 01 5e d6 00 00 00 00  fa 01 8a d6 00 00 00 00  |..^.............|
00000020  00 00 00 00 00 00 00 00  fa 01 cc d4 46 f8 0a 00  |............F...|
00000030  3d 04 e0 d8 da 00 3a 00  e0 a8 9a b7 0a 70 46 59  |=.....:......pFY|
00000040  13 00 3d 07 7e b7 9a b7  fe 70 46 59 11 00 3d fa  |..=.~....pFY..=.|
00000050  7e b7 9a b6 fe 70 7e b6  f6 f8 b0 fe f0 48 db 00  |~....p~......H..|
00000060  fa 01 40 d2 fa 01 5a ce  f0 48 f0 59 28 40 38 50  |..@...Z..H.Y(@8P|
00000070  cd 03 f0 48 f0 59 0d 05  f0 48 81 40 f0 59 18 50  |...H.Y...H.@.Y.P|
00000080  81 50 db 00 00 00 00 00  00 00 00 00 fa 01 d8 d8  |.P..............|
00000090  fa 01 02 ca 00 00 00 00  00 00 00 00 00 00 00 00  |................|

De vele 0x00 bytes zijn niet-gebruikte geheugenlocaties. Jammer genoeg weet ik niet of de uitvoer van de ROM bij 0x00000000 begint, zodat (een deel van) 0xFA 0x00 0xFC 0x42 meteen de eerste instructie vormt, of dat er een ander entry point is.

Alle tips zijn welkom!

[DataGhost]

Ja, sommige instructiesets zijn zo met het blote oog te herkennen. Die ik ken herken ik er helaas niet in. Verder wil er soms ook nog een string van de processornaam/fabrikant tussen de code staan. Heb je misschien het hele bestand ergens (liefst de site van de fabrikant, ik denk niet dat je het zelf zomaar mag posten ivm auteursrechten enzo)?

De eerste series van 4 bytes zouden trouwens interrupt-locaties kunnen zijn, het lijken in ieder geval opvolgende geheugen-adressen te zijn.

[ Voor 17% gewijzigd door DataGhost op 04-01-2011 20:37 ]

[farlane]

Heb je meer gegevens over het embedded systeem? Bouwjaar, type toepassing, performance? Ennuh, je weet zeker dat het code geheugen is waar je naar zit te kijken?

[edit]
Ponder Ponder
Ik zie een aantal keren lang komen, ook als eerste instructie:
FA XX YY ZZ

Ik neem aan dat FA een jump is ( educated guess ), en XX, YY, ZZ het adress.
Ik neem aan dat XX een segment is( educated guess ), en YYZZ het adres

Ik zie ook een aantal keren:
F0 48 F0 59
Ik neem aan dat F0 de instructie is en 48/59 de data is ..

Ponder Ponder

Anyways, zou het een Infineon C166 (of derivaat) kunnen zijn?

Heb je de mogelijkheid om me het gehele image te sturen?

Damm nu wil ik het ook weten ook

[ Voor 97% gewijzigd door farlane op 05-01-2011 01:34 ]

[H!GHGuY]

Kun je niet gewoon even met objdump aan de slag?
objdump -d <filenaam>
Als objdump klaagt dat hij een processortype nodig heeft, kun je de meest gangbare even overlopen: arm, powerpc, mips32, mips64, ...

Trouwens, farlane heeft gelijk: welke systeem is het? Elimineren van processoren op basis van toepassing kan de scope al redelijk verminderen.

Veel embedded systemen starten van het laatste adres in de ROM (welke meestal een jump bevat).

[raoulduke]

Bedankt voor de reacties totnutoe; ik ben bang dat ik niet de hele dump kan opsturen in verband met NDA's enzo. Op de vraag of het geposte stukje een codesegment is, heb ik geen goed antwoord: mijn hoop was dat de uitvoering van de ROM op 0x0 zou beginnen en dat uit dit gedeelte zou te zijn achterhalen welke CPU er gebruikt is.

Het toepassingsgebied van deze ROM is een geavanceerde acculader. De ROM bevat onder andere configuratieinstellingen voor het oplaadproces, maar tijdens mijn onderzoek kwam ik erachter dat ook alle 'GUI' (display) strings aanwezig zijn, dus dat dit waarschijnlijk een volledige dump is van het systeem, niet alleen instellingen.

Is er verder geen 'statische' methode om een educated guess te ontwikkelen? Of een uitgebreidere 'file' tool die uitkomst kan bieden? Als de enige reeële optie is om de hardware te analyseren, dan ga ik alles in het werk stellen om dat te doen.

[H!GHGuY]

raoulduke schreef op woensdag 05 januari 2011 @ 09:21:
Bedankt voor de reacties totnutoe; ik ben bang dat ik niet de hele dump kan opsturen in verband met NDA's enzo. Op de vraag of het geposte stukje een codesegment is, heb ik geen goed antwoord: mijn hoop was dat de uitvoering van de ROM op 0x0 zou beginnen en dat uit dit gedeelte zou te zijn achterhalen welke CPU er gebruikt is.

Het toepassingsgebied van deze ROM is een geavanceerde acculader. De ROM bevat onder andere configuratieinstellingen voor het oplaadproces, maar tijdens mijn onderzoek kwam ik erachter dat ook alle 'GUI' (display) strings aanwezig zijn, dus dat dit waarschijnlijk een volledige dump is van het systeem, niet alleen instellingen.

Is er verder geen 'statische' methode om een educated guess te ontwikkelen? Of een uitgebreidere 'file' tool die uitkomst kan bieden? Als de enige reeële optie is om de hardware te analyseren, dan ga ik alles in het werk stellen om dat te doen.

Ik begin eerder richting 8032 en co te denken. ARM, PPC, MIPS, ... zijn allemaal veel te heavy voor een simpele acculader. Je zal eerder moeten zoeken naar microcontrollers.

Heb je objdump al geprobeerd?

[EddoH]

Er zijn anders genoeg microcontrollers met een ARM instructieset hoor, dat heeft niet zoveel met ' heavy' te maken.

Al zou je er achter komen welke instructieset gebruikt wordt, wordt het nog verdomd lastig er iets nuttigs uit te halen als je niet exact weet welke micro het is: er zullen nogal wat peripheral registers gelezen en geschreven worden.

[farlane]

raoulduke schreef op woensdag 05 januari 2011 @ 09:21:
Bedankt voor de reacties totnutoe; ik ben bang dat ik niet de hele dump kan opsturen in verband met NDA's enzo. Op de vraag of het geposte stukje een codesegment is, heb ik geen goed antwoord: mijn hoop was dat de uitvoering van de ROM op 0x0 zou beginnen en dat uit dit gedeelte zou te zijn achterhalen welke CPU er gebruikt is.

Het toepassingsgebied van deze ROM is een geavanceerde acculader. De ROM bevat onder andere configuratieinstellingen voor het oplaadproces, maar tijdens mijn onderzoek kwam ik erachter dat ook alle 'GUI' (display) strings aanwezig zijn, dus dat dit waarschijnlijk een volledige dump is van het systeem, niet alleen instellingen.

Is er verder geen 'statische' methode om een educated guess te ontwikkelen? Of een uitgebreidere 'file' tool die uitkomst kan bieden? Als de enige reeële optie is om de hardware te analyseren, dan ga ik alles in het werk stellen om dat te doen.

Post eens een stukje vanaf adres 0x0042FC en evt vanaf 0x01D6E dan.Post eens zoveel als je mag.

Aangezien je dump 128K is en het over een acculader gaat moet je het niet in al te geavanceerde uP's zoeken verwacht ik, 128K is meer gangbaar voor 8 of 16bitters.

De enige analyse die je zo kunt doen is op basis van 'wat wordt er normaal gesproken gedaan' gokken welke instructieset het is en met een disassembler ( of instructiemanual ) kijken of er zinnige assembly uitrolt op basis van de opcodes.

Ik raak er steeds meer van overtuigd dat het een C166 of afgeleide is trouwens.


[edit]
Deze disassembler ziet er wel goed uit ...

[DataGhost]

EddoH schreef op woensdag 05 januari 2011 @ 10:24:
Er zijn anders genoeg microcontrollers met een ARM instructieset hoor, dat heeft niet zoveel met ' heavy' te maken.

Al zou je er achter komen welke instructieset gebruikt wordt, wordt het nog verdomd lastig er iets nuttigs uit te halen als je niet exact weet welke micro het is: er zullen nogal wat peripheral registers gelezen en geschreven worden.

Naar mijn weten kan je ARM wel uitsluiten, die heeft een interrupt vector table op 0x0 en die heeft maar 7 interrupts... als dit zo'n table is tel ik er al 11. Daarnaast zie ik eigenlijk geen enkele onconditionele opcode staan.

[EddoH]

DataGhost schreef op woensdag 05 januari 2011 @ 13:56:
[...]

Naar mijn weten kan je ARM wel uitsluiten, die heeft een interrupt vector table op 0x0 en die heeft maar 7 interrupts... als dit zo'n table is tel ik er al 11. Daarnaast zie ik eigenlijk geen enkele onconditionele opcode staan.

Ik dacht dat ARM-uC een minimum aantal interrupts defined door ARM zelf had en verder vendor specific...
Anyway, bedoelde dat je ARM niet uit hoeft te sluiten op basis van applicatie.

[DataGhost]

EddoH schreef op woensdag 05 januari 2011 @ 16:48:
[...]


Ik dacht dat ARM-uC een minimum aantal interrupts defined door ARM zelf had en verder vendor specific...
Anyway, bedoelde dat je ARM niet uit hoeft te sluiten op basis van applicatie.

Hm, nu zie ik 'm. Dacht dat je 'een ARM processor' bedoelde

[raoulduke]

farlane schreef op woensdag 05 januari 2011 @ 11:10:
[...]
Post eens een stukje vanaf adres 0x0042FC en evt vanaf 0x01D6E dan. Post eens zoveel als je mag.

Hierbij twee korte hexdumps op die addressen, beginnend met 0x42F0:

code:

000042f0  6e 64 65 66 4f 70 63 6f  64 65 00 00 0a 86 ff 3c  |ndefOpcode.....<|
00004300  1a 86 04 d6 1a 89 00 ff  0a 89 ff 94 e6 0c 08 10  |................|
00004310  e6 8a be 04 e6 0a 0c fa  e6 00 00 00 e6 01 01 00  |................|
00004320  e6 02 40 00 e6 08 00 fc  b5 4a b5 b5 e6 e8 80 00  |..@......J......|
00004330  e6 e9 80 00 e6 f0 00 90  e6 f9 01 00 e6 f8 a8 04  |................|
00004340  f0 18 70 19 2d 2f a7 58  a7 a7 e0 05 dc 09 98 28  |..p.-/.X.......(|
00004350  2d 29 f0 32 dc 09 98 48  aa f2 1d e0 aa f2 0e f0  |-).2...H........|
00004360  f0 34 7c 33 0e f3 06 f3  00 fd e0 15 4c 54 91 50  |.4|3........LT.P|
00004370  68 5b b8 53 08 41 28 21  3d f3 0d e5 dc 09 98 38  |h[.S.A(!=......8|
00004380  a7 58 a7 a7 dc 44 b9 a3  08 31 18 40 76 f3 00 c0  |.X...D...1.@v...|
00004390  28 21 7d f6 0d d8 a7 58  a7 a7 b9 a4 08 41 28 21  |(!}....X.....A(!|
000043a0  7d fa 0d d1 e6 f9 01 00  e6 f8 00 00 a7 58 a7 a7  |}............X..|
000043b0  e6 03 03 00 dc 09 a8 28  2d 3e 08 82 18 90 aa f2  |.......(->......|
000043c0  2b f0 f0 42 66 f2 ff 3f  3d 05 e0 04 dc 09 a8 28  |+..Bf..?=......(|
000043d0  08 82 18 90 dc 09 a8 38  08 82 18 90 8a f4 06 e0  |.......8........|
000043e0  f6 f3 06 fe dc 09 a8 38  08 82 18 90 dc 09 a9 a8  |.......8........|

En 0x01D6E0 (jouw adres was garbled, misschien is dit niet het adres dat je bedoelde):

code:

0001d6e0  11 80 db 00 f0 48 47 f8  0a 00 3d 05 9a b6 fe 70  |.....HG...=....p|
0001d6f0  7e b6 e6 58 0d 00 9a b6  fe 70 7e b6 f0 48 d0 84  |~..X.....p~..H..|
0001d700  f6 f4 b0 fe db 00 9a b6  02 70 0f f4 0d 01 0e f4  |.........p......|
0001d710  69 81 db 00 9a b7 fe 70  f2 f4 b2 fe 7e b7 db 00  |i......p....~...|
0001d720  4a b7 f4 70 db 00 ec fd  f0 d8 da 01 5a d8 e6 a1  |J..p........Z...|
0001d730  04 00 7f a1 e6 a0 27 00  f6 8e 0c 90 f6 8e 0e 90  |......'.........|
0001d740  f6 8e 3a 90 f6 8e 3c 90  f6 fd 38 90 e0 0a e6 f4  |..:...<...8.....|
0001d750  36 38 e6 f5 40 00 f0 84  f0 95 0d 0f e0 06 dc 69  |68..@..........i|
0001d760  b8 68 c4 68 06 00 c4 68  08 00 dc 59 c4 68 04 00  |.h.h...h...Y.h..|
0001d770  c4 68 02 00 08 a1 06 f8  0a 00 46 fa 10 00 cd ee  |.h........F.....|
0001d780  f0 4d 5c 54 20 4d 5c 24  00 4d f6 f4 40 fe e6 b1  |.M\T M\$.M..@...|
0001d790  75 00 fc fd db 00 ec fe  ec ff f0 ef f2 f4 38 90  |u.............8.|
0001d7a0  f6 f8 0e fe 5b 44 f2 f7  0e fe 48 71 9d 01 e0 17  |....[D....Hq....|
0001d7b0  1b 74 f2 f8 0e fe e0 0b  e6 f4 36 38 e6 f5 40 00  |.t........68..@.|
0001d7c0  f0 24 f0 35 0d 26 da 01  28 c7 4a f4 fe 01 dc 43  |.$.5.&..(.J....C|
0001d7d0  a8 42 3d 18 dc 63 b8 72  c4 92 06 00 c4 a2 08 00  |.B=..c.r........|

Interessant is dat vlak voor 0x0042FC nog een aantal, misschien bekende(?), foutcondities worden genoemd:

code:

00004210  4e 4d 49 2d 4e 6f 6e 4d  61 73 6b 61 62 6c 65 49  |NMI-NonMaskableI|
00004220  6e 74 72 00 53 54 4b 4f  46 2d 53 74 61 63 6b 4f  |ntr.STKOF-StackO|
00004230  76 65 72 66 6c 6f 77 00  50 52 54 46 4c 54 2d 50  |verflow.PRTFLT-P|
00004240  72 6f 74 65 63 74 46 61  75 6c 74 00 49 4c 4c 4f  |rotectFault.ILLO|
00004250  50 41 2d 49 6c 6c 57 6f  72 64 4f 70 65 72 41 63  |PA-IllWordOperAc|
00004260  63 00 49 4c 4c 49 4e 41  2d 49 6c 6c 49 6e 73 74  |c.ILLINA-IllInst|
00004270  72 75 63 74 41 63 63 00  49 4c 4c 42 55 53 2d 49  |ructAcc.ILLBUS-I|

Met de genoemde disassembler en objdump moet ik nog aan de slag, ik ben niet fulltime bezig aan deze klus en ik verwacht pas morgenavond of zo echt wat meer er in te kunnen duiken. Tot die tijd alvast bedankt voor alle tips en gedachten.

[farlane]

Thx, nog een verzoek, zou je het stuk van 8000h tot 80FFh kunnen posten?

[edit]
Het onderstaande stuk is een disasm van een gedeelte, zoals je ziet lijkt het er toch wel erg op dat er een functie staat tussen 1D726 en 1D792.
De combinatie's van RETS en de PUSH R13 - POP R13 combo lijkt redelijk aannemelijk.

GAS:

1D724 : DB 00             RETS     
 1D726 : EC FD             PUSH     R13
 1D728 : F0 D8             MOV      R13,R8
 1D72A : DA 01 5A D8       CALLS    1,0D85AH
 1D72E : E6 A1 04 00       MOV      T3CON,#0004H
 1D732 : 7F A1             BSET     T3UD
 1D734 : E6 A0 27 00       MOV      T2CON,#0027H
 1D738 : F6 8E 0C 90       MOV      900CH,ZEROS
 1D73C : F6 8E 0E 90       MOV      900EH,ZEROS
 1D740 : F6 8E 3A 90       MOV      903AH,ZEROS
 1D744 : F6 8E 3C 90       MOV      903CH,ZEROS
 1D748 : F6 FD 38 90       MOV      9038H,R13
 1D74C : E0 0A             MOV      R10,#00H
 1D74E : E6 F4 36 38       MOV      R4,#3836H
 1D752 : E6 F5 40 00       MOV      R5,#0040H
 1D756 : F0 84             MOV      R8,R4
 1D758 : F0 95             MOV      R9,R5
 1D75A : 0D 0F             JMPR     CC_UC,0D77AH
 1D75C : E0 06             MOV      R6,#00H
 1D75E : DC 69             EXTP     R9,#3
 1D760 : B8 68             MOV      [R8],R6
 1D762 : C4 68 06 00       MOV      [R8+#0006H],R6
 1D766 : C4 68 08 00       MOV      [R8+#0008H],R6
 1D76A : DC 59             EXTP     R9,#2
 1D76C : C4 68 04 00       MOV      [R8+#0004H],R6
 1D770 : C4 68 02 00       MOV      [R8+#0002H],R6
 1D774 : 08 A1             ADD      R10,#1
 1D776 : 06 F8 0A 00       ADD      R8,#000AH
 1D77A : 46 FA 10 00       CMP      R10,#0010H
 1D77E : CD EE             JMPR     CC_SLT,0D75CH
 1D780 : F0 4D             MOV      R4,R13
 1D782 : 5C 54             SHL      R4,#05H
 1D784 : 20 4D             SUB      R4,R13
 1D786 : 5C 24             SHL      R4,#02H
 1D788 : 00 4D             ADD      R4,R13
 1D78A : F6 F4 40 FE       MOV      T2,R4
 1D78E : E6 B1 75 00       MOV      T3IC,#0075H
 1D792 : FC FD             POP      R13
 1D794 : DB 00             RETS   

Verder heb ik nog een Ultraedit highlight bestand gevonden met daarin de volgende termen:
STKOF, STKUF, PRTFLT, ILLOPA, ILLINA en ILLBUS, precies die termen die in jouw stukje staan.

Maw, ik ben er nu nog zekerder van dat het een C166 derivaat is, en waarschijnlijk een C167, aangezien mijn gebruikte disassembler de D9 opcode (EXTS) niet snapte bij een C166 en wel als ik een C167 koos.

Bovendien, er stond dit:

/L20"C167 ASM Tasking7" Nocase Line Comment = ; String Chars = "' File Extensions = ASM LST S66 S67 SRC

bovenin het Ultraedit ding.

[ Voor 94% gewijzigd door farlane op 05-01-2011 20:51 ]

[raoulduke]

farlane schreef op woensdag 05 januari 2011 @ 20:07:
Thx, nog een verzoek, zou je het stuk van 8000h tot 80FFh kunnen posten?

Zeker:

code:

00008000  40 00 f2 f4 60 33 88 40  d7 40 40 00 f2 f4 5e 33  |@...`3.@.@@...^3|
00008010  88 40 d7 40 40 00 c2 f4  27 32 88 40 d7 40 40 00  |.@.@@...'2.@.@@.|
00008020  c2 f4 26 32 88 40 d7 40  40 00 c2 f4 25 32 88 40  |..&2.@.@@...%2.@|
00008030  d7 40 40 00 c2 f4 24 32  88 40 d7 40 40 00 c2 f4  |.@@...$2.@.@@...|
00008040  23 32 88 40 d7 40 40 00  c2 f4 22 32 88 40 d7 40  |#2.@.@@..."2.@.@|
00008050  40 00 c2 f4 21 32 88 40  d7 40 40 00 c2 f4 20 32  |@...!2.@.@@... 2|
00008060  88 40 d7 40 40 00 c2 f4  1f 32 88 40 d7 40 40 00  |.@.@@....2.@.@@.|
00008070  c2 f4 1e 32 88 40 d7 40  40 00 f2 f4 b0 2f 88 40  |...2.@.@@..../.@|
00008080  d7 40 40 00 f2 f4 ae 2f  88 40 d7 40 40 00 f2 f4  |.@@..../.@.@@...|
00008090  ac 2f 88 40 d7 40 40 00  f2 f4 aa 2f 88 40 d7 40  |./.@.@@..../.@.@|
000080a0  40 00 f2 f4 a8 2f 88 40  d7 40 40 00 f2 f4 a6 2f  |@..../.@.@@..../|
000080b0  88 40 d7 40 40 00 f2 f4  a4 2f 88 40 d7 40 40 00  |.@.@@..../.@.@@.|
000080c0  f2 f4 a2 2f 88 40 d7 40  40 00 f2 f4 a0 2f 88 40  |.../.@.@@..../.@|
000080d0  d7 60 40 00 f2 fc 9e 2f  f2 fa b0 27 f2 fb b2 27  |.`@..../...'...'|
000080e0  e6 f8 0c 19 e6 f9 00 00  da 01 3e dd 06 f0 4c 00  |..........>...L.|
000080f0  db 00 ec fd da 01 0a c7  f3 f8 b8 90 2d 2c f7 8e  |............-,..|

In ieder geval heel erg bedankt voor het al gedane uitzoek- en meedenkwerk, ik ga morgenavond eens kijken of ik met een disassembler voor die C167 of gelijkende verder kom. Alhoewel ik de opcodes en het assemblerdialect van die processor niet ken, ziet die disassembled snippet er goed uit. De PUSH/POP lijkt inderdaad logisch in combinatie met een RETS.

Ik heb ook gevraagd of degene met toegang tot de hardware kan kijken welke chips er op de printplaat zitten, dus hopelijk ben ik er binnenkort uit.

[raoulduke]

Even een minder subtiel kickje: het processortype blijkt inderdaad een Infineon C167 te zijn en voor kleine aanpassingen heb ik een werkende workflow gevonden. Helaas heb ik nog geen goede disassembler gevonden, of ik zoek niet goed. Ik heb Ida Pro (Advanced) geprobeerd, maar daarin vind ik geen Infineon C166 serie, alleen Siemens C166 - is dat hetzelfde?

Ik heb ook uVision van Keil geprobeerd, maar daarin kan ik de .bin-file niet laden. Ook DAvE van Infineon helpt me niet echt verder, aangezien ik daar geen optie zie om binaries te disassemblen.

@farlane, welke disassembler heb jij gebruikt? Jouw uitvoer ziet er zeer bruikbaar uit!

[Onno]

raoulduke schreef op dinsdag 15 februari 2011 @ 11:00:
Ik heb Ida Pro (Advanced) geprobeerd, maar daarin vind ik geen Infineon C166 serie, alleen Siemens C166 - is dat hetzelfde?

Even googlen levert daar snel een antwoord op:

The Infineon (Siemens*) C166 was the first generation in the 16-bit microcontroller family. [...]

*Siemens spun off Infineon Technologies in 1999, so one may see this microcontroller family referred to as either Siemens or Infineon)

Daarnaast had je natuurlijk ook gewoon kunnen proberen wat IDA ervan bakt als je die Siemens C166 kiest.

[raoulduke]

Onno schreef op dinsdag 15 februari 2011 @ 12:52:
Daarnaast had je natuurlijk ook gewoon kunnen proberen wat IDA ervan bakt als je die Siemens C166 kiest.

Dat heb ik gedaan, maar het disassemblen van een embedded ROM is een beetje een nieuw gebied voor me. Ik ben nu al wat verder; in IDA krijg ik nu een redelijke disassembly te zien, dus daar ga ik mee aan de slag.

Edit: IDA doet toch nog niet helemaal wat ik wil, vooral qua startadres bij het decompileren loopt er wat mis. Andere disassemblers blijven dus welkom.

[ Voor 15% gewijzigd door raoulduke op 15-02-2011 14:40 ]

[farlane]

Hmm beetje laat maar ben je al verder hiermee? Dat je met een C166 niet verder komt kan wel kloppen aangezien de C167 instructies heeft die door een C166 disassembler niet kunnen worden gedecodeerd.

Ik zal even kijken wat voor een ding ik ervoor heb gebruikt, weet wel dat het een downloadable was voor DOS maar dat is geen probleem met een emulator