Windows CryptProtectMemory API

[deltarho[1859]]

I want to use the Windows CryptProtectMemory API.

I did a forum search but not found. This does not mean that nobody is using it but it may indicate that it is by no means a popular API.

In PowerBASIC I could use something like this:

Code: Select all

#COMPILE EXE "test.exe"
#DIM ALL
#INCLUDE "Win32API.inc"
 
Function PBmain
Dim Buffer As String
Local Result as Dword
 
Buffer = String$(131072, 0)
Result = CryptProtectMemory( ByVal StrPtr(Buffer), Len(Buffer), 0 )
If IsTrue Result Then Print "Success" Else Print "Failure"
 
Waitkey$
 
END FUNCTION

That compiles and I get "Success" printed.

CryptProtectMemory is in PB's WinCrypt.inc but I don't need to know that as Win32API.inc is almost a 'catch all' include file. Sometimes we need to know which inc file is needed but not often.

With FreeBASIC I have to search the bi files for CryptProtectMemory. No big deal but a pain nonetheless.

This is my first attempt in FreeBASIC.

Code: Select all

#include once "windows.bi"
#include once "win/wincrypt.bi"
 
Dim Buffer( 1 To 131072) As Byte
Dim As Any Ptr ptrBaseBuffer = @Buffer(1)
Dim As Ulong Result
 
Result = CryptProtectMemory( Cast(LPVOID, ptrBaseBuffer), Ubound(Buffer), 0 )
If Result = TRUE Then Print "Success" Else Print "Failure"
 
Sleep

I get 'undefined reference to `CryptProtectMemory@12'

Ok, so I need a library. MSDN tells me that CryptProtectMemory is in Crypt32.dll. Another search and more pain.

So, I tried this:

Code: Select all

#include once "windows.bi"
#include once "win/wincrypt.bi"
#inclib "crypt32"   ' Added
 
Dim Buffer( 1 To 131072) As Byte
Dim As Any Ptr ptrBaseBuffer = @Buffer(1)
Dim As Ulong Result
 
Result = CryptProtectMemory( ptrBaseBuffer, 131072, 0 )
If Result = TRUE Then Print "Success" Else Print "Failure"
 
Sleep

I still get 'undefined reference to `CryptProtectMemory@12'.

So, I loaded the binary of libcrypt32.dll.a into TextPad and searched for CryptProtectMemory. It was not there. CryptProtectMemory is declared in wincrypt.bi.

No import library then. Oh, well I will have to use my own declare.

Code: Select all

#include once "windows.bi"
Declare Function CryptProtectMemory Lib "Crypt32.dll" Alias "CryptProtectMemory" _
  (byval pDataIn as LPVOID, byval cbDataIn as DWORD, byval dwFlags as DWORD) as WINBOOL
 
Dim Buffer( 1 To 131072) As Byte
Dim As Any Ptr ptrBaseBuffer = @Buffer(1)
Dim As Ulong Result
 
Result = CryptProtectMemory( Cast(LPVOID, ptrBaseBuffer), 131072, 0 )
If Result = TRUE Then Print "Success" Else Print "Failure"
 
Sleep 

I still get 'undefined reference to `CryptProtectMemory@12'

Way back in January I wrote a general Hash & HMAC routine which included many Windows APIs without all this none-sense.<smile>

CryptProtectMemory was introduced in Windows Vista so it is not a new API.

Clearly I have more jumping through hoops to do but I am scratching my head as to what to do next.

Usual question: What am I doing wrong now?

[MrSwiss]

Code: Select all

#Include "windows.bi"

Declare Function CryptProtectMemory Lib "Crypt32.dll" Alias "CryptProtectMemory" _
  (byval pDataIn as LPVOID, byval cbDataIn as DWORD, byval dwFlags as DWORD) as WINBOOL
 
Dim Buffer(1 To 131072) As Byte
Dim As Any Ptr ptrBaseBuffer = @Buffer(1)
Dim As Boolean Result
 
Result = CryptProtectMemory(ptrBaseBuffer, 131072, 0)
If Result Then Print "Success" Else Print "Failure"

Sleep

Result = "FALSE"

[deltarho[1859]]

@MrSwiss

I take it that Result = "FALSE" should have been Result = "Failure"

With your code I am getting 'undefined reference to `CryptProtectMemory@12' in both FBEdit and poseidonFB.

I have just compiled and run the example in my Hash & HMAC thread to make sure that is still working and it is.

[dodicat]

Win 10 using the 64 bit compiler, the function is found .
But not the 32 bit compiler.

[deltarho[1859]]

Win 10 using the 64 bit compiler, the function is found .
But not the 32 bit compiler.

Strewth!

My second FreeBASIC attempt in the opening post now works, using 64 bit, and Result corrected to Boolean( as per MrSwiss ).

Are we saying then that we cannot use CryptProtectMemory in 32 bit mode?

If so it is not the end of the world, I will use PowerBASIC but I should not have to, should I?

[dodicat]

Personally, I would avoid freebasic booleans.
Just use long, it is just as fast.

I copied crypt32.dll into a folder.
The function is in it (I created a .def text file), and there it is, bold as brass.
....
CryptObjectLocatorGetUpdated
CryptObjectLocatorInitialize
CryptObjectLocatorIsChanged
CryptObjectLocatorRelease
CryptProtectData
CryptProtectMemory <----------- here it is
CryptQueryObject
CryptRegisterDefaultOIDFunction
CryptRegisterOIDFunction
....
I tried running the code from the dll folder (32 bit FB).
I got
undefined reference to `CryptProtectMemory@12'
I'll have a fiddle around.

[MrSwiss]

Are we saying then that we cannot use CryptProtectMemory in 32 bit mode?

I rather think, it's a DLL-hell issue, since: the "Crypt32.dll" loaded, is (on a 64 bit WIN)
a 64 bit .dll, which can't be accessed from a 32 bit program.
(maybe, with a path to WoW's version of .dll working?)

C:\Windows\SysWoW64\Crypt32.dll --> just a guess ...
WoW = Windows(32) on Windows(64), internal Emulator for 32 bit Applications.

[deltarho[1859]]

Personally, I would avoid freebasic booleans.
Just use long, it is just as fast.

I get "Failure" if I do that with my second FreeBASIC attempt. I will play it safe - if the FreeBASIC declaration uses Boolean as a return value then that is what I will ask for. With my own functions I wouldn't use Boolean.

I'll have a fiddle around.

Great.

@MrSwiss

I use WOW in my GUIRuler:

Code: Select all

Magnify

This invokes the Windows magnify application. The application used will depend upon whether you have a 32 bit or 64 bit operating system

I don't really want to go down that route since I can use CryptProtectMemory in PowerBASIC without batting an eyelid.

[srvaldez]

hello
the import lib needs updating, I made a new libcrypt32.dll.a
if you want to build it yourself do
gendef crypt32.dll
dlltool -d crypt32.def -l libcrypt32.dll.a

[deltarho[1859]]

if you want to build it yourself do
gendef crypt32.dll
dlltool -d crypt32.def -l libcrypt32.dll.a

That is way outside of my comfort zone.

Replaced libcrypt32.dll.a with your update and CryptProtectMemory is still not working in 32 bit.

[MrSwiss]

srvaldez, just tried your .dll.a (with FBC 32 bit), it's still giving the 'old' error message ...

As stated by dodicat: WIN10 / 64 bit OS / FBC 64 bit = everything OK!

CryptProtectMemory in PowerBASIC without batting an eyelid.

Just until PB goes 64 bit, also ... <laugh>

[srvaldez]

you may need to use extern "Windows-MS" with the CryptProtectMemory declaration

[MrSwiss]

you may need to use extern "Windows-MS" with the CryptProtectMemory declaration

OK, that did the trick ... thanks srvaldez.
I've tried that before, with the 'old' .dll.a, without success (as usual: details).

[deltarho[1859]]

I have just checked srvaldez's new binary and both CryptProtectMemory and CryptUnProtectMemory are there which they were not before.

Just until PB goes 64 bit, also ... <laugh>

But the point is I want to use 32 bit and at the moment PowerBASIC can and FreeBASIC cannot. I won't laugh because it isn't funny.

you may need to use extern "Windows-MS" with the CryptProtectMemory declaration

That did it!

Funny thing is I tried that yesterday but that had no chance of working with the 'old' libcrypt32.dll.a.

Great work - srvaldez.

MrSwiss posted at the same time as me.

Added: This begs the question why do we have to use Extern when we don't have to with this:

Code: Select all

Declare Function MyRandomInt Lib "Advapi32.dll" Alias "SystemFunction036" _
 ( RandomBuffer As Any Ptr, RandomBufferLength As ULong ) As Byte

Of course, having to use Extern on my declaration explains why

Code: Select all

#include once "win/wincrypt.bi"
#inclib "crypt32" 

still does not work.

[MrSwiss]

This begs the question why do we have to use Extern when we don't have to with this

The Extern itself, makes no difference, the "Windows-MS" vs. "Windows" (FBC 64) does ...
It's to do with the "@.." appended to the Sub/Function-Name ... (Windows-MS, chops that off, on FBC 32).