adb use on xenix 3.0?

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.