Thomas J. Hruska wrote:
Feel free to follow along with this e-mail:
http://www.slproweb.com/download/bad_openssl.zip
I just zipped up the contents of the 'out32dll' directory. What you see
is what I've got in my out32dll directory. And now onto the main part
of the e-mail.
This is my first time building FIPS but given that I generally know how
to build pretty much anything OpenSSL, it probably isn't my fault
(famous last words). The build process works fine up to this point:
out32dll\fips_premain_dso.exe out32dll\libeay32.dll
2348:error:25078067:DSO support routines:WIN32_LOAD:could not load the
shared library:.\crypto\dso\dso_win32.c:147:filename(out32dll\libeay32.dll)
2348:error:25070067:DSO support routines:DSO_load:could not load the
shared library:.\crypto\dso\dso_lib.c:244:
Get hash failure at util\fipslink.pl line 48.
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.EXE' : return code '0x1'
Stop.
Looking at fipslink.pl, it looks like the first line displayed is the
executable/command run. Running that command directly, I get the two
error messages after Windows displays this message box:
"Bad Image"
"The application or DLL C:\[path]\openssl-0.9.7m\out32dll\libeay32.dll
is not a valid Windows image. Please check this against your
installation diskette."
So, it is finding the DLL but refusing to load. It could be the fixed
address issue and wanting to relocate, but using one of the tools I use,
it is clear to me that something seriously hosed the file up somewhere
along the line in the build process. There is a relocation table data
directory entry but no relocation table (appears to be intentional file
truncation) and a missing section. One of the tools I've used for years
without problems is balking at the file. I'm not surprised that Windows
isn't loading the DLL.
VC++ 2008 Professional (not SP1)
Windows XP SP2
FIPS 1.1.2 w/ OpenSSL 0.9.7m
fipscanister.o and other files reside on a CD-R (drive e:) built against
the MSYS instructions in the User Guide for 1.1.1.
perl Configure VC-WIN32 fips --with-fipslibdir=e:/
Beyond that, regular build process using NASM (latest).
Fresh 0.9.7m and FIPS 1.1.2 files, cross-referenced against the MD5 and
SHA-1 hashes on the site (which, BTW, the website links are broken, I
had to go through FTP).
Additional tests:
While paused at the message box, I ran a little tool I wrote many years
ago:
Process ID: 2904
Module ID = 00400000, Module Name = FIPS_PREMAIN_DSO.EXE, Module
Filename =
c:\cfiles\projects\winssl\openssl-0.9.7m\out32dll\FIPS_PREMAIN_DSO.EXE
Module ID = 7C900000, Module Name = ntdll.dll, Module Filename =
C:\WINDOWS\system32\ntdll.dll
Module ID = 7C800000, Module Name = kernel32.dll, Module Filename =
C:\WINDOWS\system32\kernel32.dll
Module ID = 08370000, Module Name = depends.dll, Module Filename =
C:\PROGRA~1\MIAF9D~1\Common\Tools\depends.dll
Module ID = 77DD0000, Module Name = ADVAPI32.dll, Module Filename =
C:\WINDOWS\system32\ADVAPI32.dll
Module ID = 77E70000, Module Name = RPCRT4.dll, Module Filename =
C:\WINDOWS\system32\RPCRT4.dll
Module ID = 77FE0000, Module Name = Secur32.dll, Module Filename =
C:\WINDOWS\system32\Secur32.dll
Module ID = 71AD0000, Module Name = WSOCK32.dll, Module Filename =
C:\WINDOWS\system32\WSOCK32.dll
Module ID = 71AB0000, Module Name = WS2_32.dll, Module Filename =
C:\WINDOWS\system32\WS2_32.dll
Module ID = 77C10000, Module Name = msvcrt.dll, Module Filename =
C:\WINDOWS\system32\msvcrt.dll
Module ID = 71AA0000, Module Name = WS2HELP.dll, Module Filename =
C:\WINDOWS\system32\WS2HELP.dll
Module ID = 7E410000, Module Name = USER32.dll, Module Filename =
C:\WINDOWS\system32\USER32.dll
Module ID = 77F10000, Module Name = GDI32.dll, Module Filename =
C:\WINDOWS\system32\GDI32.dll
Module ID = 78520000, Module Name = MSVCR90.dll, Module Filename =
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.dll
Module ID = 76390000, Module Name = IMM32.DLL, Module Filename =
C:\WINDOWS\system32\IMM32.DLL
Module ID = 629C0000, Module Name = LPK.DLL, Module Filename =
C:\WINDOWS\system32\LPK.DLL
Module ID = 74D90000, Module Name = USP10.dll, Module Filename =
C:\WINDOWS\system32\USP10.dll
No apparent base address conflicts with the loader and libeay32.dll
(preferred base at the default 0x0FB00000).
Dependency Walker was running the app. at the time and showed the
following output:
LoadLibraryA("out32dll\libeay32.dll") called from "FIPS_PREMAIN_DSO.EXE"
at address 0x00412540.
LoadLibraryA("out32dll\libeay32.dll") returned NULL. Error: %1 is not a
valid Win32 application (193).
Needless to say, given the lack of response and further web searching
reveals issues with older VC++ linkers core dumping(?) against the
latest MinGW and I've already put forth 30+ hours (not counting the
preparation time of several months!), two CD-Rs, and who knows how much
money into an attempted production of a default OpenSSL FIPS 140-2
compliant binary build for Windows (complete with fancy installer), I'm
going to simply hold off until 1.2.0 becomes available and then try
again at that time. Mixing together binaries from two totally different
compilers is not only a bad idea, it is a horrifically terrible idea.
The fact that this supposedly works at all for some people is a miracle.
Supposedly, from what I've read, 1.2.0 doesn't require mixing compilers.
That should significantly clean things up. Assuming, of course, "not
mixing compilers" allows the use of VC++. If I have to use MinGW, I
will be very annoyed. I'm also hoping I can compile against 0.9.8x
instead of 0.9.7m.
Case closed. For the time being. I'm all OpenSSL'ed out.
--
Thomas Hruska
Shining Light Productions
Home of BMP2AVI, Nuclear Vision, ProtoNova, and Win32 OpenSSL.
http://www.slproweb.com/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
