Memory Library and GetProcAddress
Memory Library and GetProcAddress
I have this source (C#) that simulates 'LoadLibrary' using Byte Arrays(no i didnt make it). What i wanted to ask you is How do i use this function in an injector?
MemoryLibrary.MemoryLoadLibrary(file)
Can GetProcAddress be used with .Net Dlls?
MemoryLibrary.MemoryLoadLibrary(file)
Can GetProcAddress be used with .Net Dlls?
Originally Posted by topblast
I have this source (C#) that simulates 'LoadLibrary' using Byte Arrays(no i didnt make it). What i wanted to ask you is How do i use this function in an injector?
MemoryLibrary.MemoryLoadLibrary(file)
Can GetProcAddress be used with .Net Dlls?
MemoryLibrary.MemoryLoadLibrary(file)
Can GetProcAddress be used with .Net Dlls?
Originally Posted by Jason
Why not just test it and see if it works? haha.
Originally Posted by topblast
the last time i tested something with getprocaddress i got return 0
GetProcAddress does work from a .net library.
wee, I am want to use it to get MemoryLibrary.MemoryLoadLibrary() which is within a .net dll
Well, idk what tehfux Memory.MemoryLoadLibrary is so /
I'm guessing it's your C# LoadLibrary approximation?
If you're injecting that .dll into a process I think you'll need a CLR loader to actually call the function, it's managed code rather than unmanaged code so GetProcAddress isn't what you need. Have a look into the Reflection namespace as well. With VirtualAllocEx on the injector you should get the pointer to the address space where the .dll was injected, and reflection of the actual .dll (not the one in the process) should get you the offset of your MemoryLoadLibrary function. Put 2 and 2 together and you should have the address of your function. However, I'm not sure why your .NET dll needs to be injected...I don't know why someone would create a manged "LoadLibrary" alternative designed to be injected into unmanaged memory...would just make it super inconvenient to use and probably unstable.
I'm guessing it's your C# LoadLibrary approximation?If you're injecting that .dll into a process I think you'll need a CLR loader to actually call the function, it's managed code rather than unmanaged code so GetProcAddress isn't what you need. Have a look into the Reflection namespace as well. With VirtualAllocEx on the injector you should get the pointer to the address space where the .dll was injected, and reflection of the actual .dll (not the one in the process) should get you the offset of your MemoryLoadLibrary function. Put 2 and 2 together and you should have the address of your function. However, I'm not sure why your .NET dll needs to be injected...I don't know why someone would create a manged "LoadLibrary" alternative designed to be injected into unmanaged memory...would just make it super inconvenient to use and probably unstable.
Originally Posted by Jason
Well, idk what tehfux Memory.MemoryLoadLibrary is so / I'm guessing it's your C# LoadLibrary approximation?
If you're injecting that .dll into a process I think you'll need a CLR loader to actually call the function, it's managed code rather than unmanaged code so GetProcAddress isn't what you need. Have a look into the Reflection namespace as well. With VirtualAllocEx on the injector you should get the pointer to the address space where the .dll was injected, and reflection of the actual .dll (not the one in the process) should get you the offset of your MemoryLoadLibrary function. Put 2 and 2 together and you should have the address of your function. However, I'm not sure why your .NET dll needs to be injected...I don't know why someone would create a manged "LoadLibrary" alternative designed to be injected into unmanaged memory...would just make it super inconvenient to use and probably unstable.
I'm guessing it's your C# LoadLibrary approximation?If you're injecting that .dll into a process I think you'll need a CLR loader to actually call the function, it's managed code rather than unmanaged code so GetProcAddress isn't what you need. Have a look into the Reflection namespace as well. With VirtualAllocEx on the injector you should get the pointer to the address space where the .dll was injected, and reflection of the actual .dll (not the one in the process) should get you the offset of your MemoryLoadLibrary function. Put 2 and 2 together and you should have the address of your function. However, I'm not sure why your .NET dll needs to be injected...I don't know why someone would create a manged "LoadLibrary" alternative designed to be injected into unmanaged memory...would just make it super inconvenient to use and probably unstable.
So its like this
Select DLL;
Read Bytes;
Save Bytes in fileBytes;
if process running
Memory.MemoryLoadLibrary(fileBytes);
Injected
Originally Posted by topblast
i am not injecting the .Net DLL, it only holds the function of where i can Inject DLL that are in Byte Arrays instead of files.
So its like this
Select DLL;
Read Bytes;
Save Bytes in fileBytes;
if process running
Memory.MemoryLoadLibrary(fileBytes);
Injected
Originally Posted by Jason
Ahhh, so you want to use GetProcAddress to find the main function address in the written bytes?
look below
[highlight=vb.net]
Private Shared Function Inject(ByVal oProcess As IntPtr, ByVal byteDLL As Byte()) As Boolean
Try
Dim bytes As IntPtr
Dim Len As Int32 = byteDLL .Length + 1
Dim AllMem As IntPtr = VirtualAllocEx(oProcess, IntPtr.Zero, CUInt(Len), &H1000, &H40)
WriteProcessMemory(oProcess, AllMem, byteDLL, Len, bytes)
Dim Injector As String = GetProcAddress(GetModuleHandle("MemoryLibrary.dll" ), "MemoryLoadLibrary")
If Injector Is Nothing Then
AddError("Injector: Error ID 001, Fail to find Fail to find [ Kernel32.dll::LoadLibraryA ]")
Return False
End If
Dim ThreadHd As String = CreateRemoteThread(oProcess, IntPtr.Zero, 0, Injector, AllMem, 0, bytes)
If ThreadHd Is Nothing Then
AddError("Injector: Error ID 101, Fail to start DLL")
Return False
End If
Dim Result As Integer = WaitForSingleObject(ThreadHd, Int32.MaxValue)
If Result = 128L OrElse Result = 258L OrElse Result = &HFFFFFFFF Then
If Result = 258L Then
AddError("Injector: Error ID 201, FAIL Waiting to Long for Object")
Else
AddError("Injector: Error ID 202, Injection fail")
End If
If ThreadHd IsNot Nothing Then
Return CloseHandle(ThreadHd)
End If
Return False
End If
Thread.Sleep(10)
VirtualFreeEx(oProcess, AllMem, 0, &H8000)
If ThreadHd IsNot Nothing Then
Return CloseHandle(ThreadHd)
End If
Return False
Catch ex As Exception
Return False
End Try
End Function
[/highlight]
Originally Posted by topblast
K i getting confused.
look below
[highlight=vb.net]
Private Shared Function Inject(ByVal oProcess As IntPtr, ByVal byteDLL As Byte()) As Boolean
Try
Dim bytes As IntPtr
Dim Len As Int32 = byteDLL .Length + 1
Dim AllMem As IntPtr = VirtualAllocEx(oProcess, IntPtr.Zero, CUInt(Len), &H1000, &H40)
WriteProcessMemory(oProcess, AllMem, byteDLL, Len, bytes)
Dim Injector As String = GetProcAddress(GetModuleHandle("MemoryLibrary.dll" ), "MemoryLoadLibrary")
If Injector Is Nothing Then
AddError("Injector: Error ID 001, Fail to find Fail to find [ Kernel32.dll::LoadLibraryA ]")
Return False
End If
Dim ThreadHd As String = CreateRemoteThread(oProcess, IntPtr.Zero, 0, Injector, AllMem, 0, bytes)
If ThreadHd Is Nothing Then
AddError("Injector: Error ID 101, Fail to start DLL")
Return False
End If
Dim Result As Integer = WaitForSingleObject(ThreadHd, Int32.MaxValue)
If Result = 128L OrElse Result = 258L OrElse Result = &HFFFFFFFF Then
If Result = 258L Then
AddError("Injector: Error ID 201, FAIL Waiting to Long for Object")
Else
AddError("Injector: Error ID 202, Injection fail")
End If
If ThreadHd IsNot Nothing Then
Return CloseHandle(ThreadHd)
End If
Return False
End If
Thread.Sleep(10)
VirtualFreeEx(oProcess, AllMem, 0, &H8000)
If ThreadHd IsNot Nothing Then
Return CloseHandle(ThreadHd)
End If
Return False
Catch ex As Exception
Return False
End Try
End Function
[/highlight]
The only reason this works is because in all "normal" processes kernel32.dll is loaded into the same address space EVERY TIME and all it's functions are loaded into the same address space every time too. This is why using GetModuleHandle and GetProcAddress return the correct handles even though you're not checking the target process.
However, YOUR .dll will not be loaded into an identical address space every time, so checking your own process for the address of MemoryLibrary.dll (if it even returns) has no guarantee the handle will even be the same as the one in the target process.
That's right bitches, Jason is no longer completely memtarded.
Originally Posted by Jason
Eugh, now I'm confused. You just said you weren't injecting your DLL but here you are checking your own process for the MemoryLibrary.dll module handle. This method won't work the same way as the regular LoadLibrary handle method; which doesn't locate the handle in another processes memory, but in the calling processes memory (AKA YOUR PROGRAM).
The only reason this works is because in all "normal" processes kernel32.dll is loaded into the same address space EVERY TIME and all it's functions are loaded into the same address space every time too. This is why using GetModuleHandle and GetProcAddress return the correct handles even though you're not checking the target process.
However, YOUR .dll will not be loaded into an identical address space every time, so checking your own process for the address of MemoryLibrary.dll (if it even returns) has no guarantee the handle will even be the same as the one in the target process.
That's right bitches, Jason is no longer completely memtarded.
addressOf(Memory.MemoryLoadLibrary)
???
Originally Posted by topblast
so how will i get it to work?
addressOf(Memory.MemoryLoadLibrary)
???
Originally Posted by Jason
Dude, you're doing it wrong in the first place. If you're injecting the bytes correctly in the first place with your "loadlibrary" function, you don't need to call a LoadLibrary function at all. You'd just need to use CreateRemoteThread to start dllMain afaik.
Originally Posted by topblast
i dont know how
That is how to manually map a dll without using LoadLibrary in C++. You can find some PEHeader structures online to add to your project to make up for the lack of having them by default in VB/C#. The direct ASM can be circumvented by finding the calling bytes of the dllMain function (props to @Hell_Demon
) and simply changing the address it calls by editing some bytes.Good luck and have fun. On a day when I have like 6 hours to spend coding and suiciding, I may try write this in .NET. Until then, enjoy yourself.
Originally Posted by topblast
i dont know how :(