Actually, I'd not heard of this before. I've now seen it in a KB, but there was no download link.
Have you tried the file MSIE128.EXE?
Same old propaganda, regurgitated by so-called experts that can't think for themselves. Beware security of W98 machines, make sure they're guarded from physical access, they use FAT, whereas NT machines are so much more secure thanks to NTFS. Yeah right, a proprietary file system without a publicly available specification may hamper recovery efforts, but it doesn't stop an intruder getting in.
I guess that the actual explanation comes hear-hear from the NSA:
That would explain everything nicely.
Well, I have some success to report!Well, jds has the right attitude to be our lab rat and report.
I am curious now, if that is the sole factor or if it checks other things?
Since the "high encryption packs":
I would suspect a check for one of the bolded files (or a specific version of them), but let's wait for test results.
# First experiment. Dusted off an old laptop with W98FE …
Initially, IE was 4.01, with 40 bit encryption.
Installed 'dun14-SE.exe', but IE remained at 40 bit encryption!
Installed 'ie4dom.exe', now IE had 128 bit encryption.
Installed 'dsclient.exe' 5.00.2920.0005, 'secur32.dll' was now 4.10.2226 - 128 bit!!!
It was a bit of a surprise to see the 4.10.2226 version number for 'secur32.dll', since the 56 bit sub-version within the above 'dsclient.exe' file is version 4.10.2228. I thought perhaps this lower version number was due to this being W98FE.
Note, see http://www.msfn.org/...post__p__945562 for a link to 'dsclient.exe' 5.00.2920.0005.
# Second experiment. Dusted off an old laptop with W98SE …
Initially, IE was 5.0, with 40 bit encryption & 'secur32.dll' was 4.10.2222 - 56 bit.
Installed 'ie5dom.exe', now IE had 128 bit encryption.
Installed 'dsclient.exe' 5.00.2920.0005, 'secur32.dll' was now 4.10.2226 - 128 bit!!
OK, now where did that 4.10.2226 version of 'secur32.dll' come from? Comparing to the W98FE one, it was the same file. It could not have been produced by patching the original file, since that would be impractical (original version could be anything) and the 4.10.2228 (56 bit) version was too different. So 'dsclient.exe' must have this 128 bit sub-version of 'secur32.dll' hidden somewhere within it. The fact that it had a lower version number than the 56 bit sub-version suggests that MS only bothered to produce a 56 bit version of this hotfix. This is [edit: the word "possibly" should go here, since this is just one interpretation] implied by http://support.microsoft.com/kb/267879 which states :
The hotfix that is described in this article is not fully compatible with the Windows 95 or Windows 98 Directory Service client. The Windows 95 and Windows 98 Directory Service client contains a version of the Secur32.dll file that provides additional functionality that is not included in the version of the Secur32.dll file that is included with Windows 95, Windows 98, and Windows 98 Second Edition. This hotfix also does not provide the additional Directory Service client functionality.
# Third experiment. The '266772usa8.exe' hotfix …
Perhaps this hotfix can provide a 128 bit subversion of 'secur32.dll' 4.10.2228?
Well, applying this hotfix to the above W98SE laptop updated the version of 'secur32.dll', BUT now it was 56 bit again!
Re-applying 'dsclient.exe' did not change it back to 4.10.2226 (128 bit).
Deleting 'secur32.dll' (in DOS mode) and re-applying 'dsclient.exe' did.
# Fourth experiment. Those "high encryption pack" files …
Of those files listed above, the following were present on the W98SE laptop : 'ADVPACK.DLL', 'enhsig.dll', 'rsaenh.dll', 'W95INF16.DLL' and 'W95INF32.DLL'.
These files were copied onto the W98SE desktop with IE 5.01SP2 mentioned at the outset of this thread, after first backing up the existing files. Deleting the 'secur32.dll' file (in DOS mode) and applying 'dsclient.exe' 5.00.2920.0005 resulted in the 128 bit sub-version of 'secur32.dll' 4.10.2226! (The above substituted files were then restored.)
# Conclusions …
Yes, 128 bit sub-version(s) of 'secur32.dll' really DO exist. The latest proven to exist is version 4.10.2226.
The 'dsclient.exe' package (similarly, the MSI packages) create the 128 bit sub-version(s) of 'secur32.dll' only if they detect IE is at 128 bit encryption. Unfortunately, this detection is flawed, it seems to work for IE 4 and IE 5.0, but seems to fail for newer editions of IE (or may be affected by updates). It can be forced to recognise that IE is at 128 bit encryption level by copying the "high encryption pack" files mentioned above (probably only one of these files is key).
# Caution …
The 4.10.2226 version of 'secur32.dll' has a Unicode bug, identified in http://support.microsoft.com/kb/266772 . This may be the reason why 'cntlm' (an NTLM authentication proxy) failed for me, after installing the 128 bit sub-version of this file. I rectified this by copying the (56 bit) sub-version of 'secur32.dll' 4.10.2228 into the same directory as 'cntlm.exe'.
Edited by jds, 16 November 2010 - 06:34 AM.