info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
I have found a practical way to recover the long-missing TOPS-10 Fortran V11 patch decryption keys - Here is how
252 views
Skip to first unread message
G.
Apr 15, 2020, 1:56:56 AM4/15/20
to
Dear all,
as many of you may know, the TOPS-10 Fortran V11 tape image
available in the usual repositories is truncated because the original tape
reel from which it was sourced (BB-D480G-SB) was found to be damaged.
Luckily enough, the first four savesets (out of seven) were indeed readable,
therefore the V11 compiler is in fact available. Unfortunately, one of the
missing savesets (the seventh) contains the keys required to decode TSU tape
patches. Therefore, even if TSU tapes are available and completely readable,
their contents could not be used because they are encrypted.
Nonetheless, after much pondering and careful observing, and thanks to some
good guess, I was able to reconstruct the most important missing keys :)
Since both TOPS-10 and TOPS-20 Fortran compilers share the vast majority of
their sources, my first idea was to build the updated TOPS-10 Fortran
compiler from scratch with TOPS-20 sources from the latest TSU tape, but I
soon found it to be a too complex task because, among other things, some
TOPS-10-specific sources were missing. I would have had to use those from
some old field test tape available in the repository, but I was afraid that
the resulting compiler (if buildable at all) could have been a weird
bug-ridden hybrid. So I had to find a different route. Since I was there, I
also verified that TOPS-20 keys (which have always been available) do not
work with TOPS-10 products.
By observing the keys for other products I noticed that they are wildly
different in size and are usually pretty large, some are several hundred
blocks long, therefore I speculated that the encryption may have been just
some simple XOR of keys and sources. This means that XORing any cleartext
file with its corresponding encrypted version yields the key.
Since I could not directly recover the key for the patched compiler binaries
because I didn't have a suitable cleartext copy of any encrypted binary, I
had to follow a more circuitous route.
The solution comes from the fact that, as I said above, TOPS-10 and TOPS-20
Fortran compilers share the vast majority of their source files, which also
happen to be among the largest of the whole Fortran distribution. Also, most
important, the updated runtime sources come with their respective compiled
counterparts, i.e. REL files. Finally, runtime binary modules are contained
in the runtime sources saveset, whereas the resulting library is contained
in the binaries saveset.
So, here is a summary of the required steps.
1. First of all, on TOPS-20, restore the TOPS-20 Fortran V11 runtime key,
namely FORLIB.KEY, from the product distribution tape BB-4157J-BM.
2. Then, still on TOPS-20, restore the largest updated source of the Fortran
V11 runtime and the decryption tool, namely FOROPN.MAC and DCRYPT.EXE, from
TSU tape 04 (volume 1 of 2) BB-PENEA-BM.
3. Then, again on TOPS-20, use DCRYPT to obtain a plaintext version of
FOROPN.MAC, and call it e.g. FOROPN.T20.
4. Finally, transfer FOROPN.T20 to TOPS-10. If you do not have a working
DECnet network available you could use a tape image. The standard TOPS-20
backup program, DUMPER.EXE, could write (and read) TOPS-10 BACKUP tapes when
instructed to do so with the INTERCHANGE command. Note that the same
INTERCHANGE command in TOPS-10 BACKUP.EXE has another (unrelated) meaning.
5. Now on TOPS-10, restore the original (unpatched) TOPS-10 Fortran V11
runtime files from the truncated tape BB-D480G-SB. In fact they are in the
fourth saveset, i.e. the last readable one. Then, in the same directory,
restore the updated Fortran runtime files from TSU tape 04 (volume 3 of 3)
BB-PBDED-BB. The directory on tape is DSKB:[10,7,FTNOTS]. Several old files
will be overwritten with new patched and encrypted updated copies.
6. Restore tools APUTIL.EXE and DCRYPT.EXE from TSU tape 04 (volume 1 of 3)
BB-BT99V-BB. APUTIL and DCRYPT do basically the same thing, but APUTIL is
list-driven and could verify checksums, whereas DCRYPT does just one file at
a time and does not perform any check.
7. Then restore (or make available) the FOROPN.T20 file created on TOPS-20
and "misuse" DCRYPT to obtain the runtime key. Since the encryption is a
simple XOR and DCRYPT luckily does not distinguish among encrypted, plain,
and key files, just feed it with FOROPN.MAC (which is encrypted as it came
from the TOPS-10 TSU tape) when it asks for some encrypted file, and
FOROPN.T20 when it asks for a key. Call the resulting file FTNOTS.KEY.
|.r [,,tsu]dcrypt
|
| [DCRYPT version 1(3)]
| Dcrypt>decrypt foropn.mac foropn.t20 ftnots.key
| Decrypting DSK:FOROPN.MAC
| with DSK:FOROPN.T20
| calling it DSK:FTNOTS.KEY ...[OK]
|
| Dcrypt>
8. Now, with our new key, we can use APUTIL to decrypt every runtime file.
APUTIL reads file names from a VFY file and is able to distinguish between
encrypted and non-encrypted files. Therefore in decrypt mode it will only
work on encrypted files, whereas in verify mode it will work on all files.
If the VFY file and the KEY file have the same name, it's all automatic.
| .r [,,tsu]aputil
|
| APUTIL>read ftnots.vfy
| [Reading DSKB:FTNOTS.VFY[1,2,FTNOTS]]
| APUTIL>decrypt
| [Decrypting DSKB:[1,2,FTNOTS] using key file DSKB:FTNOTS.KEY[1,2,FTNOTS]]
| B10FRS.CTL has been decrypted
| FDDT.MAC has been decrypted
| FORCHR.MAC has been decrypted
| . . .
| MTHDUM.REL has been decrypted
| MTHPRM.UNV has been decrypted
| FORDDT.REL has been decrypted
| [Decrypted 25 of 94 files, 0 errors, 0 checksum errors]
| APUTIL>verify
| [Verifying DSKB:[1,2,FTNOTS]]
| B10FDT.CTL has been verified
| B10FRS.CTL has been verified
| F10LIB.CCL has been verified
| . . .
| MTHTRP.MAC has been verified
| MTHTRP.REL has been verified
| FORDDT.REL has been verified
| [Successfully verified 94 of 94 files, 0 errors, 0 checksum errors]
| APUTIL>
9. At this point we are ready to create our updated runtime library. Run
MAKLIB and feed it with F10LIB.CCL. This will create a new and updated
FORLIB.REL in the current directory, which will be the picklock to recover
the compiler binaries key. Let's rename it to something like FORLIB.NEW.
| .r maklib
|
| *@f10lib.ccl
|
| *^Z
|
| .rename forlib.new=forlib.rel
| Files renamed:
| DSKB:FORLIB.REL
10. Now, in another directory, restore the updated and encrypted compiler
binary files from TSU tape 04 (volume 3 of 3) BB-PBDED-BB. The directory on
tape is DSKB:[10,7,FTNSYS]. Copy to the same directory FORLIB.NEW from the
previous step and feed it to DCRYPT.EXE together with FORLIB.REL (encrypted,
coming from the TSU tape) to obtain FTNSYS.KEY in the same way as above.
11. Now run APUTIL to decrypt and verify the binary compiler files, that is
our final target.
| APUTIL>read ftnsys.vfy
| [Reading DSKB:FTNSYS.VFY[1,2,FTNSYS]]
| APUTIL>decrypt
| [Decrypting DSKB:[1,2,FTNSYS] using key file DSKB:FTNSYS.KEY[1,2,FTNSYS]]
| FORDDT.REL has been decrypted
| FORLIB.REL has been decrypted
| FORO11.EXE has been decrypted
| FORTB.EXE has been decrypted
| FORTC.EXE has been decrypted
| FORTD.EXE has been decrypted
| FORTE.EXE has been decrypted
| FORTF.EXE has been decrypted
| FORTG.EXE has been decrypted
| FORTRA.EXE has been decrypted
| [Decrypted 10 of 10 files, 0 errors, 0 checksum errors]
| APUTIL>verify
| [Verifying DSKB:[1,2,FTNSYS]]
| FORDDT.REL has been verified
| FORLIB.REL has been verified
| FORO11.EXE has been verified
| FORTB.EXE has been verified
| FORTC.EXE has been verified
| FORTD.EXE has been verified
| FORTE.EXE has been verified
| FORTF.EXE has been verified
| FORTG.EXE has been verified
| FORTRA.EXE has been verified
| [Successfully verified 10 of 10 files, 0 errors, 0 checksum errors]
| APUTIL>
:)
The same trick, but with REVHST.MAC instead of FOROPN.MAC, could be used to
recover the compiler sources key, although it will not decrypt a couple of
files because they are longer than REVHST.MAC and some other unpatched files
will not pass the checksum verification because the originals are missing
(they were stored in the unreadable section of the product distribution
tape) and those from the field test tape I had to use are different. At the
moment I have no fresh data at hand, but if my notes are correct it worked
for 253 out of 258 files, i.e. only 5 files didn't pass the checksum test,
and of those only 2 are actual source files.
I hope you'll find all of this useful and amusing as much as I did, :)
G.
as many of you may know, the TOPS-10 Fortran V11 tape image
available in the usual repositories is truncated because the original tape
reel from which it was sourced (BB-D480G-SB) was found to be damaged.
Luckily enough, the first four savesets (out of seven) were indeed readable,
therefore the V11 compiler is in fact available. Unfortunately, one of the
missing savesets (the seventh) contains the keys required to decode TSU tape
patches. Therefore, even if TSU tapes are available and completely readable,
their contents could not be used because they are encrypted.
Nonetheless, after much pondering and careful observing, and thanks to some
good guess, I was able to reconstruct the most important missing keys :)
Since both TOPS-10 and TOPS-20 Fortran compilers share the vast majority of
their sources, my first idea was to build the updated TOPS-10 Fortran
compiler from scratch with TOPS-20 sources from the latest TSU tape, but I
soon found it to be a too complex task because, among other things, some
TOPS-10-specific sources were missing. I would have had to use those from
some old field test tape available in the repository, but I was afraid that
the resulting compiler (if buildable at all) could have been a weird
bug-ridden hybrid. So I had to find a different route. Since I was there, I
also verified that TOPS-20 keys (which have always been available) do not
work with TOPS-10 products.
By observing the keys for other products I noticed that they are wildly
different in size and are usually pretty large, some are several hundred
blocks long, therefore I speculated that the encryption may have been just
some simple XOR of keys and sources. This means that XORing any cleartext
file with its corresponding encrypted version yields the key.
Since I could not directly recover the key for the patched compiler binaries
because I didn't have a suitable cleartext copy of any encrypted binary, I
had to follow a more circuitous route.
The solution comes from the fact that, as I said above, TOPS-10 and TOPS-20
Fortran compilers share the vast majority of their source files, which also
happen to be among the largest of the whole Fortran distribution. Also, most
important, the updated runtime sources come with their respective compiled
counterparts, i.e. REL files. Finally, runtime binary modules are contained
in the runtime sources saveset, whereas the resulting library is contained
in the binaries saveset.
So, here is a summary of the required steps.
1. First of all, on TOPS-20, restore the TOPS-20 Fortran V11 runtime key,
namely FORLIB.KEY, from the product distribution tape BB-4157J-BM.
2. Then, still on TOPS-20, restore the largest updated source of the Fortran
V11 runtime and the decryption tool, namely FOROPN.MAC and DCRYPT.EXE, from
TSU tape 04 (volume 1 of 2) BB-PENEA-BM.
3. Then, again on TOPS-20, use DCRYPT to obtain a plaintext version of
FOROPN.MAC, and call it e.g. FOROPN.T20.
4. Finally, transfer FOROPN.T20 to TOPS-10. If you do not have a working
DECnet network available you could use a tape image. The standard TOPS-20
backup program, DUMPER.EXE, could write (and read) TOPS-10 BACKUP tapes when
instructed to do so with the INTERCHANGE command. Note that the same
INTERCHANGE command in TOPS-10 BACKUP.EXE has another (unrelated) meaning.
5. Now on TOPS-10, restore the original (unpatched) TOPS-10 Fortran V11
runtime files from the truncated tape BB-D480G-SB. In fact they are in the
fourth saveset, i.e. the last readable one. Then, in the same directory,
restore the updated Fortran runtime files from TSU tape 04 (volume 3 of 3)
BB-PBDED-BB. The directory on tape is DSKB:[10,7,FTNOTS]. Several old files
will be overwritten with new patched and encrypted updated copies.
6. Restore tools APUTIL.EXE and DCRYPT.EXE from TSU tape 04 (volume 1 of 3)
BB-BT99V-BB. APUTIL and DCRYPT do basically the same thing, but APUTIL is
list-driven and could verify checksums, whereas DCRYPT does just one file at
a time and does not perform any check.
7. Then restore (or make available) the FOROPN.T20 file created on TOPS-20
and "misuse" DCRYPT to obtain the runtime key. Since the encryption is a
simple XOR and DCRYPT luckily does not distinguish among encrypted, plain,
and key files, just feed it with FOROPN.MAC (which is encrypted as it came
from the TOPS-10 TSU tape) when it asks for some encrypted file, and
FOROPN.T20 when it asks for a key. Call the resulting file FTNOTS.KEY.
|.r [,,tsu]dcrypt
|
| [DCRYPT version 1(3)]
| Dcrypt>decrypt foropn.mac foropn.t20 ftnots.key
| Decrypting DSK:FOROPN.MAC
| with DSK:FOROPN.T20
| calling it DSK:FTNOTS.KEY ...[OK]
|
| Dcrypt>
8. Now, with our new key, we can use APUTIL to decrypt every runtime file.
APUTIL reads file names from a VFY file and is able to distinguish between
encrypted and non-encrypted files. Therefore in decrypt mode it will only
work on encrypted files, whereas in verify mode it will work on all files.
If the VFY file and the KEY file have the same name, it's all automatic.
| .r [,,tsu]aputil
|
| APUTIL>read ftnots.vfy
| [Reading DSKB:FTNOTS.VFY[1,2,FTNOTS]]
| APUTIL>decrypt
| [Decrypting DSKB:[1,2,FTNOTS] using key file DSKB:FTNOTS.KEY[1,2,FTNOTS]]
| B10FRS.CTL has been decrypted
| FDDT.MAC has been decrypted
| FORCHR.MAC has been decrypted
| . . .
| MTHDUM.REL has been decrypted
| MTHPRM.UNV has been decrypted
| FORDDT.REL has been decrypted
| [Decrypted 25 of 94 files, 0 errors, 0 checksum errors]
| APUTIL>verify
| [Verifying DSKB:[1,2,FTNOTS]]
| B10FDT.CTL has been verified
| B10FRS.CTL has been verified
| F10LIB.CCL has been verified
| . . .
| MTHTRP.MAC has been verified
| MTHTRP.REL has been verified
| FORDDT.REL has been verified
| [Successfully verified 94 of 94 files, 0 errors, 0 checksum errors]
| APUTIL>
9. At this point we are ready to create our updated runtime library. Run
MAKLIB and feed it with F10LIB.CCL. This will create a new and updated
FORLIB.REL in the current directory, which will be the picklock to recover
the compiler binaries key. Let's rename it to something like FORLIB.NEW.
| .r maklib
|
| *@f10lib.ccl
|
| *^Z
|
| .rename forlib.new=forlib.rel
| Files renamed:
| DSKB:FORLIB.REL
10. Now, in another directory, restore the updated and encrypted compiler
binary files from TSU tape 04 (volume 3 of 3) BB-PBDED-BB. The directory on
tape is DSKB:[10,7,FTNSYS]. Copy to the same directory FORLIB.NEW from the
previous step and feed it to DCRYPT.EXE together with FORLIB.REL (encrypted,
coming from the TSU tape) to obtain FTNSYS.KEY in the same way as above.
11. Now run APUTIL to decrypt and verify the binary compiler files, that is
our final target.
| APUTIL>read ftnsys.vfy
| [Reading DSKB:FTNSYS.VFY[1,2,FTNSYS]]
| APUTIL>decrypt
| [Decrypting DSKB:[1,2,FTNSYS] using key file DSKB:FTNSYS.KEY[1,2,FTNSYS]]
| FORDDT.REL has been decrypted
| FORLIB.REL has been decrypted
| FORO11.EXE has been decrypted
| FORTB.EXE has been decrypted
| FORTC.EXE has been decrypted
| FORTD.EXE has been decrypted
| FORTE.EXE has been decrypted
| FORTF.EXE has been decrypted
| FORTG.EXE has been decrypted
| FORTRA.EXE has been decrypted
| [Decrypted 10 of 10 files, 0 errors, 0 checksum errors]
| APUTIL>verify
| [Verifying DSKB:[1,2,FTNSYS]]
| FORDDT.REL has been verified
| FORLIB.REL has been verified
| FORO11.EXE has been verified
| FORTB.EXE has been verified
| FORTC.EXE has been verified
| FORTD.EXE has been verified
| FORTE.EXE has been verified
| FORTF.EXE has been verified
| FORTG.EXE has been verified
| FORTRA.EXE has been verified
| [Successfully verified 10 of 10 files, 0 errors, 0 checksum errors]
| APUTIL>
:)
The same trick, but with REVHST.MAC instead of FOROPN.MAC, could be used to
recover the compiler sources key, although it will not decrypt a couple of
files because they are longer than REVHST.MAC and some other unpatched files
will not pass the checksum verification because the originals are missing
(they were stored in the unreadable section of the product distribution
tape) and those from the field test tape I had to use are different. At the
moment I have no fresh data at hand, but if my notes are correct it worked
for 253 out of 258 files, i.e. only 5 files didn't pass the checksum test,
and of those only 2 are actual source files.
I hope you'll find all of this useful and amusing as much as I did, :)
G.
smax...@prognoshealth.com
Apr 15, 2020, 8:50:44 AM4/15/20
to
On Wednesday, April 15, 2020 at 1:56:56 AM UTC-4, G. wrote:
> Dear all,
Outstanding!
> Dear all,
Outstanding!
AI Logic
Jan 21, 2021, 5:16:53 AM1/21/21
to
On Wednesday, April 15, 2020 at 1:56:56 AM UTC-4, G. wrote:
> Dear all,
>
> as many of you may know, the TOPS-10 Fortran V11 tape image
> available in the usual repositories is truncated because the original tape
> reel from which it was sourced (BB-D480G-SB) was found to be damaged.
http://pdp-10.trailing-edge.com
>
> as many of you may know, the TOPS-10 Fortran V11 tape image
> available in the usual repositories is truncated because the original tape
> reel from which it was sourced (BB-D480G-SB) was found to be damaged.
BB-D480G-SB_FORTRAN10_V11.0_short.tap.bz2
> Luckily enough, the first four savesets (out of seven) were indeed readable,
> therefore the V11 compiler is in fact available. Unfortunately, one of the
> missing savesets (the seventh) contains the keys required to decode TSU tape
> patches. Therefore, even if TSU tapes are available and completely readable,
> their contents could not be used because they are encrypted.
BB-BT99V-BB_1990.tap.bz2 (TOPS-10 TSU4 tape (1/3))
BB-JR93N-BB_1990.tap.bz2 (TOPS-10 TSU4 tape (2/3))
BB-PBDED-BB_1990.tap.bz2 (TOPS-10 TSU4 tape (3/3))
> Nonetheless, after much pondering and careful observing, and thanks to some
> good guess, I was able to reconstruct the most important missing keys :)
Wow, this is excellent information.
As it turns out, the work to decrypt the text and source files for
fortran-10 V11 updates, on the TOPS-10 TSU4, tapes, was done around Sept 2009.
The alt.sys.pdp10 newsgroup thread "Tops-10 Fortran-10 v11, TSU keys?"
https://groups.google.com/g/alt.sys.pdp10/c/Ik_xcjEZqUA/m/i2ZwSbS-wa8J
and
https://groups.google.com/g/alt.sys.pdp10/c/D6E-YL57a7Q/m/KSf2FXFIVOsJ
described the work.
The 2009 efforts didn't recover the ftnsys binary executable files though.
> Since both TOPS-10 and TOPS-20 Fortran compilers share the vast majority of
> their sources, my first idea was to build the updated TOPS-10 Fortran
ftncmp.vfy (TOPS-10)
and
ftncsr.vfy (TOPS-20)
which happen to list all files, with checksums, that should be in fortran
compiler source directory.
Comparing the list checksums reveals the files that are common,
and identical, between TOPS-10 and TOPS-20 Fortran v11.
Many of the missing/damaged source files for Fortran-10 can be copied
and restored from the TOPS-20 Fortran-20 tape.
> ...
12:
> The same trick, but with REVHST.MAC instead of FOROPN.MAC, could be used to
> recover the compiler sources key, although it will not decrypt a couple of
> files because they are longer than REVHST.MAC and some other unpatched files
> will not pass the checksum verification because the originals are missing
> (they were stored in the unreadable section of the product distribution
> tape) and those from the field test tape I had to use are different. At the
> moment I have no fresh data at hand, but if my notes are correct it worked
> for 253 out of 258 files, i.e. only 5 files didn't pass the checksum test,
> and of those only 2 are actual source files.
I was able to finish the work, and decrypt all the encrypted files for
> recover the compiler sources key, although it will not decrypt a couple of
> files because they are longer than REVHST.MAC and some other unpatched files
> will not pass the checksum verification because the originals are missing
> (they were stored in the unreadable section of the product distribution
> tape) and those from the field test tape I had to use are different. At the
> moment I have no fresh data at hand, but if my notes are correct it worked
> for 253 out of 258 files, i.e. only 5 files didn't pass the checksum test,
> and of those only 2 are actual source files.
TOPS-10 fortran-10 v11 on the TSU4 tape.
The remaining steps:
13:
Restore the missing files in ftncmp directory for TOPS-10 Fortran V11, that are identical
(same checksums) between TOPS-10 and TOPS-20, from the TOPS-20 Fortran V11 tape.
These are mostly *.bli (source code in blis10), and *.rel (relocatable compiled output)
files.
14:
Restore missing owndm.mac, and owndm.rel, from TOPS-10 Fortran V11
field test 3 tape (fortv11.tap.bz2). The checksums of these files match their
entries in ftpcmp.vfy from the TSU4 update.
15:
Install/update compiler tools and system libraries for building
the fortran compiler. More details on these tools and library dependencies
are in the b10ftn.ctl file.
These are the tools and libraries to install/update:
LINK, updated with the TSU4 tape, [10,7,link]
SCAN.rel, updated (version 7.5.675) with the TSU4 tape, [10,7,scan]
HELPER.rel, updated (version 7.7.57) with the TSU4 tape, [10,7,helper]
WILD.rel, required version (7.4.345) from tape
cuspmar86binsrc_2of2_bb-fp63a-sb.tap.bz2
BLIS10, install from FORTRAN-TOOLS saveset in the
TOPS-10 Fortran V11 field test 3 tape (fortv11.tap.bz2)
16:
Recover still missing *.rel files by rebuilding (see b10ftn.ctl) them from source.
Files to rebuild include main.rel, oneseg.rel, srca.rel, sta*.rel, etc.
Verify their checksums (use dir /check) against their entries in ftncmp.vfy.
.run sys:blis10
*unend=unend.bli
;Module length: 594+171
;Run Time: 0:0.4
;Elapsed Time: 0:3.5
;Max core used: 21 + 41 K
;[BLSNED No errors detected]
*main=main.bli
;Module length: 171+74
;Run Time: 0:0.1
;Elapsed Time: 0:0.3
;Max core used: 9 + 41 K
;[BLSNED No errors detected]
*^Z
*^C
.dir /check main.*,unend.*
MAIN BLI 24 <055> 116163 22-Dec-86 DSKB: [10,7,FTNCMP]
MAIN REL 5 <055> 406767 10-Jan-21
Total of 29 blocks in 2 files Checksum = 003021 on DSKB: [10,7,FTNCMP]
UNEND BLI 25 <055> 603507 19-Dec-86
UNEND REL 12 <055> 472524 10-Jan-21
Total of 37 blocks in 2 files Checksum = 562551 on DSKB: [10,7,FTNCMP]
Grand total of 66 blocks in 4 files Checksum = 402771
.
17:
Backup the still encrypted single segment fortran compiler single.exe.
Then rebuild it. The rebuild is good when single.exe checksum matches its entry
in ftncmp.vfy.
.ren single.exf=single.exe
Files renamed:
DSKB:SINGLE.EXE
.ren single.maq=single.map
Files renamed:
DSKB:SINGLE.MAP
.run sys:link
*@all
EXIT
.dir /check single.*
SINGLE EXF 937 <055> 530106 31-Jul-90 DSKB: [10,7,FTNCMP]
SINGLE MAQ 214 <055> 571565 31-Jul-90
SINGLE MAP 213 <057> 502467 11-Jan-21 11(4606)
SINGLE EXE 936 <057> 264211 11-Jan-21 11(4606)
SINGLE DIF 92 <057> 101056 11-Jan-21
Total of 2392 blocks in 5 files Checksum = 547061 on DSKB: [10,7,FTNCMP]
18.
Repeat step 12 with single.exe instead of REVHST.MAC to again recover the
compiler sources key. Call this key SINGLE.KEY.
This key will now be complete, and will decrypt all the TSU4 updated contents
in the FTNCMP directory.
.r [10,7,tsu]dcrypt
[DCRYPT version 1(3)]
Dcrypt>deCRYPT (encrypted file) single.exe (with key) single.exf (call it) single.key
Decrypting DSK:SINGLE.EXE
with DSK:SINGLE.EXF
calling it DSK:SINGLE.KEY ...[OK]
Dcrypt>exit
.
> I hope you'll find all of this useful and amusing as much as I did, :)
> G.
the PDP-10 emulation site at asun.net.
http://www.asun.net/pdp10 -> download page
fort10v11-tsu-keys-20210117.tap.bz2
contains the recovered TOPS-10 Fortran V11 TSU4 decryption keys,
forlib.key, foro11.key, single.key
fort10v11-recovery-20210117.tap.bz2
contains recovered, or rebuilt, files so far that are
missing for the original BB-D480G-SB_FORTRAN10_V11.0_short.tap.bz2
tape. The recovered decryption keys are also included.
I hope this helps. ..retro98
Rich Alderson
Jan 21, 2021, 3:18:27 PM1/21/21
to
Brilliant! Good work!
--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
G.
Mar 14, 2021, 11:33:27 AM3/14/21
to
On Wed, 15 Apr 2020 07:56:54 +0200, G. <ger...@no.spam.mail.com> wrote:
> Dear all,
>
> as many of you may know, the TOPS-10 Fortran V11 tape image
> available in the usual repositories is truncated because the original tape
> reel from which it was sourced (BB-D480G-SB) was found to be damaged.
>
> Luckily enough, the first four savesets (out of seven) were indeed readable,
> therefore the V11 compiler is in fact available. Unfortunately, one of the
> missing savesets (the seventh) contains the keys required to decode TSU tape
> patches. Therefore, even if TSU tapes are available and completely readable,
> their contents could not be used because they are encrypted.
Some weeks ago a new complete copy has surfaced in an almost uncatalogued
> Dear all,
>
> as many of you may know, the TOPS-10 Fortran V11 tape image
> available in the usual repositories is truncated because the original tape
> reel from which it was sourced (BB-D480G-SB) was found to be damaged.
>
> Luckily enough, the first four savesets (out of seven) were indeed readable,
> therefore the V11 compiler is in fact available. Unfortunately, one of the
> missing savesets (the seventh) contains the keys required to decode TSU tape
> patches. Therefore, even if TSU tapes are available and completely readable,
> their contents could not be used because they are encrypted.
media collection recently published on Bitsavers.
http://bitsavers.org/bits/DEC/mixed_media/magtape/2.mt.gz
I've had no time yet to test it on any TOPS-10 system, but the following is
the output of the backup10 unix utility, and it looks very promising. I'm
almost 100% sure that this is it and it would work.
| Start of Saveset FORTRAN-AUTOPATCH on MTA0 F10TAP
| System RN340A DEC10 Development TOPS-10 monitor 704(31674) APR#1026
| 1600 BPI 9-track 29-Jan-87 10:09:29 BACKUP 5A(620) tape format 1
| Tape number 1
|
| 109 13842(36) <***> 19-Jan-87 []fortra.key
| 725 92690(36) <***> 19-Jan-87 []forlib.key
| 165 21010(36) <***> 19-Jan-87 []foro11.key
| 85 10770(36) <***> 19-Jan-87 []forddt.key
| 349 44562(36) <***> 19-Jan-87 []fortb.key
| 181 23058(36) <***> 19-Jan-87 []fortc.key
| 309 39442(36) <***> 19-Jan-87 []fortd.key
| 305 38930(36) <***> 19-Jan-87 []forte.key
| 277 35346(36) <***> 19-Jan-87 []fortf.key
| 209 26642(36) <***> 19-Jan-87 []fortg.key
| 981 125458(36) <***> 28-Jan-87 []single.key
| 213 27154(36) <***> 29-Jan-87 []dortra.key
| 441 56338(36) <***> 29-Jan-87 []dortb.key
| 265 33810(36) <***> 29-Jan-87 []dortc.key
| 397 50706(36) <***> 29-Jan-87 []dortd.key
| 397 50706(36) <***> 29-Jan-87 []dorte.key
| 365 46610(36) <***> 29-Jan-87 []dortf.key
| 305 38930(36) <***> 29-Jan-87 []dortg.key
|
| End of Saveset FORTRAN-AUTOPATCH on MTA0 F10TAP
| System RN340A DEC10 Development TOPS-10 monitor 704(31674) APR#1026
| 1600 BPI 9-track 29-Jan-87 10:10:08 BACKUP 5A(620) tape format 1
| Tape number 1
HTH, :)
G.
AI Logic
Apr 8, 2021, 1:28:50 PM4/8/21
to
On Sunday, March 14, 2021 at 11:33:27 AM UTC-4, G. wrote:
> On Wed, 15 Apr 2020 07:56:54 +0200, G. <ger...@no.spam.mail.com> wrote:
>
> > Dear all,
> >
> > as many of you may know, the TOPS-10 Fortran V11 tape image
> > available in the usual repositories is truncated because the original tape
> > reel from which it was sourced (BB-D480G-SB) was found to be damaged.
> >
...
> On Wed, 15 Apr 2020 07:56:54 +0200, G. <ger...@no.spam.mail.com> wrote:
>
> > Dear all,
> >
> > as many of you may know, the TOPS-10 Fortran V11 tape image
> > available in the usual repositories is truncated because the original tape
> > reel from which it was sourced (BB-D480G-SB) was found to be damaged.
> >
> Some weeks ago a new complete copy has surfaced in an almost uncatalogued
> media collection recently published on Bitsavers.
>
> http://bitsavers.org/bits/DEC/mixed_media/magtape/2.mt.gz
>
This is great news!
> media collection recently published on Bitsavers.
>
> http://bitsavers.org/bits/DEC/mixed_media/magtape/2.mt.gz
>
A good and complete copy of the long damaged FORTRAN-10 V11.0 tape (BB-D480G-SB) has been found. Also see
http://www.bitsavers.org/bits/DEC/mixed_media/BitImages.txt
Product Date text1 text2 FromBox System OS Blue Media Bad Source Filename
BB-D480G-SB FORTRAN-10 V11.0 0 PDP-10 TOPS-10 N MT FALSE STUMPF 2.mt
> I've had no time yet to test it on any TOPS-10 system, but the following is
> the output of the backup10 unix utility, and it looks very promising. I'm
> almost 100% sure that this is it and it would work.
>
Strange as it may be for the tape to be found just 1 month after a 12 year effort (from 2009) to reconstruct the FORTRAN-10 V11.0 lost files and decryption keys.
..retro98
0 new messages