Microsoft to delete legacy updates in the great SHA-1 purge

Get ready to see this quite often.

From the article here, on August 3rd, (aka yesterday) the purge will be complete. Instead of introducing an update to verify SHA-2 into legacy systems, and re-signing old updates, instead MS has taken the path of obsolesce and pulled the downloads instead.

And we’ve been here before.

Microsoft movie maker was a popular download for Windows XP, and MS removed the download, as hosting it was apparently encouraging people to keep on using XP. Naturally this wasn’t taken as a message that people wanted this kind of product, and why fill a void when you can remove a product? So now the majority of downloads that you will find are infected, corrupted and just going to cause further problems.

And here we go again.

Office 2003 SP1 is no more

A quick search on BING for MS Office 2003 updates still shows links, but they are simply no more. The purge is in full force, and search pages haven’t caught up. And as you can see cnet is already in the top downloads, and will become the authoritative download by fiat.

Also the early .NET’s deployment packages are no longer for download, while .NET 1.1 SP1 is still online surprisingly. For reference:

$ shasum -a 512256 NDP1.1sp1-KB867460-X86.exe 
7b44095feff471dee9366a2153dfe2654d70754c21b7e5204ed950cdf4a3f15a  NDP1.1sp1-KB867460-X86.exe

For what it’s worth.

Calculating with shasum offers a few algorighims as this isn’t a simple one shot deal.

-a, --algorithm   1 (default), 224, 256, 384, 512, 512224, 512256

Naturally to add further confusion. Like everything with crypto, it’s so easy to mess it up.

$ shasum -a 1 NDP1.1sp1-KB867460-X86.exe 
74a5b25d65a70b8ecd6a9c301a0aea10d8483a23  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 224 NDP1.1sp1-KB867460-X86.exe 
18507f80722780ca477d7f10528ae28dd176f8d36cbce05a50cc7be0  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 256 NDP1.1sp1-KB867460-X86.exe 
2c0a35409ff0873cfa28b70b8224e9aca2362241c1f0ed6f622fef8d4722fd9a  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 384 NDP1.1sp1-KB867460-X86.exe 
c2372c71f93b5dc2a1c21c804bc74e27d82bfa45ee50fbc9037e713c156f1c591ffbe5e87f94022157906098916403b4  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 512 NDP1.1sp1-KB867460-X86.exe 
bbe643f447f49636732b12d23a052d02681ad41f6920dc1038b073fa600f7589b378ed8e7de97e811543d93ae89ce52871a85ee58aa3b6aeaddc01bc1617ad85  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 512224 NDP1.1sp1-KB867460-X86.exe 
63b2ffb0c5f1cd68abafba23997482b2087d486dcf60bec6fef7446d  NDP1.1sp1-KB867460-X86.exe
$ shasum -a 512256 NDP1.1sp1-KB867460-X86.exe 
7b44095feff471dee9366a2153dfe2654d70754c21b7e5204ed950cdf4a3f15a  NDP1.1sp1-KB867460-X86.exe

Oddly enough a quick search for these checksums isn’t coming up with anything so I guess I’m first. Which of course is a further problem, is that there is no authoritative source from MS. I get the contract obsolescence thing, after-all the strongest competition to NEW MS products is OLD MS products. I still use Excel 3 & MS Word 2, despite having an Office 365 subscription, and various newer versions retail.

The sad thing is that many people will get screwed over from this action, and the only “solution” is of course move to Windows 10, embrace the new, and hope that you don’t have applications that actually require .NET 1.1 (or 1.0!).

Not having fun with Python/Debian 9.1

Well after my last Star Wars Galaxies adventure, where I tried to run MySQL on Linux Subsystem for Windows v1, I got some weird shared memory error, and it wouldn’t run. Even the old BSDDB engine was bombing out trying to create files. So fine, whatever I thought I could move on, and that is when I found out that somehow OpenSSL & Python had utterly collided.

Python 1.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/", line 98, in import _ssl # if we can't import it, let the error propagate ImportError: /usr/lib/x86_64-linux-gnu/ version `OPENSSL_1_1_0' not found (required by /usr/lib/python2.7/lib-dynload/ >>>

Well isn’t that great. I tried un-installing & re-installing Python over and over, along with trying to force re-install OpenSSL. No dice.

So what finally got it working for me was to purge OpenSSL.

apt-get purge libssl1.1

And after that it pulled out everything that was using it, well over 500MB of stuff I’d installed. And for good measure I followed up with the autoremove for an additional 384MB of stuff to remove. And then for the final step, of just installing Python:

[email protected]:~# apt-get install python2.7 Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libpython2.7-stdlib libssl1.1 Suggested packages: python2.7-doc The following NEW packages will be installed: libpython2.7-stdlib libssl1.1 python2.7 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 3,537 kB of archives. After this operation, 12.8 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 stretch/main amd64 libssl1.1 amd64 1.1.0j-1~deb9u1 [1,354 kB] Get:2 stretch/main amd64 libpython2.7-stdlib amd64 2.7.13-2+deb9u3 [1,897 kB] Get:3 stretch/main amd64 python2.7 amd64 2.7.13-2+deb9u3 [285 kB] Fetched 3,537 kB in 0s (13.2 MB/s) Preconfiguring packages ... Selecting previously unselected package libssl1.1:amd64. (Reading database ... 27441 files and directories currently installed.) Preparing to unpack .../libssl1.1_1.1.0j-1~deb9u1_amd64.deb ... Unpacking libssl1.1:amd64 (1.1.0j-1~deb9u1) ... Selecting previously unselected package libpython2.7-stdlib:amd64. Preparing to unpack .../libpython2.7-stdlib_2.7.13-2+deb9u3_amd64.deb ... Unpacking libpython2.7-stdlib:amd64 (2.7.13-2+deb9u3) ... Selecting previously unselected package python2.7. Preparing to unpack .../python2.7_2.7.13-2+deb9u3_amd64.deb ... Unpacking python2.7 (2.7.13-2+deb9u3) ... Processing triggers for mime-support (3.60) ... Processing triggers for libc-bin (2.24-11+deb9u4) ... Setting up libssl1.1:amd64 (1.1.0j-1~deb9u1) ... Processing triggers for man-db ( ... Setting up libpython2.7-stdlib:amd64 (2.7.13-2+deb9u3) ... Setting up python2.7 (2.7.13-2+deb9u3) ... Processing triggers for libc-bin (2.24-11+deb9u4) ...

So now you think its going to be broken right? It’s the same libssl package! I didn’t even run an ‘apt-get update’. And guess what?! You would be wrong.

[email protected]:~# python Python 2.7.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ssl >>>

That’s right, it’s now working.

Speaking of Picard, I hear there will be a new series, inspiringly named ‘Picard’. Apparently it’s going down the same path as STD, complete with a lack of backers, and merch. I’m hoping it’ll be something watchable, although they certainly cannot afford any of the TNG cast as they apparently have zero budget. Maybe it’ll end up as another ‘Jake Skywalker’ or ‘Not my Picard’. But the bad reboot 25% contractual difference could be the difference between something new, or something so divergent that there was no point in even attempting to be a Trek.

Anyone using truecrypt or any derivative work

will want to incorporate these patches on the Windows platform:

So yeah, apparently you can get full admin rights through the driver. oops.

Fun with PGP 1.0

Well I got slightly bored, and thought I’d dig into some old crypto software.  And PGP 1.0 was as good as any place to start.

Now one scandalous thing at the time was the inclusion of RSAREF 1.0, the RSA reference library which redistribution required a license that wasn’t exactly included with PGP.

A company called Public Key Partners (PKP) holds the exclusive
commercial license to sell and sub-license the RSA public key
cryptosystem. For licensing details on the RSA algorithm, you can
contact Robert Fougner at PKP, at 408/735-6779. The author of this
software implementation of the RSA algorithm is providing this
implementation for educational use only.

And wow was this fun at the time.  As far as I know this license lapsed on September 21, 2000

And then there was this slight issue:

After Biham and Zimmermann go their food and sat down, Zimmermann took out a few pages of computer listings.  Within minutes, Birham was finding fundamental flaws in Bass-O-Matic.  Some of the flaws were subtle-weaknesses that made the algorithm susceptible to differential cryptanalysis, which was Birham’s speciality. Others were more embarrassing, like a conceptual error in Zimmermann’s algorithm that prevented the last bit of each byte from being properly encrypted.  After ten minutes of Birham’s onslaught, Zimmermann realized that Bass-O-Matic was a lost cause.

So now you would be wondering, why would I even bother with what was a quickly abandoned encryption?  Well I was bored, and I was more interested if I could locate the source to 1.0.  What would be more interesting to me is to revive it onto somewhat more modern 32-bit platforms.  Namely OS X, Win32 and MS-DOS.

With a little luck, I found the unix_pgp10.tar.gz, which does contain the source code for a Unix version of PGP!  This version is more so geared to the SPARC of all things. Specifically it mentions:

Tested on SunOS 4.1 with gcc 1.39

However building on OS X was trival with changing the Makefile.  The CC had to be changed to reflect a 32bit build, and the DEFINES had to remove the HIGHFIRST define, as the x86 platform is little endian.

CC=cc -arch i386


Is the relevant changes.

And even better it’ll work!

$ pgp pgp.ctx pgp.exe

Pretty Good Privacy 1.0 – RSA public key cryptography for the masses.
(c) Copyright 1990 Philip Zimmermann, Phil’s Pretty Good Software. 5 Jun 91

File has signature. Public key is required to check signature.
File ‘pgp.ctx’ has signature, but with no text.
Text is assumed to be in file ‘pgp.exe’.
Good signature from user “Zimmermann, Philip R. – [email protected]”.
Signature made Wed Jun 5 13:51:18 1991

Signature and text are separate. No output file produced.
Plaintext filename: pgp.exe

Wasn’t that great!

Now getting this to run on Windows was a little bit more of a challenge.  I was going to build from the UNIX source code again, however both Visual C++, and Watcom C++ build an executable, but neither are able to add keys to the keyring, verify the executable reliably and deadlock all the time.

So I thought I’d get a little creative and start replacing some code from the MS-DOS version of PGP. It turns out that all I needed was rsaio.c & rsaio.h and I was able to build an executable.  But I ran into other snags, and stack errors.  A glance at the MS-DOS Makefile, and I saw that they had to up the stack size from the defaults.  So I figured the same would hold true, and I picked a much larger 32kb stack for the heck of it.  I mean it is 2014, and if you can’t handle a 32kb stack well..

Compiling on Visual C++ went like this:

cl *.obj /F32768 /Fepgp.exe

And for Watcom C++

wcl386 -c -dPSEUDORANDOM -dUNIT16 -dPORTABLE *.c
wcl386 *.obj -fe=pgp.exe -k32768

And now I can build for either compiler.  And even better, it works!

PGP 1.0 on Win32

PGP 1.0 on Win32

Even for completness sakes, DOS4G/W works as well! Just remember to link for MS-DOS

wcl386 *.obj -fe=pgp.exe -k32768 -l=dos4g

And you should be good to go.

PGP for 32bit MS-DOS

PGP for 32bit MS-DOS

So what happened to PGP?  Well version 2 used a more ‘acceptable’ encryption, the IDEA cypher, then the company was sold, IP was sold again and again.  It’s still out there, mostly for email encryption.

While it sure did ignite the world on fire for a while, the overall difficulty of using it, combined with the ease of losing the private key and all your data is just too easy.  But this really is the nature of the beast.

With all the truecrypt hysteria running around

truecrypt-logoI thought I’d go mining for old versions, and put them up on CVS web.  Turns out some old versions are missing, but oddly enough not the 1.0 stuff.

So here is the src2html version, and the raw tree view.

And for the really crazy, I dumped all versions into CVS.

I only briefly looked at it, and noticed the block driver has the ability to look at memory.. I don’t know why, but I don’t think I would want my block drivers being able to do that.  maybe it’s a good thing, I don’t know.  I haven’t tried to build it, and I’ve never used TrueCrypt so I really can’t comment on it.

Also pulling through I found some old versions of scramdisk. But I never used that either.