Jump to content

128 bit SECUR32.DLL - Myth or Missing?


jds

Recommended Posts


How to get 128-bit secur32.dll file...

In tinkering with a factory-state Dell with Win98 SE, I've discovered that having IE6 with 128bit (only that app upgraded after factory-state) somehow isn't what the dsclient9x.msi wants when deciding which version of secur32.dll to give you (56bit or 128). With IE6 you'll get 56. However, when I went back to true factory state and then installed the "high encryption pack" version of IE, version 5 for Win98, followed by execution of dsclient9x.msi, I then ended up with the 128-bit version of secur32.dll. Be cautious, however, since I've found Microsoft documentation on the Web that indicates that subsequent hot fixes can destroy what dsclient9x.msi sets up. Sorry to not include links. I don't have them handy but this information should be easy to find with simple searches on key words/phrases within this text.

Link to comment
Share on other sites

that's because the 128-bit versions of IE 5.01 SP, IE 5.5 and IE 6.0 install 128-bit versions of the RSAENH.DLL & SCHANNEL.DLL files and NOT the 128-bit version of the SECUR32.DLL file. Installing/upgrading to the 128bit encryption edition of IE does not upgrade the SECUR32.DLL file to 128-bit version.

Thanks for that info. It explains why IE can have 128 bit encryption despite SECUR32.DLL.

if dsclient for win9x doesn't install the correct version of the secur32.dll file, you may want to read the following Annoyances.org thread:

http://www.annoyances.org/exec/forum/win2003/t1128901046

Yeah! That's pretty similar to what I'm facing now. Pity there was no resolution.

I'm not sure if this is any help or if it confuses the situation even more. On my old 98FE unit, my copy of secur32.dll does not say export version or USA and Canada on the version tab. Just says Microsoft Win32 Security Services.

The MD5 for the file is 677273be08256ea12afdfc8da91ac54a if it's of any help. So far, I'm unable to determine just where I got this file. It does have DUN1.4 installed.

That's right, older versions of SECUR32.DLL do no differentiate Export vs US/Canada sub-versions. I think that's because this was before the 128 bit encryption for NTLMv2 was added. So only newer versions have that split.

How to get 128-bit secur32.dll file...

In tinkering with a factory-state Dell with Win98 SE, I've discovered that having IE6 with 128bit (only that app upgraded after factory-state) somehow isn't what the dsclient9x.msi wants when deciding which version of secur32.dll to give you (56bit or 128). With IE6 you'll get 56. However, when I went back to true factory state and then installed the "high encryption pack" version of IE, version 5 for Win98, followed by execution of dsclient9x.msi, I then ended up with the 128-bit version of secur32.dll. Be cautious, however, since I've found Microsoft documentation on the Web that indicates that subsequent hot fixes can destroy what dsclient9x.msi sets up. Sorry to not include links. I don't have them handy but this information should be easy to find with simple searches on key words/phrases within this text.

Yes, I encountered this too, which is the reason why I've tried this on W98 machines with both IE6 and IE5, as it is implied that the DSClient install incorrectly determines the encryption capabilities of IE6. However, I didn't get any different result in either case.

----------------------------

The KB's suggest that the DSClient installer package checks the security capability (56 vs 128 bit encryption) of your IE installation, to decide if you qualify for the 56 bit (Export) or 128 bit (US/Canada) capable sub-versions of SECUR32.DLL. But as usual, it seems the detection logic is faulty, and nothing I've tried so far has been successful. Now that 128 bit NTLMv2 is becoming mandatory (by default), this is a real problem.

The alternative theory is that all the stuff in the KB's describing these two sub-versions is pure fantasy. That's why I question if anyone has ever seen the 128 bit version of SECUR32.DLL as described (ie. identified as "(US and Canada only)" in its version description). I guess that version description comes from the time when 128 bit encryption software was restricted to USA and Canada (I can't recall when that restriction eased, although it must have been around the time of IE 5.5).

The various DSClient installer packages seem to contain only the "Export" version of SECUR32.DLL when you open them with TugZip or 7Zip. Different versions seem to exist for W95, W98 and W98SE. Perhaps the "US and Canada only" sub-version is produced by the DSClient installer by patching the "Export" version.

The only new lead I've encountered in the past day or so, is that the Q323466 update for DSClient (not clear from the archived KB just what that update fixes) is (also?) included in a file called "5234_ENU_i386_zip.exe". Haven't been able to locate it, nor do I know if it will be any better at producing the 128 bit version of SECUR32.DLL.

Joe.

Edited by jds
Link to comment
Share on other sites

I guess that the actual explanation comes hear-hear :w00t: from the NSA:

http://www.nsa.gov/ia/_files/os/win2k/w2k_winnt_9x_clients.pdf

(page 9)

That would explain everything nicely.

The actual file on the Server 2000 CD should be the one available also here:

http://www.xlightftpd.com/faq.htm

It also seems like the good MS guys have of course managed to make an incompatible (with their OWN product) .dll :whistle::

http://kbalertz.com/278243/Error-Default-Start-Outlook.aspx

This should mean that the install routine *somehow* detects *something* and patches on-the-fly the "Export" .dll to the "U.S. and Canada Only" version. :unsure:

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

@Jaclaz

Good find! That PDF only mentions checking IE 4 /5 for 128 bit

encryption as the parameter for deciding which level Secur32.dll

get's installed.

I am curious now, if that is the sole factor or if it checks other things?

Interesting stuff......

Jake

Link to comment
Share on other sites

I am curious now, if that is the sole factor or if it checks other things?

Well, jds has the right attitude to be our lab rat :w00t:;) and report.

Since the "high encryption packs":

http://www.microsoft.com/windows/ie/ie6/downloads/recommended/128bit/default.mspx

Contain:

  • ADVPACK.DLL
  • enhsig.dll
  • ie5dom.inf
  • rsaenh.dll
  • sch128c.dll
  • W95INF16.DLL
  • W95INF32.DLL

I would suspect a check for one of the bolded files (or a specific version of them), but let's wait for test results. :)

jaclaz

Link to comment
Share on other sites

Have you tried the file MSIE128.EXE?

Actually, I'd not heard of this before. I've now seen it in a KB, but there was no download link.

I guess that the actual explanation comes hear-hear :w00t: from the NSA:

http://www.nsa.gov/ia/_files/os/win2k/w2k_winnt_9x_clients.pdf

(page 9)

That would explain everything nicely.

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 am curious now, if that is the sole factor or if it checks other things?

Well, jds has the right attitude to be our lab rat :w00t:;) and report.

Since the "high encryption packs":

http://www.microsoft.com/windows/ie/ie6/downloads/recommended/128bit/default.mspx

Contain:

  • ADVPACK.DLL
  • enhsig.dll
  • ie5dom.inf
  • rsaenh.dll
  • sch128c.dll
  • W95INF16.DLL
  • W95INF32.DLL

I would suspect a check for one of the bolded files (or a specific version of them), but let's wait for test results. :)

jaclaz

Well, I have some success to report!

# 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 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'.

Joe.

Edited by jds
Link to comment
Share on other sites

Now that you have confirmed that the "trick" is inside dsclient.exe, I presume the same EXACT file here 5.0.2920.5:

ftp://ftp.catalyst.com/pub/cstools/support/dsclient.exe

And what happens with the one here 5.0.2920.0:

http://www.xlightftpd.com/faq.htm

http://www.xlightftpd.com/download/Dsclient.exe

Check the "instsec.dll" properties ;) (remember that on NT systems SECUR32.DLL was called SECURITY.DLL., and as usual in the MS world the internal name of SECUR32.DLL is still SECURITY.DLL :whistle:

IF it's that, the SAME "instsec.dll" file is also inside dsclient9x.msi (but other files are changed, particularly in the .msi SECUR32.DLL is 4.10.0.226 whilst in the .exe it is 4.10.0.228) :wacko:

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Just for my own peace of mind.....

Tryed all 3 versions of the dsclient install on my 98se system

with ie6sp1....all 3 produced the same "export" version of Secur32.dll.

Next stop was grab the high encryption pack and checked the included

Dll's against what was resident on my system, The only thing missing

of 3 jaclaz pointed out was sch128c. dll. So I copied that into the Windows

System directory , ended with same results.

Next stop is to find out if that DLL needs to be registered, also going to

roll back my registry to a pretest state and try again.....

any other suggestions would be welcome???

Jake

Link to comment
Share on other sites

Can you try it with the WinME version SECUR32.DLL?

The WinME version of SECUR32.DLL is v4.90.3000 dated 6/8/2000 AND is 56bit.

I know because I have an actual WinME system. File description of ME's secur32.dll file says "Microsoft Win32 Security Services (Export Version)"

Next stop was grab the high encryption pack and checked the included

Dll's against what was resident on my system, The only thing missing

of 3 jaclaz pointed out was sch128c. dll. So I copied that into the Windows

System directory , ended with same results.

the sch128c.dll file is just a renamed schannel.dll file, Jake. that one has 128bit encryption.

Edited by erpdude8
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...