Hidden code in DOS - CP/M

[Floppy Software]

It was reported by Pournelle that Kildall demonstrated to him that writing "something" in the DOS prompt, "something" was printed on console, revealing Kildall's copyright.

If that's true, I can't figure how could be done that, having in mind that DOS run in 8086 or 8088 cpus, while CP/M run in 8080 cpu.

They are not compatible at binary level.

What *hidden* algorithm could survive to that architecture change?

Any ideas?

[dxf...@gmail.com]

Here's another.

https://dfarq.homeip.net/did-microsoft-steal-dos-from-cpm/

[Bruce Mardle]

All the CLI would have to do is compare the command with "something" (or "somethin"; CP/M files are '8.3', aren't they?) and act accordingly.
Or, 'encrypt' the command and compare it with an encrption of "something". (That way "something" needn't appear in the binary.)

[Bruce Mardle]

<ramble>That reminds me of the TV series 'Halt and Catch Fire', in which a fictitious company clones the PC BIOS (in a ridiculously longwinded way).
(I like the series title, although the description of it at the start isn't entirely correct. I don't think I have any processors with an HCF, though I do have a 6808, which I think has a 'Drop Dead' instruction :-) )</ramble>

[dxf...@gmail.com]

The problem with reports of hidden stuff buried inside CP/M is that they
appear to come from sources with little background in CP/M.

[Udo Munk]

An even greater problem is, that with all relevant CP/M and 86-DOS sources
available, no suspicious code/data can be found which would hide anything.
Obviously Patterson wrote DOS from scratch in 8086 assembler and just
implemented a CP/M 2 compatible API, so that existing programs can be
converted more easily.

https://github.com/BlastarIndia/msdos/blob/master/v11source/MSDOS.ASM

[Bruce Mardle]

A single 4000-line source file. How wonderful! Tim Paterson is clearly a programmer after my own heart :-)

It seems highly likely to me that Paterson wrote DOS from scratch but I'm reminded of a story about UNIX.
Allegedly, 1 of its creators arranged that every installation of UNIX had a back door allowing him to log in. This was based on code in the executable of `login`, but not the distributed *source* of `login`. When the C compiler compiled the source for `login` it would recognise it as `login` and add the back door code! Of course, the distributed code for the C compiler didn't include *that* code; the distributed executable was based on other source code which did!

[Floppy Software]

That's my exact suspicion about the available CP/M and DOS (not 86-DOS) sources.

Maybe the best path to try to get some light on this, would be doing some disassembling of very early binaries, if available.

[Udo Munk]

On Sunday, September 30, 2018 at 12:56:25 PM UTC+2, Bruce Mardle wrote:

> A single 4000-line source file. How wonderful! Tim Paterson is clearly a programmer
> after my own heart :-)

Don't forget to complain that Kildall put BDOS, disk descriptor tables and BIOS into a single PL/M
source, that later of course needed to be separated ;-)

> It seems highly likely to me that Paterson wrote DOS from scratch but I'm reminded
> of a story about UNIX.
> Allegedly, 1 of its creators arranged that every installation of UNIX had a back door allowing
> him to log in. This was based on code in the executable of `login`, but not the distributed
> *source* of `login`. When the C compiler compiled the source for `login` it would
> recognise it as `login` and add the back door code! Of course, the distributed code for the C
> compiler didn't include *that* code; the distributed executable was based on other source code
> which did!

Well, companies who got a UNIX source distribution also got the compromised compiler
source. For example at Nixdorf that thing was found when working on porting the compiler
sources for different targets.
There have been more subtile backdoors in early UNIX's, like the delete option for the print
spooler, which would delete a file after printing. Because it ran setuid root you would print
and remove /etc/passwd and then quickly replace it with your version with known root
password ;-)

But also stuff like this wasn't done, beside you can examine the PL/M compiler sources
for stuff like this, in CP/M 2 the BDOS and CCP were rewritten in assembler and not
compiled anymore.

[Udo Munk]

On Sunday, September 30, 2018 at 1:23:11 PM UTC+2, Floppy Software wrote:

> That's my exact suspicion about the available CP/M and DOS (not 86-DOS) sources.

Looks like source is the same. Comments talk about 86-DOS while the Copyright text
says MS-DOS. Only name was changed after selling it to Microsoft, besides bug fixes
and improvements.

> Maybe the best path to try to get some light on this, would be doing some disassembling
> of very early binaries, if available.

Has been tried to no avail, early binaries were more accessible than sources for it.

[s_dub...@yahoo.com]

clues in the myst of time...

Intel had a conversion utility to convert 8080 asm to 8086 asm that released early on with the 8088.

XLAT exists for cp/m-80, cp/m-86 to do likewise. I'm not sure if this was the
DRI product. I'm pretty sure Gary worked on that type of utility, just don't know if it was an 'in-house-only' utility. If you xlat the sources for cp/m-80 v.2.2 you get 90% of cp/m-86 v.1.0, I've done enough search & compare of cp/m-86 sources and fragments to think that was DRI's initial tactic. Did 86-dos do likewise? [1].

I have cp/m-86 v.1.0 for the ibm pc. It contains, in the boot sector code, an easter egg written by Dean Ballard, encrypted, to display a message on boot, if the correct pc keyboard keys are being pressed. The code, including message and algorithm and key combo detection, is 64 bytes. Search comp.os.cpm for 'Dean Ballard' discussion. There is no message obvious in a hex dump of the bootstrap code, and if you are not a somewhat seasoned asm programmer, you won't spot it.
Did Gary do the equivalent in bootstrap code that ended up in ms-dos hands?
This is one point to the possible.

[1] The direct xlat of cp/m-80 asm to asm86 has the 'call 5' entry point to BDOS. 86-dos supports it, ms-dos supports it, even cmd.exe supports it, as a parallel (cpm-80) method to some system services.
"
What is at issue is the msdos int 20h
(program terminate), which mimics cp/m-80 'jmp 0'. And the cp/m-80 'Call 5',
mimic which msdos vectors thru a far call to handle cp/m functions (function
number passed in CL, etc.). And msdos int 21h, first 26 functions, more or
less, which are patterned after cp/m. And the internal structures which sup-
port those.
"
The 'call 5' mechanism depends on address 'wrap around' to do its work. This is the cause of the 'one megabyte' address line A20 toggle requirement in later processor systems to be implemented so that ms-dos would still work, rather odd this wasn't orphaned, say by circa msdos v 2.0. The only reason to support this is for XLAT'ed cp/m-80 code emulation.

'IF' it is a bootstrap code issue, then an original image or diskette of the 5 1/4 SSDD 8 SPT of ms-dos 1.0, a very rare bird, is required and be booted on a ibm pc, note that the keyboard of ibm pc isn't compatible with the 'AT' class. First the binary of the bootstrap would have to show that there is an easter egg, and the key combo to display it de-cyphered.

CP/M-86 was done before the ibm-pc, already in use by s100 buss systems. Could have one of these such systems supporting 5 1/4 disk drive, have been used in the dos code production chain to port to 5 1/4 media? Are we certain that FAT12
was used in the earliest versions? My recollection from other articles is that fcb's were used initially, before use of fat12, so was there an oversight in use of a dri bootstrap? -its a stretch. But, if 86-dos used fcbs, possible, as some earliest bootstraps loaded the first file in the directory, without checks. My second point to the possible.

So,
"DOS programmer's Reference" 3rd ed. pg, 271

"
Dos provides two basic ways to deal with files: the FCB method or the handle-function method.

Before DOS V2 was introduced, the file control block (FCB) method (an outgrowth of the old CP/M system) was the only way to access files.
. . .
Handle functions have several advantages over FCB functions:
. . .
o Handle functions can take advantage of DOS's hierarchical directory structure.
. . .
"

This indicates to me a flat file system prior to V2. correct?, with/without FAT?

Paterson seems to say that FAT was from the beginning.

The point is to media interchange. CP/M-80 & CP/M-86 have the same file system,
one can read the others' provided the structure and media is the same. What did
Paterson do to bring up his file system, was the result initially compatible with cp/m? Did 86-dos mistakenly end up on a diskette with Gary's bootstrap?
Yeah, it's a stretch.

"wiki
Seattle Computer Products (SCP) was a Seattle, Washington, microcomputer hardware company which was one of the first manufacturers of computer systems based on the 16-bit Intel 8086 processor.[1] SCP began shipping its first S-100 bus 8086 CPU boards to customers in November, 1979,[2] about 21 months before IBM introduced its Personal Computer which was based on the slower 8088 and introduced the 8-bit ISA bus. SCP shipped an operating system for that hardware about a year before the release of the PC, which was modified by Microsoft for the PC and renamed IBM PC DOS. SCP was staffed partly by high-school students from nearby communities who soldered and assembled the computers. Some of them would later work for Microsoft.
Corporate history
Twenty-two-year-old Tim Paterson was hired in June 1978 by SCP's owner Rod Brock. At the time, SCP built memory boards for microcomputers, but after attending a local seminar on Intel's just-released 8086 in late summer 1978, Paterson convinced Brock that his company should design a CPU board for the new chip. Paterson had a prototype working by May 1979,[3] and he took his "computer" over to Microsoft, who were working on an 8086 BASIC, which was working before the end of May.
...
"

Memory boards were still its main focus when it went out of business.

Didn't ibm-pc initially ship with 512k memory, no disks, with a cassette tape io interface, light-pen support, ibm basic in rom?

Anyway, clues for the mysts of time..

It's my leading theory, an easter egg in the bootstrap (8086) that was mistakenly passed on to a production release. Anyway, I'd love to have the elements together to dispel that.

Steve

[Steve Nickolas]

On Sun, 30 Sep 2018, s_dub...@yahoo.com wrote:

> CP/M-86 was done before the ibm-pc, already in use by s100 buss systems.
> Could have one of these such systems supporting 5 1/4 disk drive, have
> been used in the dos code production chain to port to 5 1/4 media? Are
> we certain that FAT12 was used in the earliest versions? My
> recollection from other articles is that fcb's were used initially,
> before use of fat12, so was there an oversight in use of a dri
> bootstrap? -its a stretch. But, if 86-dos used fcbs, possible, as some
> earliest bootstraps loaded the first file in the directory, without
> checks. My second point to the possible.

MS-DOS 1.x's API used FCBs, but the filesystem was FAT12. My
understanding is that MS-DOS always - even in the 86-DOS days - used some
form of FAT, although there was a flag day when the directory format was
changed.

> This indicates to me a flat file system prior to V2. correct?,
> with/without FAT?

PC DOS 1 & 1.1 and MS-DOS 1.25 used FAT12 as their filesystem, but did not
support subdirectories; there was only one directory on a disk.

> Paterson seems to say that FAT was from the beginning.
>
> The point is to media interchange. CP/M-80 & CP/M-86 have the same file
> system, one can read the others' provided the structure and media is the
> same. What did Paterson do to bring up his file system, was the result
> initially compatible with cp/m? Did 86-dos mistakenly end up on a
> diskette with Gary's bootstrap? Yeah, it's a stretch.

Not likely.

> Didn't ibm-pc initially ship with 512k memory, no disks, with a cassette
> tape io interface, light-pen support, ibm basic in rom?

16K and 64K.

> Anyway, clues for the mysts of time..
>
> It's my leading theory, an easter egg in the bootstrap (8086) that was
> mistakenly passed on to a production release. Anyway, I'd love to have
> the elements together to dispel that.

The PC DOS 1.00 (IBM's version of MS-DOS 1.14) boot sector's been
disassembled. It was written by Robert O'Rear at Microsoft.

http://starman.vertcomp.com/DOS/ibm100/Boot.htm

Pretty sure there's nothing in there that could possibly track down to DR.

-uso.

[dxf...@gmail.com]

On Monday, October 1, 2018 at 7:37:37 AM UTC+10, s_dub...@yahoo.com wrote:
> ...

> CP/M-86 was done before the ibm-pc, already in use by s100 buss systems.

Interesting because I seem to recall reading the claim QDOS was written
*because* DRI was slow in released CP/M for the 8086.

Exactly how much DRI would have gained from CP/M-86 on the IBM is an open
question given the latter's quick transition to DOS 2.x. By the early 80's
CP/M's file interface was looking rather dated.

[Floppy Software]

I think we should focus on 86-DOS, not (IBM- or MS-) DOS.

[Udo Munk]

On Sunday, September 30, 2018 at 11:37:37 PM UTC+2, s_dub...@yahoo.com wrote:

> Intel had a conversion utility to convert 8080 asm to 8086 asm
> that released early on with the 8088.
>
> XLAT exists for cp/m-80, cp/m-86 to do likewise. I'm not sure if this
> was the DRI product. I'm pretty sure Gary worked on that type of
> utility, just don't know if it was an 'in-house-only' utility.

Intel sold xlat86 for 8080 ISIS, don't know if DRI sold it for CP/M-80.

Also Patterson wrote one called TRANS, but much less capable.

> CP/M-86 was done before the ibm-pc, already in use by s100 buss
> systems. Could have one of these such systems supporting 5 1/4 disk
> drive, have been used in the dos code production chain to port to 5 1/4
> media?

Unlikely, Patterson had a booting 86-DOS in 1980 and DRI released
CP/M-86 in 1982.

> Are we certain that FAT12 was used in the earliest versions?

Yep.

> The point is to media interchange. CP/M-80 & CP/M-86 have the
> same file system, one can read the others' provided the structure and
> media is the same. What did Paterson do to bring up his file system,
> was the result initially compatible with cp/m?

He did what everyone does, using a working system to read/write files
from another OS. The 86-DOS 0.3 manual explains that the CP/M and 86-DOS
filesystems are different even with same disk format. So 86-DOS comes
with an utility RDCPM, which reads and transfers files from CP/M disks.

> Did 86-dos mistakenly end up on a diskette with Gary's bootstrap?
> Yeah, it's a stretch.

Very likely it was tried if the boot sector from one can boot the
other OS, does it work?

[dott.Piergiorgio]

this passage from the blog post definitively is for me (top-rank Naval
historian..):

> We know that Kildall had experience with encryption in the Navy in
> the early 1970s. So we have to look at what technologies he would
> have been exposed to. One option is linear feedback shift registers.
> The state of the art at the time were Feistel block ciphers, but
> implementing that on early 8-bit CPUs seems a bit much. Linear
> feedback shift registers likely were good enough for this
> application.


in the Internet archive lies a sizeable collection of thesis from the
very Naval Postgraduate School where Kildall was when CP/M borne (sadly,
Kildall's thesis seems MIA in this archive...) :

> https://archive.org/details/navalpostgraduateschoollibrary

and I add that today's PC horsepower available can tackle a known word
attack against even the Feistel cypher, and we have at least five good
cribs (Gary Kildall Digital Research Copyright).

I'm definitively not interested in ~97K$, so if someone want to tackle
on that prize... ;)

Best regards from Italy,
dott. Piergiorgio.

[dott.Piergiorgio]

well, IIRC that Thompson and Ritchie manages to put a backdoor into
C/Unix, whose remain active until the two disclosed its existence.. two
decades later or so. A backdoor active in an OS ported to more diverse
hardware than CP/M and active from early 1970s to 1990s, and never found
by an entire generation of true hackers.

so I will be cautious on certain type of assertion...

[s_dub...@yahoo.com]

Thanks for the link.

Subsequent sectors up to the directory would show the fat tables.

Note that the text strings end with the last letter having its high
bit set, but this isn't used by the print code.

Note the use of pushing the pointer to the code CDh,18h onto the stack.
This is a jump-on-return to INT 18h, which is the entry to the rom Basic,
which occurs (by this code) if there is an error reading the diskette.

> Pretty sure there's nothing in there that could possibly track down to DR.
>

No, but for completeness the fat tables area up to the directory, and the directory sectors up to the file data should be examined.

There could be deleted directory entries that have their own story to tell.
There could be sectors marked 'bad-do not touch' which may not be so 'bad'.

None of that pertains to accidental DRI code. I give up on the accidental
'dri easter egg' notion since fat is involved.

Steve

> -uso.

[Floppy Software]

Very interesting:

http://starman.vertcomp.com/DOS/ibm090/index.html

It seems that ASM.COM in DOS 0.90, writes CP/M style file records of 128 bytes each.

After assembling HEXTOBIN.ASM into HEXTOBIN.HEX, the website author's says it's so curious that the generated HEX file has 54 EOF characters at the end, instead of only one.

Well, the file size of HEXTOBIN.HEX is 1280 bytes, according to the image he also shows.

Yes, 10 CP/M records of 128 bytes each one!

[s_dub...@yahoo.com]

On Monday, October 1, 2018 at 10:31:40 AM UTC-5, Udo Munk wrote:
> On Sunday, September 30, 2018 at 11:37:37 PM UTC+2, s_dub...@yahoo.com wrote:
>
> > Intel had a conversion utility to convert 8080 asm to 8086 asm
> > that released early on with the 8088.
> >
> > XLAT exists for cp/m-80, cp/m-86 to do likewise. I'm not sure if this
> > was the DRI product. I'm pretty sure Gary worked on that type of
> > utility, just don't know if it was an 'in-house-only' utility.
>
> Intel sold xlat86 for 8080 ISIS, don't know if DRI sold it for CP/M-80.
>
> Also Patterson wrote one called TRANS, but much less capable.
>
> > CP/M-86 was done before the ibm-pc, already in use by s100 buss
> > systems. Could have one of these such systems supporting 5 1/4 disk
> > drive, have been used in the dos code production chain to port to 5 1/4
> > media?

I give up on that notion, with 2 fats, and the need to read io.sys, and
command.com, no.

> Unlikely, Patterson had a booting 86-DOS in 1980 and DRI released
> CP/M-86 in 1982.
>

I'm not so sure development dates, availability. DRI had legal hassels going on, prior to the ibm pc release, perhaps that was the delay for the ibm pc release.

o from: http://patersontech.com/dos/byte%E2%80%93history.aspx
"
In the last few days of 1980, a new version of the DOS was released, now known as 86-DOS version 0.3. Seattle Computer passed this new version on to Microsoft, which had bought non-exclusive rights to market 86-DOS and had one customer for it at the time. Also about this time, Digital Research released the first copies of CP/M-86. In April 1981, Seattle Computer Products released 86-DOS version 1.00, which was very similar to the versions of MS-DOS that are widely distributed today.
"

So this credits CP/M-86 release as much earlier. -'for the s100 buss'-, so to speak.

o fwiw, the lastdri.zip from Gaby's site, disk 23, has CPM.SYS with a copyright
date, in the command buffer, of:

00000080 e9 8a 03 e9 81 03 e9 74 03 7f 00 20 20 20 20 20 |.......t... |
00000090 20 20 20 20 20 20 20 20 20 20 20 43 4f 50 59 52 | COPYR|
000000a0 49 47 48 54 20 28 43 29 20 31 39 38 30 2c 20 44 |IGHT (C) 1980, D|
000000b0 49 47 49 54 41 4c 20 52 45 53 45 41 52 43 48 20 |IGITAL RESEARCH |

Granted, this is in the CCP.

The disk 23 is work for hard drive support (Cartridge Disk Controller).
This bios has a date of "16 Apr '81" for (this) hard drive support.


ASM86 VER 1.0 SOURCE: FDBIOS.A86 BIOS For iSBC86 w/ cartridge d PAGE 1


title 'BIOS For iSBC86 w/ cartridge disk'

; BIOS for CP/M-86 using Deblocking

; Configured for the Intel SBC 86/12 CPU board,
; the Xylogics C410 Cartridge Disk Controller
; (with a CDC Hawk type Cartridge drive),
; and the Intel SBC204 diskette controller

; 16 Apr '81 already! ; JRP

So before the August 1981 ibm pc announcement, and months before microsoft
secured rights to 86-dos, cp/m-86 with hard drive support, in some form, was available.

I find less fault with DRI on this 'availability' issue. The fact (as they
state it) the 2 Seattle prototypes were available, one for Seattle, one for
microsofts' 8086 Basic, orphans DRI.

from: https://en.wikipedia.org/wiki/Seattle_Computer_Products
Granted the source, but as to time-line;
"
86-DOS was created because sales of the Seattle Computer Products 8086 computer kit, demonstrated in June 1979 and shipped in November,[1] were languishing due to the absence of an operating system. The only software which SCP could sell with the board was Microsoft's Standalone Disk BASIC-86, which Microsoft had developed on a prototype of SCP's hardware.[1] SCP wanted to offer the 8086-version of CP/M that Digital Research had announced, but its release date was uncertain.[2] This was not the first time Digital Research had lagged behind hardware developments; two years earlier it had been slow to adapt CP/M for new floppy disk formats and hard disks. In April 1980 SCP assigned 24-year-old Tim Paterson to develop a substitute for CP/M-86
"

By nov 1979, the cpu card was shipping with ms basic-86, so could not Seattle
have loaned one to DRI?, Seattle declined DRI:

http://patersontech.com/dos/encyclopedia.aspx
"
Among 8-bit computers, the CP/M operating system from Digital Research had become the standard. Digital Research was known to be working on a 16-bit version for the 8086 microprocessor, CP/M-86, and had expressed interest in using a prototype of the SCP 8086 CPU card to aid in their development (SCP declined). CP/M-86 was expected to be available by the end of 1979.
"

Finger pointing and excuses - history belongs to the victor I guess.

I mean there was a period of time, nov 1979 to april 1980 before 86-dos
work was sanctioned, where co-operation with DRI could have born fruit.
If, as they say, DRI approached Seattle, DRI shows interest, initiative.

As I maintain, xlat of cpm-80 gets you 90% of cpm-86, so at least that
much was done by late 1979, as they expected a late 79 release.

> > Are we certain that FAT12 was used in the earliest versions?
>
> Yep.
>
> > The point is to media interchange. CP/M-80 & CP/M-86 have the
> > same file system, one can read the others' provided the structure and
> > media is the same. What did Paterson do to bring up his file system,
> > was the result initially compatible with cp/m?
>
> He did what everyone does, using a working system to read/write files
> from another OS. The 86-DOS 0.3 manual explains that the CP/M and 86-DOS
> filesystems are different even with same disk format. So 86-DOS comes
> with an utility RDCPM, which reads and transfers files from CP/M disks.
>
> > Did 86-dos mistakenly end up on a diskette with Gary's bootstrap?
> > Yeah, it's a stretch.
>
> Very likely it was tried if the boot sector from one can boot the
> other OS, does it work?

Not to mind, now that I've examined things more, with 2 fat areas, and 3 file
loads to bootstrap dos.

Just this is interesting:
o cp/m block 0 is the directory area, block references include the directory.
o fat blocks 0,1 are reserved and not used, first used is blk 2, which is not
the directory but the first file data area.
o possibly 2 blocks for cpm directory, being reserved blocks under 86/ms-dos.

Steve

[Floppy Software]

I will reply to myself.

In the dissasembled ASM.COM v2.24 (shipped with 86-DOS), you can see how it writes the HEX file as CP/M style file records, using CP/M BDOS function numbers:

L13DF: PUSH CX
PUSH DX
PUSH BX
CALL 0005 <--- NOTE THIS!
POP BX
POP DX
POP CX
RET

...
L148F: MOV AL,0Dh
CALL L1496
MOV AL,0Ah
L1496: MOV BX,[D1A68]
MOV [BX],AL
CALL L14E1
MOV [D1A68],BX
JNZ L14E0
PUSH BX
MOV BX,D1A72
MOV AL,[BX]
MOV B, [BX],00
POP BX
OR AL,AL
JNZ L14E0
MOV CL,1Ah
XCHG DX,BX
CALL L13DF
MOV DX,D19B3
MOV CL,15h <--- NOTE THIS!
CALL L13DF <--- NOTE THIS! CALL BDOS, SEE ABOVE
XCHG DX,BX
OR AL,AL
JZ L14E0
L14C8: MOV BX,D1951
JMP L0268


But in the sources of ASM.COM v2.44 (shipped with MSDOS v1.1), we can see how it writes HEX files with "new" DOS functions / style:

MOV AL,13
CALL PUTCHR
MOV AL,10
CALL PUTCHR
WRTHEX:
;Write out the line
MOV DX,HEXBUF
MOV [HEXPNT],DX
MOV AH,SETDMA
INT 33
SUB DI,DX ;Length of buffer
MOV CX,DI
MOV DX,HEXFCB
MOV AH,BLKWRT
INT 33
OR AL,AL
JNZ DSKFUL
RET

We can see in the source code of v2.44 the following comments:

; 08/02/81 2.30 Re-write pass 2:
; Always report errors to console
; Exact byte lengths for HEX and PRN files

Note the last line.

Interesting, it'sn it?