| |
David Hughes
Account closed
Registered: Jul 2016
Posts: 5 |
Release id #149377 : DTL Basic
As far as I can recall someone cracked the security around 1983/84 or so.
I got the impression that he wasn't seeking to benefit from it rather he just saw it as a challenge or was annoyed by the idea of security on software. He contacted me to let me know he had done it which he probably wouldn't have done if he was seeking to profit from it.
It is certainly possible to break the security if you are persistent enough and trace through from the entry point and have good enough tools to analyse what is going on. Whether it is worth the effort now is another matter!
From what I remember the first part of the security was at several separate places in the normal initialisation code one or two bytes are overwritten in an otherwise unused section of code. The end result being a short (two or three instructions maybe) section of code that has been created dynamical; these instructions are then executed and are essential in some way to passing the security checks later.
I'm pretty sure that later on there is also some sort of checksum done on that section of code to detect simple patches.
Also, I tried to avoid there being a simple test of the number read from the dongle against a constant. So it may be that there is a section of code that is encrypted and has to be decrypted using the number read from the dongle.
All these features mean that several changes are probably needed to disable the patches. |
|
| |
David Hughes
Account closed
Registered: Jul 2016
Posts: 5 |
I believe that the dongles used with DTL Basic were originally designed by the authors of the Wordcraft word processor that was very successful on CBM machines (in fact they claimed to have invented the term 'dongle'). Both Wordcraft and DTL Basic were marketed by Dataview who were based Colchester, UK and Dataview manufactured the dongles.
My understanding was that the dongle itself was some sort of simple shift register chip encased in resin. The serial number was set by snipping off the appropriate legs of the chip. |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Hi David.
I have written a decompiler for DTL version 64.4 and have some questions I'd like you to answer if you have time.
Was Speedwriter the US marketing name for the compiler? I noticed that redefining the ZX% variable changes the displayed program name in the compiler.
Another variable (PX) controls PROTECTOR feature. I guess that was used to tie the compiled program with dongle with given key?
It was also interesting to see that you could change the disk-based compiler into tape compiler with single variable. That makes sense, as it kept both versions in sync, although there is some extra code because of supporting both in the same program.
The dongle itself is indeed a 16-bit shift register, I think the reason it doesnt work in VICE is that emulation lacks the reset feature triggered with one of the cassette port signals. When I have time I will dig out the dongle and write more complete example program for blacky so he can fix VICE. |
| |
Count Zero
Registered: Jan 2003
Posts: 1920 |
TNT: wondering - got other versions rather than
ftp://ftp.zimmers.net/pub/cbm/pet/programming/dtl-basic.lnx.gz or what I found on my HD: http://ftp.pokefinder.org/tmp/dtl-findings.rar (includes d64 of the zimmers .lnx.gz) ?
Never really cared to take a closer look on DTL. The Archive from the ftp looks "stripped" (as for files) over the "original disk dump". |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
The large (20 KB'ish) compiler is likely the PET version, C64 version is version 64.4, possibly from my dump - http://sid.fi/~tnt/dtl/ |
| |
David Hughes
Account closed
Registered: Jul 2016
Posts: 5 |
Quote: Hi David.
I have written a decompiler for DTL version 64.4 and have some questions I'd like you to answer if you have time.
Was Speedwriter the US marketing name for the compiler? I noticed that redefining the ZX% variable changes the displayed program name in the compiler.
Another variable (PX) controls PROTECTOR feature. I guess that was used to tie the compiled program with dongle with given key?
It was also interesting to see that you could change the disk-based compiler into tape compiler with single variable. That makes sense, as it kept both versions in sync, although there is some extra code because of supporting both in the same program.
The dongle itself is indeed a 16-bit shift register, I think the reason it doesnt work in VICE is that emulation lacks the reset feature triggered with one of the cassette port signals. When I have time I will dig out the dongle and write more complete example program for blacky so he can fix VICE.
I don't recall the name Speedwriter and as far as I know the marketing name was always DTL Basic and JetPack on tape.
To be honest I don't recall how the dongle number was encoded though I wouldn't have thought that it would be simply held in a variable. I think I would have done something like read the key number and then use it to unscramble an encrypted bit of code.
I'm sure you are right about there only being one version for both tape and disk. I've always been very keen to just have one set of sources as far as is possible.
I never really took much interest in the tape version as it seemed too slow/tedious to be of much practical use; so I'm pleased if some games were successfully compiled with it! |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Here is the normal startup screen
When I patch the code with "ZX%=1" I get
Furthermore, a compiler comparison in Commodore Microcomputer says "The Drive Technology Ltd. (DTL) 64 Compiler by David Hughes is an improved and upgraded version of the DTL BASIC Compiler originally developed for the PET series. It is being marketed in the U.S. by two companies under two different names that I'm aware of: Microsci as InstaSpeed and by Codewriter as SpeedWriter)." Article here.
I guess I wasn't too clear about the PROTECTOR feature. I didn't mean the compiler protection itself which indeed is quite evil. It uses the RTL features to decrypt the protection code, grab the key ID from dongle, re-encrypt the dongle code and then use the ID in several places, for example for decrypting GOTO destinations.
I meant the feature where you presumably can protect the compiled program itself. Again, patching code with "PX=1" gives this starting screen
 |
| |
David Hughes
Account closed
Registered: Jul 2016
Posts: 5 |
Ha Ha, it looks like you are correct about SpeedWriter.
I must have implemented that feature but don't recall it at all!
It looks like you are right about the Protector feature too; users could compile programs that were unprotected or were to be protected with a specific key (dongle). We (i.e. Dataview) then made a bit of money supplying the dongles. |
| |
Fierman
Registered: Feb 2002
Posts: 85 |
copypaste from DTL Jetpack BASIC
There are two different versions of DTL Basic it seems.
A tape one and a disk one. The tape one is not protected by a dongle, but is missing a lot of functionality.
I have the original of the tape here, including manual.
Cleaned tap images:
https://fierman.org/c64/tape/clean.dtl-basic_1983_side_a.tap
https://fierman.org/c64/tape/clean.dtl-basic_1983_side_b.tap
Quick&dirty scan of tapecover+manual:
https://fierman.org/c64/tape/dtl-basic_tape_manual_1983.pdf |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Thanks Fierman. Tape version identifies itself as version 64.4 but lacks some of the disk specific lines. I will check later if the compiled code is identical to the version I've got.
The run-time library is different as well, but as the protected programs have some bytes EORed with the dongle code one can't just replace the rtl file and unprotect the disk version.
I remember reading a review of tape version which used the dongle - one of the downsides mentioned was the need to remove cassette player and insert the dongle while C64 was powered on. |
