latest beta "dis.of" can detect hidden or disguised ppc instructions

[Tinkerer Atlarge]

I have continued adding extra capabilities to "dis.of", the PowerPC
Macintosh Open Firmware disassembler whenever I find spare time over the
past six months, including some unorthodox user-preference options:

nextline vs sameline

These options determine how much clutter 'asm' leaves on screen when
inputting a sequence of assembler instructions. Typing 'sameline' at any
time will cause asm to overwrite the ppc instruction you typed with the
way it was actually interpreted. That leaves a compact presentable
listing on screen at the end of code entry sequences. 'nextline' prints
the disassemled equivalent below your typed input, preserving your
ability to compare the instruction you typed with the one you got.

simplify vs unsimplify

These options give a more intuitive listing of conditional branch
instructions. "bclr 14,0" now decodes as "blr" for example. The old
style branch format is still available because I have yet to update
'asm' with similar capability. You might prefer seeing your branch
instructions echo back in the same format you enter them. In that case
you would type 'unsimplify' before using 'asm'.

conceal vs reveal

This determines whether to ignore or scrutinize more closely what lies
concealed within the reserved bits of powerpc instructions. Some fields
are ignored by the G4, but the official line is that they are reserved
and should always remain empty. That is something compilers and
assemblers generally comply with. Disassemblers are prone to rely on
them having done so, without allowing in some cases for the possibility
that instructions could have been tampered with after the compiler was
finished with them.

To see the effect of "reveal" (after booting the current version of
dis.of available free from the author via email), type at the forth
prompt:

7c567826 here !
conceal
here dasm ( disassembles as "data" )

It looks like data and most probably is. However if you are of a
naturally suspicious nature, you could type:

reveal
here dasm ( now disassembles as "mfcr r2" )

Instructions which spring fully-formed out of data like that are real
instructions which execute normally on the G4 without any telltale
side-effects, and probably also on the G5 and other related cpus.

Which way to disassemble memory cells containing such data is correct?

The answer is, it depends what you are doing.

As the vast majority of ppc code you examine will have been produced by
a compiler or assembler, it will most probably be "pure" and the output
correctly decoded by any powerpc disassembler. Rejecting improperly
coded instructions as more likely to represent data gets them out of the
way and makes it easier to spot the action sequences in your memory
dumps.

However it is possible that such a disassembler could miss displaying
code which was disguised as data in order to conceal its presence or
purpose. Typing 'reveal' in such circumstances makes it easier to spot
and investigate what could turn out to be disguised executable
instructions.

The underlying problem is that a disassembler can never be certain
whether a memory cell contains code or data. It is the way the cell is
interpreted which matters in the end. Only the programmer can know for
sure which cells are intended to be used (or ignored) as data and which
are intended to be executed as code by the cpu.

To demonstrate this for yourself (assuming you have not been writing to
unallocated memory or telling forth to 'forget' things since you booted
dis.of), try this at the Open Firmware prompt:

0 , ( points 'here' past the cell we played with above )

here @ s. ( reports contents as: -21524111 )

here 4 type ( responds with a 4-char garbage striing )

here @ u. ( reports contents as 'deadbeef' )

That was the same "data" interpreted three different ways using normal
forth commands. It is you, the operator, who must tell the computer how
you want the contents of memory interpreted.

here dasm \ reports same contents as "stfdu fr21,-0x4111(r13)"

Thus the disassembler is no better. It does not know whether it is
looking at data or an instruction. If it can recognize an instruction it
will report one because that is its job.

The best clue to the "meaning" of the contents of that particular memory
cell in this case can be revealed by typing:

here 60 dump

It turns out to be nothing more than the pattern Open Firmware uses to
fill unused memory at startup.

With "dis.of", you are the one in the driver's seat.

If 'dis' or one of its variants finds anything which could be an
instruction in disguise, it colors it green and will output it as "data"
as long as the 'conceal' option remains in effect. If you more recently
typed 'reveal', it will interpret it as a ppc instruction, but color it
the same as data to remind you not to become too paranoid.

"dis.of" is constantly being enlarged and tinkered with, and is thus
always in beta. It is written in plain-text forth source code, easily
scrutinized. The PowerPC Macintosh's boot monitor, Open Firmware,
compiles and runs it automatically when given the appropriate "boot"
command.