[HECnet] I have found how to recover the TOPS-10 Fortran V11 patch decryption keys

Wed Apr 15 09:56:03 PDT 2020

Fascinating reading - almost like reading Stoll's Cuckoos Eggs!

Thank you G.

---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet

> On Apr 15, 2020, at 12:09 PM, Robert Armstrong <bob at jfcl.com> wrote:
> 
>  Thanks, Gerry!
> 
> Bob
> 
> 
> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
> Of G.
> Sent: Tuesday, April 14, 2020 11:07 PM
> To: HECnet
> Subject: [HECnet] I have found how to recover the TOPS-10 Fortran V11 patch
> decryption keys
> 
> Since here too there are some TOPS-10 users, I am pleased to announce that I
> have found a way to recover the long-missing TOPS-10 Fortran V11 patch
> decryption keys. Find below a copy of the post I just sent to alt.sys.pdp10.
> 
> HTH, :)
> G.
> 
> =====
> 
> 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.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20200415/a3d2d883/attachment-0001.html>