Has anyone seen _Crypt_DeriveKey failures?

[SteveSchumacher]

Using 3.3.14.5 for current version of a production script, I have a 32bit-built exe that runs on 100's of PC's except 1, Windows 7-64 and Windows 10-64 machines in our environment.

On that (Windows 10/64bit) PC, _Crypt_DeriveKey returns an @error of 30, consistently (@error is consistently 0 set in _Crypt_Startup.)

Other versions of this code, have been run on 5000 or 6000 occasions for the last 3 years without ever seeing an error with the encryption-related bits.

Just wondered if anyone else has experienced this and found the problem (which I think must be with the OS, or with a/v, not this AutoIT function, right?.)

(I can turn off some a/v-security software but not all in our environment.)

Simplified version of the script follows.

(Have run this on the PC in question, monitoring processes via procmon, so am waiting for this (overseas) customer to FTP me a large *.PML for more investigation on my end; I only have occasional access to this PC.)
 

expandcollapse popup

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_UseX64=n
#AutoIt3Wrapper_Res_Language=1033
#AutoIt3Wrapper_AU3Check_Stop_OnWarning=y
#AutoIt3Wrapper_Run_Au3Stripper=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

#include <Crypt.au3>
#include <EditConstants.au3>
#include <MsgBoxConstants.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>

Local $bAlgorithm = $CALG_RC4
Local $CRYPT_KEY = "ExampleCryptKey"
Local $IAM = "Test"

Local $MSG =  $IAM & "-Debugging"

; Encryption startup
_Crypt_Startup() ; To optimize performance start the crypt library.
Local $ERRCODE = @error
MsgBox(1,$MSG,"@error from _Crypt_Startup:" & $ERRCODE)

;Set Algorithm, encryption key
Local $bAlgorithm = $CALG_RC4
Local $hKey = _Crypt_DeriveKey( $CRYPT_KEY, $bAlgorithm)
MsgBox(1,$MSG,"@error from Crypt_DeriveKey:" & @error)
MsgBox(1,$MSG,"hKey generated:" & $hKey)

; Encrypt a simple string, display the string before and after
Local $TEST_STRING = "ABC"
MsgBox(1,$MSG,"About to encrypt string:" & $TEST_STRING)
Local $bEncrypted = _Crypt_EncryptData( $TEST_STRING, $hKey, $CALG_USERKEY)
MsgBox(1,$MSG,"RC from crypt:" & @error)
MsgBox(1,$MSG,"Encrypted string:" & $bEncrypted)

;Encryption close down
_Crypt_DestroyKey($hKey) ; Destroy the cryptographic key.
_Crypt_Shutdown() ; Shutdown the crypt library.

There is nothing obvious in the application or system event logs, and have also tried turning on logs in the Windows Logs>Applications and Services Logs>Microsoft>Windows>Crypto-DP
API and Crypto-NCrypt group of logs that weren't already enabled using the highly scientific criteria that they contained the string "crypt". (Gr-hilk.)

Let me know if anyone has seen this issue, or can provide guidance on what the problem might be or how best to either find or fix it.

Thanks all -

Edited March 7, 2019 by SteveSchumacher
Forgot to mention that _Crypt_DeriveKey is the first point of failure, that _Crypt_Startup does not generate a non-zero @error

[AdamUL]

This looks like a 32-bit redirection issue on the 64-bit systems with a 32-bit script.  Try adding the following to the top of your script.  

#include <WinAPIFiles.au3>

;Disable x86 redirection mechanism for a 32-bit script.
If @OSArch = "X64" And Not @AutoItX64 Then _WinAPI_Wow64EnableWow64FsRedirection(False)

 

Adam

[SteveSchumacher]

Adam; thanks for your time and the suggestion; this simplified code snippet provided works fine on my own Win10-64bit PC but have added it to the snippet and am waiting for my overseas customer to give it a go. I'll reply when I hear back from him.

[SteveSchumacher]

Adam; THANK YOU! I don't know why this worked but it did; there must be a PC-configuration-related difference since it worked without this modification on other Win10-64bit PC's. Kudos man -

[AdamUL]

Your welcome.  The _Crypt functions use a dll.  Since you compiled the script as 32-bit, Windows was redirecting the script to try to use the 32 bit version on 64 bit systems.  This caused the failures.  Turning off the redirection, allowed the script to use the 64-bit version on 64 bit systems with a 32 bit script.  Some of you systems may have the redirection turned off, or some other setting that disables the redirection.  

For more information, please see the links below.  

https://www.autoitscript.com/autoit3/docs/intro/64-bit_support.htm

https://docs.microsoft.com/en-us/windows/desktop/winprog64/running-32-bit-applications

https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector

 

Adam