~ DLL Injector Source Code ~

ahh doesnt work the load dll doesnt work for me

Then I would debug the code by adding a message box to every API function (or to Err.LastDllError if the API requires GetLastError as its return status) to check its return.
When you find which on fails (and you will know it fails by looking at what each function should return via MSDN - Just google the API function and MSDN will usually be the first link) then you can take it one step further and see why, based on what kind of values are being passed in as the parameters.

If u cant understand why it is failing, then I guess post back here with the name of the API function that is failing for you, and I or someone else might propose some suggestions to try.

Lets not get off topic or stupid. If the program isn't working for you, ask him in private message. If you're creating your own, i'm sure you're only using a few APIs and if they compile (compilers still have that thing where they tell you there errors, you know), then it's probably your hack or method that's failing.

Thanks for this thing.

Ahh still aint working

What is the 1st API function that is failing?

Did you check to ensure it is declared correctly and being passed valid parameters?

If they are all returning success then it is possible that one or more of the APIs (or lower level ones they are calling) are being hooked on your system. (such as from FW, AV, or AM dlls or drivers running the the background)
To check, you could run some ARK(antirootkit) tools to ensure there are no IAT, EAT, Inline JMPs(Runtime patching), SSDT or Kernel code modifications going on. Ex of some tools to check with:
Radix
Kernel Detective
GMER
PEvert
IceSword
kX-ray

not sure i tierd googleing but nothin =(

Well you will need to check the return status of each API, and you can do that with Message boxes (Msgbox) either on the API return itself or on Err.LastDllError

There shouldn't be much googling required.
Simply take the name of the API, plug it into google, and then MSDN will usually be the first link.

Example:
VirtualAllocEx - http://www.google.com/search?q=virtualallocex
So basically if Msgbox VirtualAllocEx(...) shows 0 then obviously it is failing, and to get the error code you could then do a MsgBox on the value from Err.LastDllError.

Without seeing your code, or you describing which function is failing, it is kind of hard for us to help.

And Highlights FileName

Oh so you are getting a compile-time error.
See that is a different story.

If it is highlighting FileName for CommonDialog then that would basically be saying that "FileName" is not a member of your CommonDialog class.
So either you didn't reference the CommonDialog correctly or yours is different/modifed.
Are you sure you even have ComDLG32.ocx in your system32 folder?

Does the injection work when you just hardcode a path to a .dll or .exe instead of browsing for it using ComDlg ?
If so, then that means there is no runtime error, and your code will work fine other than having some kind of invalid common dialog.

This source was ripped from this just for your info:

Inject Library using CreateRemoteThread() by Marcin Kleczynski

bump =/

dont bump this old of a thread.