An old client contacted me to "decompile" some 68K code for a product line he purchased (but failed to verify that ALL the sources were available! So, there are portions of the production image that a "build" fails to recreate) "Sorry, not interested" [the first time I reverse-engineered a product was an "interesting" experience; the second time was "skill enhancing"; a THIRD time would just be "a job" -- boring!] This morphed into a discussion of folks I could recommend for the job (no one that *I* know would be interested). And, finally, a discussion of *tools* that he could purchase to undertake the task. I'd tackle it with an ICE -- especially if he has the target hardware available! A "poor man's" approach might be a logic analyzer (with appropriate disassembler) -- but tedious. A colleague suggested Ida Pro (apparently it can handle some number of different targets beyond x86). Any other approaches/tools that I can suggest?
68K disasm
Started by ●March 1, 2017
Reply by ●March 1, 20172017-03-01
On 1.3.17 20:25, Don Y wrote:> An old client contacted me to "decompile" some 68K code for a > product line he purchased (but failed to verify that ALL the > sources were available! So, there are portions of the production > image that a "build" fails to recreate) > > "Sorry, not interested" > > [the first time I reverse-engineered a product was an "interesting" > experience; the second time was "skill enhancing"; a THIRD time would > just be "a job" -- boring!] > > This morphed into a discussion of folks I could recommend for the > job (no one that *I* know would be interested). And, finally, a > discussion of *tools* that he could purchase to undertake the > task. > > I'd tackle it with an ICE -- especially if he has the target hardware > available! A "poor man's" approach might be a logic analyzer (with > appropriate disassembler) -- but tedious. A colleague suggested > Ida Pro (apparently it can handle some number of different targets > beyond x86). > > Any other approaches/tools that I can suggest?IIRC, the GNU binary utilities, binutils, can be configured for M68K. From the tools, objdump should do the job. -- -TV
Reply by ●March 2, 20172017-03-02
On 3/1/2017 12:17 PM, Tauno Voipio wrote:>> I'd tackle it with an ICE -- especially if he has the target hardware >> available! A "poor man's" approach might be a logic analyzer (with >> appropriate disassembler) -- but tedious. A colleague suggested >> Ida Pro (apparently it can handle some number of different targets >> beyond x86). >> >> Any other approaches/tools that I can suggest? > > IIRC, the GNU binary utilities, binutils, can be configured > for M68K. From the tools, objdump should do the job.IME, "batch" disassembly is really just a step above useless. Client could just as easily define a binary BLOB and paste it into the link map for all the value such an effort would yield. If you want to *understand* code, you need to see/watch it work. This is especially true if you don't know how the code was developed (e.g., as a compiled HLL vs. hand-tweaked ASM vs. ...) [As this isn't "my job", I'll just pass along the above suggestions -- incl yours -- and let *him* solve *his* problem! :> ] [[I am amazed at the number of times I've encountered folks who buy or inherit products without the documentation that went into their creation! And, that folks can fall into this "trap"!]]
Reply by ●March 2, 20172017-03-02
Hi Don, On Wed, 1 Mar 2017 21:16:15 -0700, Don Y <blockedofcourse@foo.invalid> wrote:>On 3/1/2017 12:17 PM, Tauno Voipio wrote: >>> I'd tackle it with an ICE -- especially if he has the target hardware >>> available! A "poor man's" approach might be a logic analyzer (with >>> appropriate disassembler) -- but tedious. A colleague suggested >>> Ida Pro (apparently it can handle some number of different targets >>> beyond x86). >>> >>> Any other approaches/tools that I can suggest? >> >> IIRC, the GNU binary utilities, binutils, can be configured >> for M68K. From the tools, objdump should do the job. > >IME, "batch" disassembly is really just a step above useless. >Client could just as easily define a binary BLOB and paste >it into the link map for all the value such an effort would >yield. > >If you want to *understand* code, you need to see/watch it work. >This is especially true if you don't know how the code was developed >(e.g., as a compiled HLL vs. hand-tweaked ASM vs. ...)That's true ... but you can't learn much by "watching it work" unless you can exercise every possible input. For some *small* programs that is possible, but in most cases it is between impractical and impossible. A module of any significant size, written in a compiled language, is likely to be very difficult to reverse engineer by tracing. A decent disassembly at least would let someone sit down and figure out the control paths. YMMV, but I don't see emulation really helping much without having a higher level overview of what is supposed to be happening. The other problem is there's a decent chance that old 68K code will not run on a modern CPU32 with JTAG ... Moto removed some "underused" addressing modes and bit manipulation instructions with the Coldfire cores. Hardware ICE for real 68K may be difficult/expensive to get hold of today. If this was embedded software - i.e. not for Mac/Atari/Amiga/etc. - then you may find a raw chip simulator useful. Depending on the actual target (000,010,020) there are some usable freely available tools below. And, of course, there are good commercial ones if there is a budget for them. graphical: http://www.easy68k.com http://home.kpn.nl/pj.fondse/ide68k/ https://github.com/BSVC/bsvc programmatic: https://github.com/kstenerud/Musashi>[As this isn't "my job", I'll just pass along the above suggestions -- incl >yours -- and let *him* solve *his* problem! :> ] > >[[I am amazed at the number of times I've encountered folks who buy >or inherit products without the documentation that went into their >creation! And, that folks can fall into this "trap"!]]Lots of things come without any documentation - even more come without *adequate* documentation. Not even having the sources is just another level of pain. George
Reply by ●March 3, 20172017-03-03
Hi George, On 3/2/2017 7:53 PM, George Neuner wrote:> On Wed, 1 Mar 2017 21:16:15 -0700, Don Y <blockedofcourse@foo.invalid> > wrote: >> On 3/1/2017 12:17 PM, Tauno Voipio wrote: >>>> I'd tackle it with an ICE -- especially if he has the target hardware >>>> available! A "poor man's" approach might be a logic analyzer (with >>>> appropriate disassembler) -- but tedious. A colleague suggested >>>> Ida Pro (apparently it can handle some number of different targets >>>> beyond x86). >>>> >>>> Any other approaches/tools that I can suggest? >>> >>> IIRC, the GNU binary utilities, binutils, can be configured >>> for M68K. From the tools, objdump should do the job. >> >> IME, "batch" disassembly is really just a step above useless. >> Client could just as easily define a binary BLOB and paste >> it into the link map for all the value such an effort would >> yield. >> >> If you want to *understand* code, you need to see/watch it work. >> This is especially true if you don't know how the code was developed >> (e.g., as a compiled HLL vs. hand-tweaked ASM vs. ...) > > That's true ... but you can't learn much by "watching it work" unless > you can exercise every possible input. For some *small* programs that > is possible, but in most cases it is between impractical and > impossible.My understanding is that they have much of the codebase, know what the product does, etc. Apparently, they just have a "hole" that they would like to document so they can port the design to a more modern implementation. [I am short on specifics as I don't want to get dragged into *their* problem! :> ]> A module of any significant size, written in a compiled language, is > likely to be very difficult to reverse engineer by tracing. > > A decent disassembly at least would let someone sit down and figure > out the control paths. YMMV, but I don't see emulation really helping > much without having a higher level overview of what is supposed to be > happening.In the past, I've been able to successfully use an ICE with a target to watch to see how "particulars" (I/O's) alter the code's execution. The advantage to compiled code (HLL) is that the compilers tend to be more consistent in their code generation than one or more ASM developers. [I know nothing of how this "missing" portion of the code was developed, nor its intended functionality. And, at this point, I suspect client doesn't, either!]> The other problem is there's a decent chance that old 68K code will > not run on a modern CPU32 with JTAG ... Moto removed some "underused" > addressing modes and bit manipulation instructions with the Coldfire > cores. Hardware ICE for real 68K may be difficult/expensive to get > hold of today.I've got several ICE's in storage -- necessary tools of the trade 10, 20 and 30 years ago. (There are advantages to keeping old kit around!)> If this was embedded software - i.e. not for Mac/Atari/Amiga/etc. - > then you may find a raw chip simulator useful. Depending on the > actual target (000,010,020) there are some usable freely available > tools below. And, of course, there are good commercial ones if there > is a budget for them. > > graphical: > http://www.easy68k.com > http://home.kpn.nl/pj.fondse/ide68k/ > https://github.com/BSVC/bsvc > > programmatic: > https://github.com/kstenerud/Musashi > >> [As this isn't "my job", I'll just pass along the above suggestions -- incl >> yours -- and let *him* solve *his* problem! :> ] >> >> [[I am amazed at the number of times I've encountered folks who buy >> or inherit products without the documentation that went into their >> creation! And, that folks can fall into this "trap"!]] > > Lots of things come without any documentation - even more come without > *adequate* documentation. Not even having the sources is just another > level of pain.My point was that the whole point of the *purchase* was to acquire a *product*, not an *instance* of a product. You'd think they would be OBSESSED with making sure all the documentation required to build and maintain the product were present BEFORE making the purchase! I.e., let me watch you build the software image from the documents on the medium you're delivering! [If it was me making/advising the purchase, I'd also want to have the makefiles, assembly drawings, test suites, etc. A schematic and partial set of software listings doesn't go very far towards describing what you're buying!]
Reply by ●March 3, 20172017-03-03
On 03.3.2017 г. 04:53, George Neuner wrote:> ..... > > The other problem is there's a decent chance that old 68K code will > not run on a modern CPU32 with JTAG ... Moto removed some "underused" > addressing modes and bit manipulation instructions with the Coldfire > cores. Hardware ICE for real 68K may be difficult/expensive to get > hold of today.I suppose you mean Coldfire rather than CPU32. CPU32 looks more or less like a 68020 minus the bitfield opcodes at user level. I am pretty sure (without looking/verifying) all 68000 user level opcodes would work on a CPU32; not so on a coldfire, then there are different CF cores (e.g. the one I have used will not allow you byte or word sized add/sub, just longword etc.) Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●March 3, 20172017-03-03
On 01.3.2017 г. 20:25, Don Y wrote:> An old client contacted me to "decompile" some 68K code for a > product line he purchased (but failed to verify that ALL the > sources were available! So, there are portions of the production > image that a "build" fails to recreate)Sorry, forgot to mention perhaps the most interesting part of it in my other messages. Having all the asm sources for a 68k product means it can be ported to power - e.g. to one of the 603e derivative cores - without too much pain. This is what I did some 15 (17?) years ago, this is how vpa got started (having a few megabytes of good sources I did not want to part with was the main drive). CPU32 user level code will still assemble into power directly, obviously supervisor level has to be rewritten but usually it is a tiny part of the code (was - is - so in DPS at least). Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●March 3, 20172017-03-03
On Wed, 1 Mar 2017 11:25:55 -0700, Don Y <blockedofcourse@foo.invalid> wrote:>... "decompile" some 68K code ...I might be interested in taking on this project. 1yknuj at neysocim dot moc <-- Reverse each field.
Reply by ●March 3, 20172017-03-03
On Wed, 01 Mar 2017 11:25:55 -0700, Don Y wrote:> An old client contacted me to "decompile" some 68K code for a product > line he purchased (but failed to verify that ALL the sources were > available! So, there are portions of the production image that a > "build" fails to recreate) > > "Sorry, not interested" > > [the first time I reverse-engineered a product was an "interesting" > experience; the second time was "skill enhancing"; a THIRD time would > just be "a job" -- boring!] > > This morphed into a discussion of folks I could recommend for the job > (no one that *I* know would be interested). And, finally, a discussion > of *tools* that he could purchase to undertake the task. > > I'd tackle it with an ICE -- especially if he has the target hardware > available! A "poor man's" approach might be a logic analyzer (with > appropriate disassembler) -- but tedious. A colleague suggested Ida Pro > (apparently it can handle some number of different targets beyond x86). > > Any other approaches/tools that I can suggest?This reminds me of the advice that I got from an engineering friend when I went out as a consultant. He sat me down, gazed into my eyes, and said "Tim, you need to remember that you're now a whore." Send him my email. Tell him I'll happily solve his problem on a full- price, per-hour basis. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●March 3, 20172017-03-03
On 3/3/2017 3:49 AM, Dimiter_Popoff wrote:> On 01.3.2017 г. 20:25, Don Y wrote: >> An old client contacted me to "decompile" some 68K code for a >> product line he purchased (but failed to verify that ALL the >> sources were available! So, there are portions of the production >> image that a "build" fails to recreate) > > Sorry, forgot to mention perhaps the most interesting part > of it in my other messages. > > Having all the asm sources for a 68k product means it can be > ported to power - e.g. to one of the 603e derivative cores - without > too much pain. This is what I did some 15 (17?) years ago, this > is how vpa got started (having a few megabytes of good sources > I did not want to part with was the main drive). > CPU32 user level code will still assemble into power directly, > obviously supervisor level has to be rewritten but usually > it is a tiny part of the code (was - is - so in DPS at least).I don't know their ultimate goal. Obviously, they can't "produce" the existing design (unless they bought the entire related resources of the company -- including any NOS components that they had in inventory). I suspect they are just trying to find an easy/straight-forward way to port the device's functionality to a more modern implementation. And, have decided that it is complex enough that a clean-room reimplementation would be too expensive. Or, they could have picked up the rights to the product by purchasing a (defunct) *company* and are looking for inexpensive ways to exploit those assets. <shrug> As I said, I don't want to get too involved in THEIR problem as I've got enough on my plate to keep me "intellectually engaged" for quite a while! Any effort thinking about their needs would just be at the expense of *mine*! :>
