From: Clem Cole <email@example.com>
To: segaloco <firstname.lastname@example.org>
Cc: The Eunuchs Hysterical Society <email@example.com>
Subject: [TUHS] Re: UNIX Disassemblers and other RE Tools
Date: Fri, 25 Aug 2023 16:33:08 -0400 [thread overview]
Message-ID: <CAC20D2OOBhoEixM4Ofq6fcKrYMs=G9GQ_YzApicQvX1M5_qpwA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3464 bytes --]
On Fri, Aug 25, 2023 at 3:51 PM segaloco via TUHS <firstname.lastname@example.org> wrote:
> Hello, I've been doing some research on the history of disassembly lately,
> tools available historically, today, and what sorts of developments have
> been made regarding utilities and systems for taking a machine-code binary
> and working it back to some semblance of source code.
> So in the early days UNIX had das(I), a PDP-11 disassembler I believe
> written by Ken (he's OWNER in the manual) with very little information
> other than "it exists". Fast forward to the UNIX 4.1 manual in 1981 for
> the 3B20S and there is dis(1), a 3B20 disassembler. Other such manuals
> feature dis(1) versions for other 3B targets.
> Was a disassembler ever considered part of the standard binary objects
> toolkit with the assembler, linker, etc.
not to my memory - although some of the debuggers could. IIRC, the DDT
that was on the Harvard tape knew about it. I also remember on that tape
was a PDP-11 disassembler. Phil Karn wrote a table-based one for UNIX
when we were students - but it was aimed at 8-bit micros. It could do
8080/8085 and Z80; if I remember, it could also do MOS6502 and M6800. It
had a feature that it could take an external symbol table and turn out code
that was reasonable to reassemble. [ I may have a copy if it squirreled
That said, while they we not part of the core tool kit, by the time of
BSD4.2 there were a couple of disassemblers kicking around the USENET. I
remember one for the Vax and another for the 68000. You might do a grep for
dis-assembler in the USENET archives for comp.sources
> or was that the sort of thing that was more niche and therefore just kinda
> cropped up when/if someone decided to write one?
exactly - need driven. Phil wrote his when we were trying to pull apart a
ROM for a tape controller. It had a funky interface on it that was not
well documented and what we did have, was wrong. So, disassembled enough
of the ROM that we could changed it.
> Were there legal concerns to be grappled with when producing a
Mumble ... by the mid-80s/late-90 people we disassembling code for game
controllers and PCs. So many manufacturers started adding words in the EULA
saying that was a no-no. But I don't remember worrying about it much when
I was a student 10-15 years before that.
> Were such tools ever shipped or did they only appear in the manuals as
> they were technically up in the code base, just not commonly distributed or
> used? Also, was there any thought given during the development of C to
> producing "decompilers" as has been becoming more common lately? Or was it
> a foregone conclusion that C to assembly is a "lossy" conversion and going
> the other direction couldn't be fully automated.
Again - in V6/V7 with DMR's compiler, it was not always easy, but the code
generally was pretty straightforward.
Post Wulf's 'Green Book' on compiler optimization and we started to have a
generation of BLISS-style optimizers pretty much everywhere, I think those
compilers really started refactoring code plus instruction sets got more
sophisticated, so I think it started to get harder and harder to
But I'll defer to someone like Paul W or Steve Johnson who loved building
those style of tools.
> Thank you for any insights!
> - Matt G.
[-- Attachment #2: Type: text/html, Size: 5926 bytes --]
prev parent reply other threads:[~2023-08-25 20:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-25 19:51 [TUHS] " segaloco via TUHS
2023-08-25 20:28 ` [TUHS] " Rich Salz
2023-08-25 20:33 ` Clem Cole [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).