ResourceDLL aus Speicher laden und direkt verwenden

[Lyan]

Hallo,

Ich habe eine .RES-file, in welcher ein Bild ist.
Diese .RES-File lade ich in einer DLL. Also ich habe eine DLL, die NUR aus dieser Resource besteht.

Aus dieser DLL habe ich nun wieder eine .RES-Datei erstellt. Diese .RES-Datei möchte ich in den Speicher laden (hat funktioniert) und anschließend das Bild als String einlesen.

Jemand eine Idee?

[DeddyH]

Du hast eine Ressourcen-DLL nochmals als Ressource eingebunden? Soll das nur zum Üben sein, oder welchen Mehrwert versprichst Du Dir gegenüber einer "normalen" Ressource? Ansonsten sollte das doch über LoadFromResourceName zu machen sein, sofern Du an das Instanzenhandle der DLL herankommst, wenn ich nicht irre.

[Lyan]

Zitat:

Zitat von DeddyH (Beitrag 1185275)

Du hast eine Ressourcen-DLL nochmals als Ressource eingebunden? Soll das nur zum Üben sein, oder welchen Mehrwert versprichst Du Dir gegenüber einer "normalen" Ressource? Ansonsten sollte das doch über LoadFromResourceName zu machen sein, sofern Du an das Instanzenhandle der DLL herankommst, wenn ich nicht irre.

Das hat den Sinn, dass ich diese DLL nun direkt aus dem Speicher laden kann.
Ich nehm sie mir aus der Resource, lade sie in den Speicher und rufe ihre funktionen auf.
So muss ich die DLL nicht auf dem Datei-System droppen :)

Die Lösung ist ja klar, nur weiß ich nicht wie ichs in der Praxis umsetze:

Delphi-Quellcode:

library adpResources;

{$R ress.RES}

function FileToStr(sPath:string; var sFile:string):Boolean;
var
hFile: THandle;
dSize: DWORD;
dRead: DWORD;
begin
  Result := FALSE;
  hFile := CreateFile(PChar(sPath), GENERIC_READ, FILE_SHARE_READ, nil, OPEN_EXISTING, 0, 0);
  if hFile <> 0 then
  begin
    dSize := GetFileSize(hFile, nil);
    if dSize <> 0 then
    begin
      SetFilePointer(hFile, 0, nil, FILE_BEGIN);
      SetLength(sFile, dSize);
      if ReadFile(hFile, sFile[1], dSize, dRead, nil) then
        Result := TRUE;
      CloseHandle(hFile);
    end;
  end;
end;

<Ab jetzt Pseudo-Code>

function Exporter(Resource : Resourcename) : String; stdcall;
begin

  FileToStr(Resourcename,result);
 
end; 

  exports Exporter index 1;

begin

end.

Ich suche nach einer möglichkeit IN meiner Resourcen-DLL auf die resource zuzugreifen^^


EDIT:// Und dass ich resourcen in eine dll einbinde und diese dll dann wieder in eine resource packe hat alles sinn ;)

[DeddyH]

Also ist das doch keine reine Ressourcen-DLL. Allerdings verstehe ich Deinen Code in diesem Zusammenhang nicht, ich denke, Du willst das Bild aus der Ressource der DLL laden und keine Datei?

[Lyan]

Ich habe eine DLL-Datei, in welcher sich ein Bild als Resource befindet.
Diese DLL habe ich wieder in eine Resource gepackt.

In meinem Programm lade ich die DLL aus der Resource direkt in den Speicher. Nun könnte ich ohne die DLL zu droppen, auf die export-Funktionen zugreifen.

Im obigen Beispiel die Funktion "Exporter" die mir einen String zurückgibt.

Diese Funktion "Exporter" soll das Bild, was sich ja als Resource in der DLL selber befindet als String einlesen und mir dann zurückgeben :)

[DeddyH]

Dann versuch es doch einmal mit LoadFromResourceName, um das Bild zu laden, und packe es dann in einen TStringStream. Allerdings könnte es je nach Delphi-Version zu Problemen kommen, wenn Du nicht entweder Sharemem einbindest oder auf PChar ausweichst. Und was passiert, wenn ein Byte des Bildes 0 (Stringendezeichen) ist?

[Lyan]

Zitat:

Zitat von DeddyH (Beitrag 1185284)

Und was passiert, wenn ein Byte des Bildes 0 (Stringendezeichen) ist?

Das Bild wurde vorher Base-64 kodiert.

[DeddyH]

Na dann probier es mal aus. Allerdings bin ich gerade nicht sicher, ob bei einer DLL nun hInstance oder GetModuleHandle der richtige Parameter für LoadFromResourceName ist.

[Zacherl]

Zitat:

Zitat von DeddyH (Beitrag 1185286)

Na dann probier es mal aus. Allerdings bin ich gerade nicht sicher, ob bei einer DLL nun hInstance oder GetModuleHandle der richtige Parameter für LoadFromResourceName ist.

hInstance entspricht immer der eigenen ImageBase. Wenn du LoadFromResourceName also aus der DLL selbst aufrufst, ist hInstance die richtige Wahl. Allerdings könnte es Probleme geben, da der Threadersteller die DLL ja anscheinend mit irgendeinem manual mapping Code in den Speicher läd. Weiß nicht, wie sich die Win API da im Bezug auf Resourcen verhält.

[DeddyH]

Ich weiß es auch nicht, deshalb sag ich ja: ausprobieren.

[Luckie]

Und warum der Umweg über die DLL? Pack die Ressource doch direkt in die Exe-Datei. Das macht vieles einfacher.

[Lyan]

Zitat:

Zitat von Lyan (Beitrag 1185280)

EDIT:// Und dass ich resourcen in eine dll einbinde und diese dll dann wieder in eine resource packe hat alles sinn ;)

...

[Furtbichler]

Welchen? Du wärst nämlich so mit der Erste.

[himitsu]

Den Sinn gibt es wo anders, z.B. wenn Funktionen (meist Hooks) in DLLs packen (weils ja nicht anders geht, wie viele glauben) muß und nicht will, daß jemand Anderes diese (bösen) DLLs sieht, bevor man sie überall in fremde Prozesse injiziert.

Das hier geht eher darauf hinaus, daß mein eine Datei in eine Zip steckt, welche wiederum in einer Zip liegt. :roll:

[Lyan]

Nein, um ehrlich zu sein hab ich das nur gemacht um meinen code, der merkwürdigerweise von ein paar antivirenprog. als malware anerkannt wird (Gen., Dropper whatever) zu verschleiern. (hat auch geklappt).

Ich schätze die Bitdefender, kaspersky etc. haben Alarm geschlagen, weil ich vorher in der Resource ja einen sehr sehr langen String hatte (RC4 kodiert), diesen dann aus der Resource lud, dekodiert habe und dann via RunPE in dem speicher executed hab..

Sollte ein, bzw. ist nun ein Runtime-Packer.

EDIT://

Nun tarne ich diesen String als .jpg z.B., dieses JPG befindet sich in einer Resourcen DLL. Diese DLL hat eine Funktion in den exports, die mir das Bild als String zurückgibt. Diese DLL ist wieder als Resource in der EXE. Die lade ich dann direkt in den Speicher, greife auf die exportierte Funktion zu und lade dann via RunPE.

[himitsu]

Tarnen/Verstecken macht verdächtig.

Rate mal was passiert, wenn du behauptest diese Resource sei ein Bild und die AV-Hersteller kommen irgendwann mal auf die Idee und schauen ob das wirklich ein Bild ist.
Da es kein Bild ist, würden sie dann ganz schnell wieder vor deinem Programm warnen.

Mach es wie alle anderen auch.
Wende dich an die AV-Hersteller und sag denen, das es in deinem Programm (als Anhang mitgeschickt) einen False-Positive gibt.
Dann beheben die den Fehler und man hat selber keinerlei Probleme mehr.

[p80286]

Zitat:

Zitat von Lyan (Beitrag 1185882)

Nun tarne ich diesen String als .jpg z.B., dieses JPG befindet sich in einer Resourcen DLL. Diese DLL hat eine Funktion in den exports, die mir das Bild als String zurückgibt. Diese DLL ist wieder als Resource in der EXE. Die lade ich dann direkt in den Speicher, greife auf die exportierte Funktion zu und lade dann via RunPE.

Hmmmm,
überspitzt gesagt erinnert mich das an die Zeiten, als ich mich noch von Edith Blyton inspirieren ließ. Da galt das Motto, je mehr und je größer die Vorhängeschlösser sind, desto sicherer.
Daß die Rückwand des Schuppens praktisch nicht vorhanden war, tat in dem Zusammenhang nichts zur Sache.
Aber vielleicht irre ich mich ja auch....

Gruß
K-H