adb use on xenix 3.0?

[Ray Arachelian]

I'm trying to help out Jason Perkins who wants to demo Multiplan on
Xenix 3.0 for the Apple Lisa at the upcoming VCF.  While the bits for it
are on bitsavers, it requires a serial number and so far he's had zero
no luck finding one.

So I'm trying to use adb to step through the code and find where it
checks for the serial number, etc.

So I run adb ./brand and then set a breakpoint using :b on "." which is
the start address for the binary, and then I do :r /usr/lib/mp/mp and it
does stop before the 1st instruction is executed (or maybe right after),
however, when I try :s to step to the next instruction it runs the rest
of the program in its whole.  I know there's also :e which should step
but skip over any function calls.  I've also tried :ss, and got the same
results (whole program runs without stopping).

? and enter does disassemble the non-running binary. $r and $m show
registers and the map.

I'm actually not sure if I'm setting the breakpoint correctly as $b
shows it, but there's also a "command" field next to the address, so if
I do :bfoo, it shows address 0 and foo for the command. So what should
"command" be? and how do I single step through the running code?


Some more details of what I got so far for those with historical interest:

The basic installation is untarring the multiplan disk, which writes to
/usr/lib/mp and /once.  In /once there's a script init.mp that runs
brand -s {serial} /usr/lib/mp/inter, but if you enter the wrong serial
number it removes all the files.

brand seems to look for a string starting with SCOSN - there's 4 copies
of the "SCOSN" string inside brand, not sure why.  The /usr/lib/mp/inter
binary has only one like this: SCOSNMFO9999990000.

I suspect that brand replaces the stuff after SCOSN with whatever the
properly encoded serial number is.  There's some sort of simple
ROT13-like encoding of the string stored in inter.  Out of the box
running "/usr/lib/mp/inter /usr/lib/mp/mp" produces output with a
product number and a serial # of NUL-000000 - the "MFO" is decoded to
NUL (basically substitutes A for Z, B for Y, 0 for 9, 1 for 8, etc.) and
ofc it says invalid serial # and quits.

The serial number is checked by both brand and inter, but maybe not the
code in mp.cod (I touched a file called /usr/lib/mp/foo.cod and then it
said /usr/lib/mp/foo.dat missing, so I touched that one too, and when I
ran it, it said invalid serial number.  Running inter by itself just
prints a banner without saying invalid serial number.)

I'm guessing the serial number is 3 letters a dash and 6 digits, but
there's maybe 4 more digits that have to be entered, or those 4 extra
digits are generated by brand, not sure.  However, so far brand hasn't
accepted any serial number tried.

I suspect inter to be a Microsoft virtual machine that wants to load
mp.cod and mp.dat which are the real code for multiplan.  I read
somewhere that early on MSFT was using VMs to do help them from having
to port the same code to lots of targets.  This way they could port the
interpreter for the vm and run anywhere, though inter has string saying
multiplan so perhaps there's some customizations to each copy of inter
based on what it's supposed to run?

brand seems to take two more options -m and -n (and -q which I suspect
is "quiet" as the init.mp script uses it).  Both -m and -n cause a core
dump but first print "identifier string found at D in"

This is an interesting bit of history that I'd like to reverse engineer
if possible. 

brand hasn't been stripped so it's likely a bit easier to disassemble.
inter however is stripped, so would be much harder to reverse engineer.
But it would be very useful to be able to step through one instruction
at a time to find where it's doing a checksum or whatever and try to
figure out what the serial number looks like.

Jason is trying to brute force it assuming it's SCO-###### by running
brand in a loop, but so far no luck either.


Thanks.