GetProcAddress liefert kein Ergebnis unter Win64, unter Win32 schon

[Bbommel]

Hi zusammen,

ich komme nicht mehr weiter und brauche mal Tipps von euch. Direkt vorweg: "ja, du musst ja auch die 64-Bit-DLL nehmen, wenn du für 64-Bit kompilierst!" werden vielleicht einige direkt zurecht antworten wollen. Ja, habe ich. Ganz so einfach ist es leider nicht. Geht noch nicht mal um meinen eigenen Code, sondern um eine Bibliothek, die ich nutzen möchte. Aber der Reihe nach:

Wenn man sich mit "modernen" Anmeldeverfahren im Netz rumschlägt, dann stolpert man irgendwann über OAuth2 und die "Access Token" und "Identity Token", die man da so bekommt. Meistens liegen diese Token in Form eines "JSON Web Tokens" vor, welche diverse Informationen über die Anmeldung enthalten und schließlich auch mit einem Zertifikat signiert sind, mit dem man die Echtheit prüfen kann und soll. Damit man nicht bei Null anfangen muss, wenn man so ein Token auswerten und prüfen will, haben andere zum Glück schon vorgearbeitet, in dem Fall gibt es u.a. die Delphi JOSE and JWT Library von Paolo Rossi. Hier ist vor allem auch die ganze Zertifikatsprüfung mit eingebaut und die basiert zum Teil wiederum auf OpenSSL.

Und hier kommt es nun zu meinem Problem. Folgender Code aus der Unit JOSE.Signing.RSA von Paolo:

Delphi-Quellcode:

unit JOSE.Signing.RSA;

interface

uses
  [...]IdSSLOpenSSLHeaders,
  [...]

class procedure TRSA.LoadOpenSSL;
begin
  if not IdSSLOpenSSLHeaders.Load then
    raise Exception.Create('[RSA] Unable to load OpenSSL libraries');

  if @EVP_DigestVerifyInit = nil then
    raise Exception.Create('[RSA] Please, use OpenSSL 1.0.0. or newer!');

  if GetCryptLibHandle <> 0 then
  begin
    // *** Die folgende Zeile macht nicht, was sie soll! ***
    _PEM_read_bio_RSA_PUBKEY := GetProcAddress(GetCryptLibHandle, 'PEM_read_bio_RSA_PUBKEY');
    if @_PEM_read_bio_RSA_PUBKEY = nil then
      raise Exception.Create('[RSA] Unable to get proc address for "PEM_read_bio_RSA_PUBKEY"');

    [...]
  end;
end;

Hier soll also

Delphi-Quellcode:

GetProcAddress(GetCryptLibHandle, 'PEM_read_bio_RSA_PUBKEY')

in der libeay32.dll die Funktion PEM_read_bio_RSA_PUBKEY finden. Die Funktion

Delphi-Quellcode:

GetCryptoLibHandle

kommt aus der Indy-Unit IdSSLOpenSSLHeaders und liefert das Handle auf die libeay32.dll. Unter Win32 funktioniert das auch alles ganz wunderbar. Unter Win64 bekomme ich immer ein NIL von der Funktion.

Mit einem "DLL Export Viewer" habe ich gesehen, dass die gesuchte Funktion in der DLL auch tatsächlich existiert. Mit dem ProcessMonitor habe ich geprüft, dass auch tatsächlich die richtige, 64 bittige Version von libeay32.dll geladen wird. Wird sie ohnehin schon vorher, weil das ganze in einer Web Broker-Anwendung läuft, die auch auf OpenSSL zugreift. Da kann man beim Debuggen dann auch sehen, dass die ganzen Funktionen auch unter Win64 in der dll problemlos gefunden werden, wenn man sich die Funktion "Load" in der IdSSLOpenSSLHeaders anguckt und da einen Breakpoint setzt. Nur oben klappt es nicht.

Ich hab auch schon mal

Delphi-Quellcode:

@_PEM_read_bio_RSA_PUBKEY := GetProcAddress(GetCryptLibHandle, PChar('PEM_read_bio_RSA_PUBKEY'));

probiert, aber das brachte keinen Unterschied.

Hat irgendwer irgendeine Idee?

(Zur Info: hab das auch in einem Issue auf Github gepostet, weil dort schon jemand ein ähnliches Problem mit Mac32/Mac64 hatte)

[venice2]

Zitat:

Ich hab auch schon mal

Delphi-Quellcode:

@_PEM_read_bio_RSA_PUBKEY := GetProcAddress(GetCryptLibHandle, PChar('PEM_read_bio_RSA_PUBKEY'));

definition in 64Bit..

Delphi-Quellcode:

function GetProcAddress(hModule: HMODULE; lpProcName: LPCSTR): FARPROC; external kernel32 name 'GetProcAddress';
function GetProcAddress(hModule: HMODULE; lpProcName: LPCWSTR): FARPROC;
begin
  if ULONG_PTR(lpProcName) shr 16 = 0 then // IS_INTRESOURCE
    Result := GetProcAddress(hModule, LPCSTR(lpProcName))
  else
    Result := GetProcAddress(hModule, LPCSTR(TMarshal.AsAnsi(lpProcName)));
end;

Aber keine Ahnung ob dir das hilft.

Habe da einiges recherchiert.
HModule <> THandle
Int <> IntPtr wenn die DLL geladen wird.

Viele haben damit ein Problem.
GetProcAddress 64bit

[himitsu]

Und natürlich kann man auch mal schauen, ob es auch einen Export mit diesem Namen in der 64-Bit-DLL gibt.
https://www.nirsoft.net/utils/dll_export_viewer.html

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1478024)

Und natürlich kann man auch mal schauen, ob es auch einen Export mit diesem Namen in der 64-Bit-DLL gibt.
https://www.nirsoft.net/utils/dll_export_viewer.html

Zitat:

Mit einem "DLL Export Viewer" habe ich gesehen, dass die gesuchte Funktion in der DLL auch tatsächlich existiert.

Hat er ja schon.

Aber ich finde den Key definitiv nicht!
Zumindest nicht in der DLL die ich auf dem System habe.

[Der schöne Günther]

Zitat:

Zitat von venice2 (Beitrag 1478023)

Habe da einiges recherchiert.
HModule <> THandle

Ganz sicher?

Windows SDK:

Code:

typedef PVOID HANDLE;
typedef HANDLE HINSTANCE;
typedef HINSTANCE HMODULE;

Die Delphi RTL ebenso:

Delphi-Quellcode:

  THandle = NativeUInt;
  HINST = THandle;              { HINSTANCE from widnef.h }
  HMODULE = HINST;              { from windef.h }

[venice2]

Zitat:

Zitat von Der schöne Günther (Beitrag 1478026)

Zitat:

Zitat von venice2 (Beitrag 1478023)

Habe da einiges recherchiert.
HModule <> THandle

Ganz sicher?

Windows SDK:

Code:

typedef PVOID HANDLE;
typedef HANDLE HINSTANCE;
typedef HINSTANCE HMODULE;

Die Delphi RTL ebenso:

Delphi-Quellcode:

  THandle = NativeUInt;
  HINST = THandle;              { HINSTANCE from widnef.h }
  HMODULE = HINST;              { from windef.h }

Es geht hier um 64Bit und 32Bit.
Nein aber so wie ich gelesen (Recherchiert) habe ist Cardinal 64Bit und THandle 32 oder?
http://codeverge.com/embarcadero.del...hi-get/1071384

[himitsu]

Zitat:

Zitat von venice2 (Beitrag 1478025)

Aber ich finde den Key definitiv nicht!

Ich seh ihn auf dem Bild auch nicht. :angle2:

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1478028)

Zitat:

Zitat von venice2 (Beitrag 1478025)

Aber ich finde den Key definitiv nicht!

Ich seh ihn auf dem Bild auch nicht. :angle2:

Hmmm. nur den hier! PEM_read_bio_RSAPUBKEY instead of PEM_read_bio_RSA_PUBKEY
Keine Ahnung wie viele DLL's es davon gibt.

[Der schöne Günther]

Zitat:

Zitat von venice2 (Beitrag 1478027)

Es geht hier um 64Bit und 32Bit.
Nein aber so wie ich gelesen (Recherchiert) habe ist Cardinal 64Bit und THandle 32 oder?

Am besten direkt an die Doku halten, da ist das klar definiert:
http://docwiki.embarcadero.com/Libra...ystem.Cardinal

Zitat:

The size of Cardinal is 32 bits across all 64-bit and 32-bit platforms.

http://docwiki.embarcadero.com/Libra...tem.NativeUInt

Zitat:

The size of NativeUInt is equivalent to the size of the pointer on the current platform.

Auch wenn ich nicht weiß was "Cardinal" damit jetzt zu tun hat.

Delphi-Quellcode:

HMODULE = HINST = THandle

, egal wieviel Bit.

[Bbommel]

Hallo zusammen,

Danke für euer erstes Feedback.

dass ich das schon geprüft habe, dass die Funktion auch wirklich vorhanden ist, hatte ich ja schon im Eingangspost geschrieben. Die Funktion ist in der DLL vorhanden (und auch in älteren Versionen der DLL). Also, wenn ich die OpenSSL-Doku richtig verstanden habe, müsste das zumindest in der Version 1.0.2 dabei sein.

Auszug aus dem DLL Export Viewer als Bildchen im Anhang.

Vielleicht gibt es ja tatsächlich irgendwelche Eigenarten bzgl. HModule <> THandle oder irgendwelcher anderer Typen bei der Funktion unter Win64. Ich versuche morgen mal mit frischem Kopf ein Demo-Projekt zu basteln.

[venice2]

Zitat:

Zitat von Der schöne Günther (Beitrag 1478030)

Zitat:

Zitat von venice2 (Beitrag 1478027)

Es geht hier um 64Bit und 32Bit.
Nein aber so wie ich gelesen (Recherchiert) habe ist Cardinal 64Bit und THandle 32 oder?

Am besten direkt an die Doku halten, da ist das klar definiert:
http://docwiki.embarcadero.com/Libra...ystem.Cardinal

Zitat:

The size of Cardinal is 32 bits across all 64-bit and 32-bit platforms.

http://docwiki.embarcadero.com/Libra...tem.NativeUInt

Zitat:

The size of NativeUInt is equivalent to the size of the pointer on the current platform.

Auch wenn ich nicht weiß was "Cardinal" damit jetzt zu tun hat.

Delphi-Quellcode:

HMODULE = HINST = THandle

, egal wieviel Bit.

Nun ja wie dem auch sei.
Ich arbeite unter 64Bit meistens mit LONG_PTR da bin ich auf der sicheren Seite.

Am ende habe ich nur versucht zu ergründen woran das liegen könnte.

[Der schöne Günther]

Ersetze doch auch das

Delphi-Quellcode:

raise Exception.Create(..)

mal durch RaiseLastOSError(), dann können wir auch sehen was Windows selbst dazu sagt warum es nicht geht.

Auch: Wir sehen dass du dir eine DLL anschaust, was sie denn exportierst. Aber sind wir uns wirklich sicher dass er auch genau diese DLL einlädt? Ich weiß nicht ob das wasserdicht ist, aber im Zweifelsfall führe ich immer where.exe im .exe-Verzeichnis aus und lasse sie nach der DLL suchen. Ich meine der listet die gefundenen Treffer in der gleichen Reihenfolge auf wie LoadLibrary(..) suchen würde...

[himitsu]

WHERE sollte nur den %PATH% zum Suchen nuzten, inkl. %PATHEXT%.
(WHERE /R sucht ähnlich wie FOR /R)

LoadLibrary macht da bissl was Anderes.
Aber Debugger, SysInternals oder GetModuleFileName (mit dem Handle der DLL) helfen.

[Bbommel]

Zitat:

Zitat von Der schöne Günther (Beitrag 1478033)

Ersetze doch auch das

Delphi-Quellcode:

raise Exception.Create(..)

mal durch RaiseLastOSError(), dann können wir auch sehen was Windows selbst dazu sagt warum es nicht geht.

Guter Hinweis, probiere ich nachher mal aus.

Zitat:

Zitat von Der schöne Günther (Beitrag 1478033)

Auch: Wir sehen dass du dir eine DLL anschaust, was sie denn exportierst. Aber sind wir uns wirklich sicher dass er auch genau diese DLL einlädt? Ich weiß nicht ob das wasserdicht ist, aber im Zweifelsfall führe ich immer where.exe im .exe-Verzeichnis aus und lasse sie nach der DLL suchen. Ich meine der listet die gefundenen Treffer in der gleichen Reihenfolge auf wie LoadLibrary(..) suchen würde...

Ihr seid euch nicht sicher, aber ich. :-) Ich hatte ja schon im Eingangspost geschrieben, dass ich mir mit dem ProcessMonitor angeschaut habe, welche DLL genau geladen wird. Da wird defintiv die richtige geladen und auch nur diese eine.

[venice2]

[OT]

Zitat:

Ihr seid euch nicht sicher, aber ich.

[/OT]
Ich glaube dir :-D

[Bbommel]

Hab's gefunden. Danke euch für die Unterstützung. Letztlich liegt der Fehler bei Indy. Kann man das irgendwo melden, in der Hoffnung, dass das gefixt wird? Macht das bei QC Sinn, weil ja Teil von Delphi, oder kann man sowas auch direkt ans Indy-Team melden?

Folgendes Beispielprojekt (für Interessierte auch als Paket im Anhang):

Delphi-Quellcode:

unit main;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, IdSSLOpenSSLHeaders, Vcl.StdCtrls;

type
  TForm2 = class(TForm)
    MemoStatus: TMemo;
    ButtonLoadLib: TButton;
    ButtonLoadLibOwn: TButton;
    procedure ButtonLoadLibClick(Sender: TObject);
    procedure ButtonLoadLibOwnClick(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    class var _PEM_read_bio_RSA_PUBKEY: function(bp: PBIO; x: PPRSA; cb: ppem_password_cb; u: Pointer): PRSA cdecl;
  end;

var
  Form2: TForm2;

implementation

{$R *.dfm}

procedure TForm2.ButtonLoadLibClick(Sender: TObject);
begin
  MemoStatus.Clear;
  if IdSSLOpenSSLHeaders.Load then begin
    MemoStatus.Lines.Add('OpenSSL loaded');
    MemoStatus.Lines.Add('Handle: '+GetCryptLibHandle.ToString);
    if GetCryptLibHandle <> 0 then
    begin
      _PEM_read_bio_RSA_PUBKEY := GetProcAddress(GetCryptLibHandle, 'PEM_read_bio_RSA_PUBKEY');
      if @_PEM_read_bio_RSA_PUBKEY = nil then
        MemoStatus.Lines.Add('Function not found')
      else
        MemoStatus.Lines.Add('Success! Function found!');
    end else
      MemoStatus.Lines.Add('Crypo handle invalid')
  end else
    MemoStatus.Lines.Add('Failed loading OpenSSL');
end;

procedure TForm2.ButtonLoadLibOwnClick(Sender: TObject);

var
  crypHandle: HMODULE;

begin
  MemoStatus.Clear;
  crypHandle:=SafeLoadLibrary('libeay32.dll');
  if crypHandle<>0 then begin
    MemoStatus.Lines.Add('OpenSSL loaded');
    MemoStatus.Lines.Add('Handle: '+crypHandle.ToString);
    _PEM_read_bio_RSA_PUBKEY := GetProcAddress(crypHandle, 'PEM_read_bio_RSA_PUBKEY');
    if @_PEM_read_bio_RSA_PUBKEY = nil then
      MemoStatus.Lines.Add('Function not found')
    else
      MemoStatus.Lines.Add('Success! Function found!');
  end else
    MemoStatus.Lines.Add('Failed loading OpenSSL');
end;

end.

Der erste Aufruf,

Delphi-Quellcode:

ButtonLoadLibClick

ist angelehnt an das, wie es auch in der von mir genutzten Bibliotheke JOSE.Signing.RSA gemacht werden soll. Hier läuft es auch genauso: unter 32-Bit funktioniert es super, unter 64-Bit findet er die Funktion nicht.

Der zweite Button mit dem Aufruf

Delphi-Quellcode:

ButtonLoadLibClick

kümmert sich selbst nochmal um das Laden der Bibliothek. Das Suchen der gewünschten Funktion klappt dann problemlos sowohl unter Win32 und Win64.

Und warum behaupte ich nun, das Indy "schuld" ist?

In der Unit IdSSLOpenSSLHeaders wird das Handle auf die libeay32.dll in der globalen Variable hIdCrypto gespeichert und diese ist auch vom Typ HModule. Unter Win32 wird HModule zu "Cardinal", unter Win64 aber zu UInt64. Die Variable ist aber nur im Implementation-Bereich definiert, also können wir nicht von außen auf sie zugreifen. Nach außen verfügbar macht die Unit diese Variable über die oben auch genutzte Funktion

Delphi-Quellcode:

GetCryptLibHandle

. Diese Funktion liefert aber nicht HModule zurück, sondern ein Integer. Dadurch wird in der Rückgabe also das Handle zerschossen - sieht man ganz gut, wenn man mein Testprogramm ausführt und die beiden Handles vergleicht. Dass das nicht passt, ist offensichtlich, denke ich mal.

Ich sag mal so: Aaaaaargh! :wall: ;-) Jemand eine Idee für einen Workaround, ohne dass ich die IdSSLOpenSSLHeaders patchen muss?

[venice2]

So wie ich das sehe lag es dann doch an den Datentypen.
So wie ich sagte.

Zitat:

Unter Win32 wird HModule zu "Cardinal", unter Win64 aber zu UInt64.

fein das es jetzt geht.

[Bbommel]

Nachtrag: gerade mal nachgesehen: im Indy, das mit Delphi 10.4 mitgeliefert wird, ist das Problem gefixt. Insofern werde ich mir wohl - bis ich mal auf 10.4 aktualisiere - doch eine lokale Kopie von IdSSLOpenSSLHeaders ins Projekt holen und es dort korrigieren, falls keiner eine bessere Idee hat.

@venice2: Genau, warst da auf der richtigen Spur.

[Daniel]

Alternativ einfach die aktuellen Version der Indy-Komponenten nutzen - dort ist der Typ des Rückgabewertes definiert als "TIdLibHandle", der seinerseits ein Thandle" ist, was als "NativeUInt" wiederum prächtig unter Win64 funktioniert.

//Edit - da warst Du schneller.

[venice2]

Zitat:

Zitat von Bbommel (Beitrag 1478051)

Nachtrag: gerade mal nachgesehen: im Indy, das mit Delphi 10.4 mitgeliefert wird, ist das Problem gefixt. Insofern werde ich mir wohl - bis ich mal auf 10.4 aktualisiere - doch eine lokale Kopie von IdSSLOpenSSLHeaders ins Projekt holen und es dort korrigieren, falls keiner eine bessere Idee hat.

@venice2: Genau, warst da auf der richtigen Spur.

Korrekt!
Funktioniert mit Indy unter 10.4 gerade getestet.