Hallo Leute,

nachdem das Thema hier
http://www.delphipraxis.net/internal...ct.php?t=98241

ja schon im Falschen Forum ansatzweise diskutiert wurde, dachte ich mir ich suche einfach mal den von FlorianBernd angesprochenen Code aus dem Web und
poste ihn hier mal.
Er soll es laut Autor ermöglichen an den Hooks der Firewall vorbei Code in fremde Apps zu schleusen.

Was mich interessieren würde:
a) funktioniert das heute noch, bzw. gibt es Abhilfe? oder ist das
b) wieder ein Windows-"Feature" wogegen man nichts tun kann
c) ist sowas unter Linux bzw. anderen OS auchso leicht möglich?

zusammenfalten · markieren

Delphi-Quellcode:

{
  FWB# by Aphex
  [url]http://www.iamaphex.net[/url]
  [email]aphex@iamaphex.net[/email]

  Well this is to remind everyone that just because you have a firewall doesn't
  mean you are safe.

  First there was FWB, DLL injection into a trusted application. Then the
  firewall companies fought back by checking and blocking DLLs. Then we fought
  back with FWB++, injection without a DLL. Now the firewall companies have
  answered back by blocking CreateRemoteThread and all our little tricks. :(

  Or so they thought...

  These firewall companies thought they would be smart and hook every API
  we needed so we couldn't use FWB methods. Well that would have worked
  if I hadn't come up with a neat yet simple idea of locating the real API.

  The method most API hooks use is code overwriting. By far the most common
  method is extended overwriting. This allows a hook to call the original API
  from the hooked function. This is very useful because often you want to
  modify the API behaviour and not completely replace it.

  This means that even though some application has hooked an API, the real
  function is out there somewhere. All we have to do is find it. Now, normally
  this wouldn't be a simple task and obviously this is what firewall companies
  are hoping for. But if you know something about API hooks and have a nice
  LDE you can find it pretty easily.

  To hook an API with extended overwriting the API has the first 5 bytes of
  its code overwritten with a jmp. Now everytime this API is called, the jmp
  forces the hook code to take control. To be able to call the original API
  these first 5 bytes must be saved somewhere, and they must be linked back
  to the rest of the function using another jmp.

  So to call the original API all we have to do is find out where the first 5
  bytes are stored and then use that as our API address!

  I have tested the following code with the latest version of Tiny Software
  which, I'm sad to say because I really liked it, is now worthless. I let this
  code run with default security permissions and I didn't receive a single
  warning. The DLL simply injected as if it wasn't even running. :P

  Other firewalls may hook different API, for example hooking NtOpenProcess but
  they are still all exploitable. Maybe firewall companies will realize now
  that API hooking is not a very good security measure...
}

program Project1;

Programm aus Sicherheitsgründen entfernt. Anfragen bitte per PM.

Nun, ob es geht, kannst Du ja selbst feststellen. Du hast den Code, Delphi und Windows.

Und wenn es geht, bringt es eigentlich auch keine neuen Erkenntnisse. Die Aussage, dass man mit einer Firewall nicht per se sicher ist, hatte auch vorher schon Gültigkeit. Bzw. dass die Anwender, die sagten "Ha ha - ich Hab' 'ne Firewall. Mir kann nüschd passieren." falsch liegen, dass wusste man eigentlich auch schon vorher.

Ich hätte den Code gerne, nun habe ich aber nicht verstanden wem ich eine PN schicken soll. Der Autor dieses Beitrages ist nicht mehr im Forum angemeldet.

EDIT:
Ziehe meine Anfrage zurück: Kurze GOogle suche nach dem Autor hat mich zum Code geführt.

Suche auch mal im Forum nach GetRealProcAddress (was ja in dem Programm verwendet wurde) und dessen Diskussion!

BTW: Diese Art der DLL injection ist nun auch schon länger überholt.