linking problem in DPAPI

linking problem in DPAPI

[bubble]

dear all:
I got a problem again :)

I am write a little security binding for my application.
and I got a error message.
....app.o(.text+0x3914):app.adb: undefined reference to 
`CryptProtectData@28'

what's the problem?
give me a hint. thanks
my compiler is [gnat gpl 2005] and my OS is windows xp.



with Win32;
With Win32.Windef;

package app.Security Is


   type Data_Blob is record
      Cbdata : Win32.DWORD;
      Pbdata : Win32.PBYTE;
   end record;
   Pragma Convention(c_pass_by_copy,Data_Blob);

   Type Access_Data_Blob Is Access All Data_Blob;

   Type CRYPTPROTECT_PROMPTSTRUCT Is Record
      Cbsize:Win32.Dword;
      DwPromptFlags:Win32.DWord;
      Hwandapp:Win32.Windef.Hwnd;
      SzPrompt:Win32.Lpcwstr;
   End Record;
   Pragma Convention(c_pass_by_copy,CRYPTPROTECT_PROMPTSTRUCT);
   Type Access_CRYPTPROTECT_PROMPTSTRUCT Is Access All 
CRYPTPROTECT_PROMPTSTRUCT;


   Function CryptProtectData(Pdatain:Access_Data_Blob;
                             SzDataDescr:Win32.Lpcwstr;
                             POptionalEntropy:Access_Data_Blob;
                             PvReserved:Win32.Pvoid;
                             pPromptStruct 
:Access_CRYPTPROTECT_PROMPTSTRUCT;
                             dwFlags :Win32.Dword;
                             Pdataout:Access_Data_Blob) Return Win32.Bool;
   Pragma Import(Stdcall,CryptProtectData,"CryptProtectData");
   Pragma Linker_Options("-lcrypt32");




end app.Security;

Re: linking problem in DPAPI

[Stephen Leake]

"bubble" <bubble@riskm.com.tw> writes:

> dear all:
> I got a problem again :)
>
> I am write a little security binding for my application.
> and I got a error message.
> ....app.o(.text+0x3914):app.adb: undefined reference to 
> `CryptProtectData@28'
>
> what's the problem?
> give me a hint. thanks
> my compiler is [gnat gpl 2005] and my OS is windows xp.

I have GNAT 5.03a, Windows XP.

This appears to be a library version problem. 'CryptProtectData'
doesn't appear to be in lib/gcc/pentium-mingw32msv/3.4.4/libcrypt32.a,
nor in any other library file in that directory.

However, 'CryptProtectData' is in Windows/system32/crypt32.dll.

So I suggest you use one of the dll tools to recreate libcrypt32.a
from Windows/system32/crypt32.dll, and see if that works. If it does,
send a bug report to AdaCore.

-- 
-- Stephe

Re: linking problem in DPAPI

[bubble]

hello,Stephen

I find a tools , "dll2s"  ,in http://home.lanck.net/mf/win_pe.shtml#D2
generator a crypt32.a and replace the libcrypt32.a in 
lib/gcc/pentium-mingw32msv/3.4.5....
and I stilll get the same error message.
I am not sure I am do it correctly.
could you possible do the test in your way?

"Stephen Leake" <stephen_leake@acm.org> ???????:u3bkdz9qs.fsf@acm.org...
> "bubble" <bubble@riskm.com.tw> writes:
>
>> dear all:
>> I got a problem again :)
>>
>> I am write a little security binding for my application.
>> and I got a error message.
>> ....app.o(.text+0x3914):app.adb: undefined reference to
>> `CryptProtectData@28'
>>
>> what's the problem?
>> give me a hint. thanks
>> my compiler is [gnat gpl 2005] and my OS is windows xp.
>
> I have GNAT 5.03a, Windows XP.
>
> This appears to be a library version problem. 'CryptProtectData'
> doesn't appear to be in lib/gcc/pentium-mingw32msv/3.4.4/libcrypt32.a,
> nor in any other library file in that directory.
>
> However, 'CryptProtectData' is in Windows/system32/crypt32.dll.
>
> So I suggest you use one of the dll tools to recreate libcrypt32.a
> from Windows/system32/crypt32.dll, and see if that works. If it does,
> send a bug report to AdaCore.
>
> -- 
> -- Stephe 

Re: linking problem in DPAPI

[Jeffrey Creem]

bubble wrote:
> hello,Stephen
> 
> I find a tools , "dll2s"  ,in http://home.lanck.net/mf/win_pe.shtml#D2
> generator a crypt32.a and replace the libcrypt32.a in 
> lib/gcc/pentium-mingw32msv/3.4.5....
> and I stilll get the same error message.
> I am not sure I am do it correctly.
> could you possible do the test in your way?

Probably not that helpful but looking at this

https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1232427&group_id=2435

Looks like there is more trouble down the road (more missing symbols) in 
this library.

In another message you asked why gcc (actually ld) can't just use a .lib 
file under windows


Take a look at this

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html

Not sure it will help, but it looks promising (may require you to add 
some -L flags or re-arrange your environment)



Also, I was pretty sure that more recent versions of gcc/ld could 
directly link to a .lib.

Re: linking problem in DPAPI

[Stephen Leake]

"bubble" <bubble@riskm.com.tw> writes:

> hello,Stephen
>
> I find a tools , "dll2s"  ,in http://home.lanck.net/mf/win_pe.shtml#D2

Well, I meant the dll tools that come with GNAT. Read the user guide.
It's been a while since I had to do this.

-- 
-- Stephe

Re: linking problem in DPAPI

[bubble]

a good news.
my guess is wrong.
ld seem can direct linking to a dll...
2nd url,Jerrrey provid.
It said...

<copy from 
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html>

direct linking to a dll
The cygwin/mingw ports of ld support the direct linking, including data 
symbols, to a dll without the usage of any import libraries. This is much 
faster and uses much less memory than does the traditional import library 
method, expecially when linking large libraries or applications. When ld 
creates an import lib, each function or variable exported from the dll is 
stored in its own bfd, even though a single bfd could contain many exports. 
The overhead involved in storing, loading, and processing so many bfd's is 
quite large, and explains the tremendous time, memory, and storage needed to 
link against particularly large or complex libraries when using import libs.

Linking directly to a dll uses no extra command-line switches other than -L 
and -l, because ld already searches for a number of names to match each 
library. All that is needed from the developer's perspective is an 
understanding of this search, in order to force ld to select the dll instead 
of an import library.

For instance, when ld is called with the argument -lxxx it will attempt to 
find, in the first directory of its search path,

libxxx.dll.a
xxx.dll.a
libxxx.a
cygxxx.dll (*)
libxxx.dll
xxx.dll



</copy from 
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html>


after some error.
I have a solution.

I copy crypt32.dll from c:\windows\system32 to project home.
and change pragma  (not use Stdcall Calling Convention ).
pragma Import (C, CryptProtectData, "CryptProtectData");
then it work..

I have new question..
in windows SDK document ,the WINAPI declare should mapping to Stdcall.
It's mean who's responsibility to clean stack frame.
http://www.unixwiz.net/techtips/win32-callconv.html
if I use "C" calling conventions in a "WINAPI" funciton , colud system clean 
stack twice and cause some problems?



> Well, I meant the dll tools that come with GNAT. Read the user guide.
> It's been a while since I had to do this.

Re: linking problem in DPAPI

[Stephen Leake]

"bubble" <bubble@riskm.com.tw> writes:

> <copy from 
> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html>
>
> direct linking to a dll
> The cygwin/mingw ports of ld support the direct linking, including data 
> symbols, to a dll without the usage of any import libraries. 

Interesting. 

> after some error.
> I have a solution.
>
> I copy crypt32.dll from c:\windows\system32 to project home.
> and change pragma  (not use Stdcall Calling Convention ).
> pragma Import (C, CryptProtectData, "CryptProtectData");
> then it work..

As you discover below, "linking" is not the same as "working".

> I have new question..
> in windows SDK document ,the WINAPI declare should mapping to Stdcall.
> It's mean who's responsibility to clean stack frame.
> http://www.unixwiz.net/techtips/win32-callconv.html
> if I use "C" calling conventions in a "WINAPI" funciton , colud system clean 
> stack twice and cause some problems?

Yes, you will eventually get a stack error; either overflow or underflow.

The problem is that the 'Convention' parameter in 'pragma Import'
speficies two things; the 'calling convention' (who pops the stack),
and the 'naming convention' (how the name is mangled in the DLL).

Microsoft has two naming conventions for the StdCall calling
convention; the 'old' one (pre Windows NT) that appends '@nn' where
'nn' is the number of bytes on the stack, and the 'new' one without
the @nn.

Ada has no way to distinguish between the two. A while ago (May 2004)
I had a similar problem, and tried to get AdaCore to provide a
Convention identifier for the 'new' StdCall naming convention; they
didn't believe it was necessary.

On the other hand, the "Link_Name" parameter to 'pragma Import' should
allow you to specify the correct name. In 2004 (GNAT 3.15?) the
compiler added '@nn' even to the Link_Name; AdaCore promised to fix
that.

So you should try using:

    pragma Import (StdCall, CryptProtectData, 
         External_Name => "CryptProtectData", 
         Link_Name => "CryptProtectData");

If that doesn't work, you'll have to build an import library that uses
the StdCall calling convention with the new naming convention. That is
done via the following steps (as recommended by AdaCore):

dll2def crypt32.dll > crypt32.def

_manually_ edit cyrpt32.def to add the appropriate @nn. 
(this step is just ridiculous, but it is required by the GNAT tools).

gnatdll -k -e cryp32.def -d crypt32.dll

The -k strips the @nn that you so laboriously added in the previous
step. Hmm. I guess that means the 'nn' in the .def doesn't have to be
correct; it just has to be there.

Hmm. I've just re-read the GNAT user's guide for 5.03a. It says GNAT
can use the .lib library files (Microsoft format). It also gives the
procedure I outlined above. 

However, my GNAT distribution doesn't contain dll2def. I found a
version (via Google) at
http://users.ncrvnet.nl/gmvdijk/packages.html#DLL2DEF
Hmm. That has source code; maybe we could fix it to add an option to
add the @nn.

In any case, send a bug report to AdaCore. Let them know how hard it
is to use their tools to do what should be a simple task. Maybe
they'll fix it eventually! Mention my bug report D525-020; that will
let them know it's not an isolated case.

Also ask how they build libcrypt32.a; I can't believe they manually
edit a .def file!

-- 
-- Stephe

Re: linking problem in DPAPI

[Pascal Obry]

Stephen Leake a �crit :
> "bubble" <bubble@riskm.com.tw> writes:
> 
> 
>><copy from 
>>http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html>
>>
>>direct linking to a dll
>>The cygwin/mingw ports of ld support the direct linking, including data 
>>symbols, to a dll without the usage of any import libraries. 
> 
> 
> Interesting. 

This is something supported since version 5.03 if my memory is correct.

> However, my GNAT distribution doesn't contain dll2def. I found a
> version (via Google) at
> http://users.ncrvnet.nl/gmvdijk/packages.html#DLL2DEF
> Hmm. That has source code; maybe we could fix it to add an option to
> add the @nn.

I don't think this is possible. When a DLL has stripped @nn there is no
way to reconstruct this suffix automatically.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: linking problem in DPAPI

[bubble]

> I copy crypt32.dll from c:\windows\system32 to project home.
> and change pragma  (not use Stdcall Calling Convention ).
> pragma Import (C, CryptProtectData, "CryptProtectData");
> then it work..

I can invoke the CryptProtectData,CryptUnprotectData and get a output.
then it will crash after executing some statement.
the result is in expect and bad.

and I have test
    pragma Import (Stdcall, CryptProtectData, 
"CryptProtectData","CryptProtectData");
and still fail in linking.

crypt functions loading by loadLibrary and GetProcAddress have some strange 
behaviors ,I am still in testing.


a document from MS has explain calling convention more.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_Calling_Conventions_Topics.asp

I don't the understand the reason why MS need 2 different " STDCALL " 
calling convention.
(maybe MS's programers confused or they using special naked function call in 
security issuse)
If MS really want 2 stdcall, they should be name stdcall and stdcall2 or 
something.
the problem should forward to MS news group.
It's not ada compiler or linker problem...     :(

if therer is no way to remove @xxx in function suffix,
may be I can add "esp register adjust" patch code after  calling crypt 
family functions.   :(

> I have new question..
> in windows SDK document ,the WINAPI declare should mapping to Stdcall.
> It's mean who's responsibility to clean stack frame.
> http://www.unixwiz.net/techtips/win32-callconv.html
> if I use "C" calling conventions in a "WINAPI" funciton , colud system 
> clean stack twice and cause some problems?
>
>
>
>> Well, I meant the dll tools that come with GNAT. Read the user guide.
>> It's been a while since I had to do this.
>
> 

Re: linking problem in DPAPI

[Stephen Leake]

"bubble" <bubble@riskm.com.tw> writes:

>> I copy crypt32.dll from c:\windows\system32 to project home.
>> and change pragma  (not use Stdcall Calling Convention ).
>> pragma Import (C, CryptProtectData, "CryptProtectData");
>> then it work..
>
> I can invoke the CryptProtectData,CryptUnprotectData and get a output.
> then it will crash after executing some statement.

Right; that's typcial of stack corruption.

> and I have test
>     pragma Import (Stdcall, CryptProtectData, 
> "CryptProtectData","CryptProtectData");
> and still fail in linking.

Ah, too bad. Please send a bug report to 'report@gnat.com'.

> crypt functions loading by loadLibrary and GetProcAddress have some strange 
> behaviors ,I am still in testing.

Ok. You _really_ should not have to do that!

> a document from MS has explain calling convention more.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_Calling_Conventions_Topics.asp

Interesting. They don't document the "stripped" naming convention,
even though all the current DLLs use it.

Still, that's typical of Microsoft; the documentation is very poor.

> I don't the understand the reason why MS need 2 different " STDCALL
> " calling convention. (maybe MS's programers confused or they using
> special naked function call in security issuse)

With current tools, the "@nn" notation serves no purpose. I suspect
someone got tired of having to put them in by hand, and invented a new
convention that doesn't have them.

> If MS really want 2 stdcall, they should be name stdcall and
> stdcall2 or something. 

Yes. The fact that they have _not_ clearly documented the current
convention makes it harder to get the Ada compiler companies to suppor
it. 

> the problem should forward to MS news group. It's not ada compiler
> or linker problem... :(

Well, to the extent that we have to make our tools work with it, it
_is_ an Ada compiler problem.

A separate problem is getting MS to document what they are doing.

> if therer is no way to remove @xxx in function suffix,
> may be I can add "esp register adjust" patch code after  calling crypt 
> family functions.   :(

I doubt that will work.

Clearly there _is_ a way to produce the right library; AdaCore does it
for each release of GNAT.

The only way I'm aware of at the moment involves manually editing the
.def file produced by dll2def. But I'm pretty sure you don't need to
get the "nn" _correct_, since it will be stripped out by gnatdll
anyway. So just use an editor macro (or 'sed' script) to add @4 to
each function name; that should not be hard.

-- 
-- Stephe

Re: linking problem in DPAPI

[bubble]

dear all:

if the test fail.
maybe I should choose Explicit linking  by loadLibrary,GetProcAddress 
function in

    Package body XXX
     begin
            -----start loadLibrary and GetProcAddress...
    end XXX;

but It's not so friendly...





<complain>
    off the topic...
    in MS-windows environment,sometime gcc(not ada) make me confused.
    why ld.exe can not link .lib format directly?
    I must say those problems will effect someone learning ada and 
misunderstand it.
</complain>



"Stephen Leake" <stephen_leake@acm.org> ???????:u3bkdz9qs.fsf@acm.org...
> "bubble" <bubble@riskm.com.tw> writes:
>
>> dear all:
>> I got a problem again :)
>>
>> I am write a little security binding for my application.
>> and I got a error message.
>> ....app.o(.text+0x3914):app.adb: undefined reference to
>> `CryptProtectData@28'
>>
>> what's the problem?
>> give me a hint. thanks
>> my compiler is [gnat gpl 2005] and my OS is windows xp.
>
> I have GNAT 5.03a, Windows XP.
>
> This appears to be a library version problem. 'CryptProtectData'
> doesn't appear to be in lib/gcc/pentium-mingw32msv/3.4.4/libcrypt32.a,
> nor in any other library file in that directory.
>
> However, 'CryptProtectData' is in Windows/system32/crypt32.dll.
>
> So I suggest you use one of the dll tools to recreate libcrypt32.a
> from Windows/system32/crypt32.dll, and see if that works. If it does,
> send a bug report to AdaCore.
>
> -- 
> -- Stephe 

Re: linking problem in DPAPI

[Stephen Leake]

"bubble" <bubble@riskm.com.tw> writes:

> <complain>
>     off the topic...
>     in MS-windows environment,sometime gcc(not ada) make me confused.
>     why ld.exe can not link .lib format directly?

I guess by ".lib" you mean the Microsoft library format, and by
"ld.exe" you mean the linker that comes with GNAT. Then the
answer is "GNAT is free software, Microsoft isn't". On the other hand,
you _could_ reverse engineer the Microsoft library format, and add
support for it to Gnu ld

>     I must say those problems will effect someone learning ada and
> misunderstand it. </complain>

Normally, it's not a problem, because AdaCore does a good job of
creating the necessary library files.

-- 
-- Stephe