Jump to content
DjayBee

Microsoft BASIC or Microsort BASIK? - Going down a rabbit hole

Recommended Posts

A few days ago @AGiambramade a post in the Programming subforum  that he found an interesting copy protection in Microsoft Basic for the Atari.

 

The floppy has a second directory in sector $179 which is active at boot time and from which Basic is loaded as AUTORUN.SYS. During the initialization of the program, DOS is patched to use the normal directory again.
At first I was a bit irritated because I knew that Microsoft Basic uses missing sectors (364 and 380) as copy protection, but then I examined the image.

 

It turned out that there are indeed two almost identical copies of BASIC on the disk. The version in the official directory is a fake and expects sector 720 to be missing and then aborts with a warm start anyway.
In the debugger it turned out that sector 361 must also be missing, but this is not true. 361 is the first sector of the directory and therefore ok.

 

After I had cracked the copy protection, the program still did not run, but continued to perform a warm start.
This was not surprising because the start address in INITAD ($2e2) is the warm start vector $e474.
Very strange!

 

I had found out before that both programs are nearly identical and differ in their RAM addresses only by 0-3 bytes. So I looked where INITAD points to in the real Basic ($6851) and searched around this address in the fake version. Bingo, at $684e there is identical code.
After setting the INITAD of the fake version to $684e, I got the following output:

 

grafik.thumb.png.e8c792371cd055ca17d7d1f0745ff71c.png

 

The two-liner was just a test to see if the interpreter does anything useful.
As you can see, it was successful. I have not done any further tests with it yet.
Maybe a reader has a somewhat larger program that runs on the Atari with Microsoft BASIC, and tries it out.

 

No, I did not patch the system message "ATARI 800 BASIC V2.7 (C) 1981 MICROSORT" into the program. That's exactly what it says on the original disk Atari supplied. The real version btw. is V1.0.
The basis for my investigation is the verified(!) image from a8preservation.com.

 

If anyone wants to play around with it, here is my crack of the disk.

 

Microsoft BASIC (1981)(Atari)(US)[!][cr CSS].atr

 

To run the fake version, boot the floppy into (real) MS Basic and then go into DOS.

Next manually run the fake AUTORUN.SYS.

 

Meanwhile I'm still trying to find out where exactly the differences between the two versions are and where the shift of the code by a few bytes in RAM comes from.

Edited by DjayBee
  • Like 6

Share this post


Link to post
Share on other sites

If you press SYSTEM RESET while running the fake version, you get a blue screen and the system hangs.  Since the real AUTORUN.SYS is in a hidden directory and we have already come up with a solution on how to extract it, I am not sure there is any value in trying to get the fake version to run.  It's obviously been booby trapped.  Simply extract the real version using the technique I mentioned in my original post and you're done.

Share this post


Link to post
Share on other sites
11 minutes ago, AGiambra said:

I am not sure there is any value in trying to get the fake version to run.

Of COURSE there is.  It's interesting in and of itself that they created a "fake" version.  Stuff like that is far more interesting to many of us that just using Microsoft BASIC, LOL!

  • Like 5

Share this post


Link to post
Share on other sites

You're right.  I myself have spent hours figuring out how to extract Microsoft Basic and the truth is i never even use it!  Hah hah

  • Haha 1

Share this post


Link to post
Share on other sites

So pretend it is 1982 again (and most of us didn't know much of anything about copy protection)... If you had an original disk and did a sector copy (say David Young's magical "SuperDup" Dos, would it work properly?  Or if you replaced the Dos 2.0 on the disk with an unaltered version, would that work as did the original disk?  IIRC, I never thought of much about the Autorun.Sys file -- you just had to reboot.

 

I bought MSB I early on, but at the moment I can't locate my original.  I have a backup, and will check it, but it may not be the same as yours.

Share this post


Link to post
Share on other sites

I too have lost my copy of the original.  If you locate your backup i would be interested in having a copy if you wouldn't mind attaching it.

Share this post


Link to post
Share on other sites

Will do.  Are you the AGiambra that wrote several articles for Analog/Antic?

 

BTW, I find this MSB topic very interesting -- brings back 1982!

  • Like 1

Share this post


Link to post
Share on other sites

 

I love a topic like this, the actual workings are so much more fun than the product being worked on, MS Basic / k, never gave it a thought to use, but reading about the funky protection, seriously more fun.

  • Like 1

Share this post


Link to post
Share on other sites

Yes I'm that guy that wrote Magic Spell, DOSCD, Bline and a bunch of other articles that were published in both Analog and Antic Magazines.  I had a lot of fun back then.

 

Here is a disk with an Assembler version of the Microsoft Basic copy program.  Just run it and follow the directions.

Copy Microsoft Basic.atr

  • Like 11

Share this post


Link to post
Share on other sites
3 hours ago, AGiambra said:

If you press SYSTEM RESET while running the fake version, you get a blue screen and the system hangs.  Since the real AUTORUN.SYS is in a hidden directory and we have already come up with a solution on how to extract it, I am not sure there is any value in trying to get the fake version to run.  It's obviously been booby trapped.  Simply extract the real version using the technique I mentioned in my original post and you're done.

My analysis is not about the copy protection but curiosity about the fake version and particularly the weird easteregg-like copyright string it shows.

  • Like 1

Share this post


Link to post
Share on other sites

Both binries consist of more than 90 separate load segments!

This ensures that DOS will not load the program quickly in "burst mode" but quite slowly.

 

These are the 96 segments of the "real one" as output of vitoco's great tool xex-filter.pl (The fake has one less segment):

 

Spoiler

Analyzing "AUTORUN1.xex"...
-: 65535 [$FFFF] (binhead)
1: 65-65 [$0041-$0041] (1) $00 "00000000" ====> disable SIO sound
-: 65535 [$FFFF] (binhead)
2: 743-744 [$02E7-$02E8] (2) -> 27136 [$6A00] ====> MEMLO=$6A00
-: 65535 [$FFFF] (binhead)
3: 7680-7755 [$1E00-$1E4B] (76) PROG/DATA
4: 738-739 [$02E2-$02E3] (2) -> 7680 [$1E00] ====> send SIO command $3F to the drive (NAKs always in Altirra)
5: 8360-8379 [$20A8-$20BB] (20) PROG/DATA
6: 12147-12870 [$2F73-$3246] (724) PROG/DATA
7: 12882-12899 [$3252-$3263] (18) PROG/DATA
8: 18226-19149 [$4732-$4ACD] (924) PROG/DATA
9: 13830-13840 [$3606-$3610] (11) PROG/DATA
10: 13887-13904 [$363F-$3650] (18) PROG/DATA
11: 8361-8374 [$20A9-$20B6] (14) PROG/DATA
12: 10120-10120 [$2788-$2788] (1) $31 "00110001"
13: 9075-9082 [$2373-$237A] (8) PROG/DATA
14: 8165-8358 [$1FE5-$20A6] (194) PROG/DATA
15: 9081-9089 [$2379-$2381] (9) PROG/DATA
16: 10121-10122 [$2789-$278A] (2) -> 20993 [$5201]
17: 9090-9118 [$2382-$239E] (29) PROG/DATA
18: 25717-26765 [$6475-$688D] (1049) PROG/DATA
19: 8363-8364 [$20AB-$20AC] (2) -> 16384 [$4000]
20: 10123-10124 [$278B-$278C] (2) -> 16384 [$4000]
21: 17763-17778 [$4563-$4572] (16) PROG/DATA
22: 24960-24972 [$6180-$618C] (13) PROG/DATA
23: 17779-17797 [$4573-$4585] (19) PROG/DATA
24: 14774-15847 [$39B6-$3DE7] (1074) PROG/DATA
25: 8365-8378 [$20AD-$20BA] (14) PROG/DATA
26: 24962-24964 [$6182-$6184] (3) PROG/DATA
27: 10125-10142 [$278D-$279E] (18) PROG/DATA
28: 9652-9993 [$25B4-$2709] (342) PROG/DATA
29: 8368-8372 [$20B0-$20B4] (5) PROG/DATA
30: 10128-10129 [$2790-$2791] (2) -> 128 [$0080]
31: 24965-24974 [$6185-$618E] (10) PROG/DATA
32: 22346-23248 [$574A-$5AD0] (903) PROG/DATA
33: 24968-24978 [$6188-$6192] (11) PROG/DATA
34: 10130-10142 [$2792-$279E] (13) PROG/DATA
35: 8370-8378 [$20B2-$20BA] (9) PROG/DATA
36: 7747-7790 [$1E43-$1E6E] (44) PROG/DATA
37: 12870-13220 [$3246-$33A4] (351) PROG/DATA
38: 24971-24986 [$618B-$619A] (16) PROG/DATA
39: 9051-9379 [$235B-$24A3] (329) PROG/DATA
40: 8371-8383 [$20B3-$20BF] (13) PROG/DATA
41: 13888-13891 [$3640-$3643] (4) PROG/DATA
42: 20608-20620 [$5080-$508C] (13) PROG/DATA
43: 19149-20322 [$4ACD-$4F62] (1174) PROG/DATA
44: 13892-13903 [$3644-$364F] (12) PROG/DATA
45: 21056-21063 [$5240-$5247] (8) PROG/DATA
46: 20619-20635 [$508B-$509B] (17) PROG/DATA
47: 17730-17748 [$4542-$4554] (19) PROG/DATA
48: 16387-16914 [$4003-$4212] (528) PROG/DATA
49: 17824-17834 [$45A0-$45AA] (11) PROG/DATA
50: 738-739 [$02E2-$02E3] (2) -> 20608 [$5080] ====> check for 1st bad/missing sector
51: 13904-13917 [$3650-$365D] (14) PROG/DATA
52: 16000-16027 [$3E80-$3E9B] (28) PROG/DATA
53: 13376-13393 [$3440-$3451] (18) PROG/DATA
54: 10503-11459 [$2907-$2CC3] (957) PROG/DATA
55: 17835-17851 [$45AB-$45BB] (17) PROG/DATA
56: 738-739 [$02E2-$02E3] (2) -> 13888 [$3640] ====> check for 2nd bad/missing sector
57: 17232-17239 [$4350-$4357] (8) PROG/DATA
58: 23248-24517 [$5AD0-$5FC5] (1270) PROG/DATA
59: 21312-21348 [$5340-$5364] (37) PROG/DATA
60: 738-739 [$02E2-$02E3] (2) -> 17824 [$45A0] ====> check for 3rd bad/missing sector
61: 21384-21433 [$5388-$53B9] (50) PROG/DATA
62: 8358-8626 [$20A6-$21B2] (269) PROG/DATA
63: 9392-9489 [$24B0-$2511] (98) PROG/DATA
64: 13220-13810 [$33A4-$35F2] (591) PROG/DATA
65: 11488-11513 [$2CE0-$2CF9] (26) PROG/DATA
66: 25155-25717 [$6243-$6475] (563) PROG/DATA
67: 17216-17269 [$4340-$4375] (54) PROG/DATA
68: 11459-12147 [$2CC3-$2F73] (689) PROG/DATA
69: 26848-26900 [$68E0-$6914] (53) PROG/DATA
70: 7935-8165 [$1EFF-$1FE5] (231) PROG/DATA
71: 17746-17756 [$4552-$455C] (11) PROG/DATA
72: 26765-27010 [$688D-$6982] (246) PROG/DATA
73: 9379-9652 [$24A3-$25B4] (274) PROG/DATA
74: 21248-21340 [$5300-$535C] (93) PROG/DATA
75: 21045-22346 [$5235-$574A] (1302) PROG/DATA
76: 13840-13904 [$3610-$3650] (65) PROG/DATA
77: 16914-17561 [$4212-$4499] (648) PROG/DATA
78: 17920-18013 [$4600-$465D] (94) PROG/DATA
79: 8626-9051 [$21B2-$235B] (426) PROG/DATA
80: 18048-18113 [$4680-$46C1] (66) PROG/DATA
81: 13810-14774 [$35F2-$39B6] (965) PROG/DATA
82: 4226-4226 [$1082-$1082] (1) $69 "01101001" ====> re-set start of directory to sector $169
83: 20480-20501 [$5000-$5015] (22) PROG/DATA
84: 9993-10503 [$2709-$2907] (511) PROG/DATA
85: 24576-24681 [$6000-$6069] (106) PROG/DATA
86: 24517-25155 [$5FC5-$6243] (639) PROG/DATA
87: 7680-7782 [$1E00-$1E66] (103) PROG/DATA
88: 20322-21045 [$4F62-$5235] (724) PROG/DATA
89: 17920-17937 [$4600-$4611] (18) PROG/DATA
90: 17561-18226 [$4499-$4732] (666) PROG/DATA
91: 65-65 [$0041-$0041] (1) $03 "00000011" ====> enable SIO sound
92: 15872-15942 [$3E00-$3E46] (71) PROG/DATA
93: 15847-16387 [$3DE7-$4003] (541) PROG/DATA
94: 27008-27055 [$6980-$69AF] (48) PROG/DATA
95: 27072-27087 [$69C0-$69CF] (16) PROG/DATA
96: 738-739 [$02E2-$02E3] (2) -> 26705 [$6851] ====> run MS Basic
-: 54116-7552 [$D364-$1D80]

 

 

I reduced this to seven (SIO off, MEMLO, SIO $3F code and run, main program, SIO on main program RUN) which allows burst-mode to kick in and reduces the file size by some 600 bytes.

 

Microsoft BASIC.xex  Microsort BASIK.xex

 

I successfully tried these binaries with DOS 2.5 and MEM.SAV. (As AGiambra already stated, the fake crashes upon RESET.)

 

================

 

I stated in my first posting that both binaries are nearly identical.

This screenshot shows the similarity of the two binaries in a more striking way. It is taken from a binary diff of the two files and shows a section of the first third.

 

grafik.thumb.png.4cb5d5ff28c38232c62174674f8db8e8.png

 

Only the bytes highlighted in red differ.

Nearly all are 16-bit addresses whose values differ only by 1-3.
Only the two places with a hatch ($193b and $196a) were inserted in the other binary.

 

For me this is also a clear proof that it is not a later hack, but was assembled from the original - but of course slightly changed - source code.

  • Like 5

Share this post


Link to post
Share on other sites

I then asked Kay @Savetz if he had interviewed anyone involved with the Atari port of Microsoft Basic.

Sure he did: https://ataripodcast.libsyn.com/antic-interview-77-tandy-trower-atari-product-manager

 

Tandy Trower was first Product Manager for MS Basic at Atari and then switched sides to become Product Manager for the Atari port of MS Basic at Microsoft.

 

Unfortunately he could not contribute much either.

Quote

Not certain I can be of much help here. The fact both BASIC and Microsoft are misspelled makes me think this is either a bogus/fake version of BASIC which could have written in 6502 assembly code or even BASIC (either the original Shepherdson or Microsoft) so that it looks like BASIC but really isn’t, or perhaps a corrupted disk file (floppies we’re notorious for dropping bits over time). To determine which would like take trying to write a longer program of perhaps disassembling the file.

 

In any case this doesn’t look like anything I recall and I don’t recall the developer creating Easter eggs in pre-release copyright signatures for startup.

 

Finally, the developer who worked on Microsoft BASIC for Atari isn’t alive, so I couldn’t even ask him.

 

Bit rot can be ruled out because my “work” is based on the verified(!) dump from a8preservation.com's database.


It is also certainly not somebody’s fake since it is on the original disk from Atari.

And it as certainly was made from the same source code as the real thing.

  • Like 4

Share this post


Link to post
Share on other sites
1 hour ago, DjayBee said:

1: 65-65 [$0041-$0041] (1) $00 "00000000" ====> disable SIO sound
91: 65-65 [$0041-$0041] (1) $03 "00000011" ====> enable SIO sound
-: 54116-7552 [$D364-$1D80]

I think these can be safely removed, especially that crap's at the end only purpose seems to be just obfuscating things, if I am not mistaken.

 

1 hour ago, DjayBee said:

2: 743-744 [$02E7-$02E8] (2) -> 27136 [$6A00] ====> MEMLO=$6A00

This could be moved to the end, just before the last init, perhaps; otherwise the binary does not load in SDX. The result of the operation:

 

MSBASIC.EXE

 

This one loads under SDX and appears to run:

 

obraz.thumb.png.a774d61b9df3e507e203a5cefb4f54f3.png

 

Edited by drac030
  • Like 5

Share this post


Link to post
Share on other sites

there are two versions of Miscrosoft Atari BASIC, the second version would be nice to see fixed up in these ways as well.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, DjayBee said:

It is also certainly not somebody’s fake since it is on the original disk from Atari.

And it as certainly was made from the same source code as the real thing.

My take on why there were two versions of the AUTORUN.SYS was like this:

 

We know the original Microsoft Basic disk had bad sectors.  So obviously they wanted to prevent people from physically copying the disk.  But someone must have said, "Yeah, maybe they can't copy the entire disk, but they can format a new disk and copy the AUTORUN.SYS file to it."

 

So they came up with the hidden directory scheme so that, if some did in fact copy the AUTORUN.SYS file to another disk, all they'd get was a garbage copy that wouldn't run.

Share this post


Link to post
Share on other sites
30 minutes ago, Larry said:

The cartridge version, or two disk versions?

 

There was only one disk version of Atari Microsoft Basic, the original version.  The second version of Microsoft Basic (called Microsoft Basic II) came on a cartridge.  It also came with a disk but the disk did not contain the Basic program.  It contained extensions that the new version used.  You could run from the cartridge without the extension disk, but if you used the extension disk then you got a little more functionality out of it.

  • Like 2

Share this post


Link to post
Share on other sites
5 hours ago, _The Doctor__ said:

there are two versions of Miscrosoft Atari BASIC, the second version would be nice to see fixed up in these ways as well.

There's already a functional executable version of Microsoft BASIC II.

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, drac030 said:

 

You probably figured this out already but everything from $D364-$1D80 to the end can be eliminated.  Once it hits the final $2E2-$2E3 heading, it's done and simply ignores the trailing bytes.  I created a new version when I chopped off those final bytes (around 281 of them) and it loads fine and works fine.

 

What a bunch of fun this topic has been.  Thanks to everyone for all your contributions.

Share this post


Link to post
Share on other sites
5 minutes ago, AGiambra said:

You probably figured this out already but everything from $D364-$1D80 to the end can be eliminated.

Yes, the version I posted above (in post #15) has that tail already cut off. Also the writes to $41 have been eliminated.

Share this post


Link to post
Share on other sites

My final posting for today about the differences between both binaries.

 

In each of the screenshots, the "real" version is on the right and the fake is on the left.

 

Irrelevant examples:

 

diff-error1.thumb.png.d0939c7f29e66cf1a4a8e56a22fef2bf.png

 

diff-error2.thumb.png.cf92402dd05ea84b27742c8aea0e0581.png

 

At first glance I thought that there were more differences between the two binaries.
But a closer look revealed that in the above examples only my diff program is out of sync and the changes are in fact again only due to the code shift by a few bytes.

 

Apparently*) there are actually only the five real differences visible below plus the copyright text.

 

msbasic-codediff.thumb.png.8a848daeb0e606ff923adb217e1f4faf.png

 

*) I didn't examine every line of the source code exactly, but only looked if the differences are more than just the (mostly) last digit of the 16-bit addresses.

 

The changes visible above rather indicate a slightly older version of the interpreter, which was subsequently and intentionally screwed up with the non-functioning copy protection, the meaningless start address and probably the above NOP.
The NOP causes the program to hang when RESET is pressed.

 

==

 

To do the analysis, I loaded both programs into Altirra, disassembled the complete memory from $1E00-$69CF using Altirra and finally, to improve readability, replaced all obvious non-code areas with hex/ASCII dumps.
The "red" screenshot above shows excerpts from these files.

 

Microsoft BASIC.asm  Microsort BASIK.asm

 

For the "diffing" I removed the memory addresses and opcodes because then there are much less textual differences. The "yellow" screenshots above were created with these files.

 

Microsoft BASIC-noopcodes.asm  Microsort BASIK-noopcodes.asm

Edited by DjayBee
  • Like 3

Share this post


Link to post
Share on other sites
23 hours ago, Larry said:

So pretend it is 1982 again (and most of us didn't know much of anything about copy protection)... If you had an original disk and did a sector copy (say David Young's magical "SuperDup" Dos, would it work properly?

No, it would not because of the protection using missing/bad sectors.

 

But if you extract the binary using AGiambra's tool or use one of the XEXs provided by me or drac030, it should work.

I tried my XEX successfully in DOS 2.5.

  • Thanks 1

Share this post


Link to post
Share on other sites
2 hours ago, DjayBee said:

one of the XEXs provided by me or drac030

"Mine" is actually yours. I only applied few amendments, among which the most important (for me at least) is the one which makes it run under SDX :)

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...