The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <>
To: segaloco <>
Cc: The Eunuchs Hysterical Society <>
Subject: [TUHS] Re: UNIX Disassemblers and other RE Tools
Date: Fri, 25 Aug 2023 16:33:08 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3464 bytes --]


On Fri, Aug 25, 2023 at 3:51 PM segaloco via TUHS <> 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
away ].

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
> disassembler?

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 --]

      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]

Reply instructions:

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 \
    --in-reply-to='' \ \ \ \

* 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).