DCoder's answer is a good one. To expand somewhat, I most often use DLL injection in the context of forcing an existing process to load a DLL through CreateRemoteThread. From there, the entrypoint of the DLL will be executed by the operating system once it is loaded. In the entrypoint, I will then invoke a routine that performs in-memory patching of all ...
ILSpy is a great open-source decompiler.
Support C# 5.0 "async"
Decompilation to C#
Supports lambdas and 'yield return'
Shows XML documentation
Decompilation to VB
Saving of resources
Save decompiled assembly as .csproj
Search for types/methods/properties (substring)
DLL Injection works by tricking/forcing the target process into loading a DLL of your choice. After that, the code in that DLL will get executed as part of the target process and will be able to do anything the process itself can. The fun part will be to figure out how to get your code called by the target process.
DLLs can be injected by:
Note: I am assuming 32bit x86 on Windows, your question unfortunately doesn't state for certain. But since it's Windows and you don't explicitly mention x64 this was the sanest assumption I could make.
First off, try to search for the function names with a search engine. Don't just settle for a single search engine. Failing that, inspect whatever came in ...
This looks like the output of Visual C++ linker in incremental linking mode. In this mode, the linker adds a section with incremental linking thunks (ILTs) at the start of the code section (.text), each thunk being a relative jump (E9 xx xx xx xx) to a function.
All function calls in the binary are redirected to the corresponding ILT instead of pointing ...
I've used JetBrains dotPeek (free of charge) before with some success.
Any JetBrains software I've ever used has been very solid.
It is not quite the 'original source' but it is very readable C# - about the closest thing I would expect to get. Quote from their website:
What's Cool about dotPeek?
Decompiling .NET 1.0-4.5 assemblies to C#
Check the dword at offset 0xE8 (32-bit) or 0xF8 (64-bit) in the PE header. If it's non-zero, it's the pointer to the CLR header. That's a managed file (you can't put random data there because direct .NET parsing support is built into XP and later, so the file won't load if the data aren't valid). The presence of mscoree.dll is not enough in itself, ...
Very easy, if I got you right:
Make an Ida project from the DLL, i.e. drag and drop the dll into the blank Ida page.
In Menu Debugger, Process Options, put the path to your exe into the textbox "Application", Into "input file" put the path to your DLL. Confirm with OK.
Start with menu Debugger, Start Process or F9.
Your breakpoint should be hit.
The Windows kernel, unlike Linux or OS X, does not use consistent syscall numbering across versions. The numbers can change even after a servicepack release. For example, the NtReadFile syscall was 0x0086 on Windows NT 4 but on Windows 7 it's 0x0111 (see here for the full list).
That's why all proper programs use the kernel32.dll (or ntdll.dll) to perform ...
What you're trying to do is very hard if the attacker is an experienced game hacker and the specifics of the cheat is unknown.
In general if you want to inject a DLL which is harder to detect and won't show up on the module list of the process you use something called manual mapping. What this does is that it emulates the behavior of LoadLibrary without ...
There are multiple ways that you can use which might work (and see below for the reasons why they might not). Here are two:
A process can debug itself, and then it will receive notifications of DLL loading.
A process can host a TLS callback, and then it will receive notifications of thread creation. That can intercept thread creation such as what is ...
Let me start by telling you that what you want would be impossible, because of how well-known DLLs work. You can attempt something similar with tools like PEBundle or dllpackager, but that will usually (I'd say certainly) fail with the well-known DLLs (such as system DLLs as well as even the MSVC runtime DLLs in their different incarnations). See this and ...
This seemed like a fun project for a Sunday afternoon, so I had a go at it. To get straight to the point, here's the call stack for a function in SQL server that parses and then executes the query (addresses and offsets taken from SQL Server 2008 R2 running on Windows 7 SP1 32-bit):
Both, DllMain and DllEntryPoint are merely symbolic names of the same concept. They even share the same prototype. But they aren't the same:
The function must be defined with the __stdcall calling convention.
The parameters and return value must be defined as documented in the
Win32 API for WinMain (for an .exe file) or DllEntryPoint (for a DLL).
DllEntryPoint - is the address from which the execution will start (but does not have to if we are speaking about malware) after the loader had finished the loading process of the PE image. This address is specified inside the PE optional header. Please look here. The other name for DllEntryPoint is AddressOfEntryPoint.
DllMain - is the default function ...
A managed DLL / Application will have a primary dependency on MSCOREE.dll... So, if you open the DLL in Dependency Walker you have
no problems in telling a managed library from an unmanaged one.
Quoted from here
and other usefull link : msdn ; msdn2
Checking DataDirectory[IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR].VirtualAddress in the data directory portion of the PE header for a nonzero value is probably the fastest way.
#define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14 // COM Runtime descriptor
Anatomy of a .NET Assembly – PE Headers
Recently I've been using dnSpy [forked from ILSpy by the creator(s) of de4dot] as my main tool for the decompiling and live debugging of .NET code
Main difference from ILSpy :
Uses dnLib to read assemblies (vs ILSpy's Mono.Cecil)
dnlib was created because de4dot needed a robust .NET ...
There is a free tool available called JustDecompile which does that.
Creating a Visual Studio project from an assembly in order to export lost projects or obtain multiple classes without the need to copy and paste code. At present, JustDecompile is able to export decompiled code only to C#.
Exporting code directly from the command ...
I think you have 4 options here:
Overwrite the function in assembler using OllyDbg, IDA Pro or any other tool. However, you may not have enough space.
Insert a jmp to another place where you have enough space to do this. You will likely need to find for "holes" between sections where you can put your code.
Add a new section to the PE/ELF file, mark it as ...
If the previously suggested resource editors aren't to your liking, you can find descriptions and reviews of several resource editors here: http://www.woodmann.com/collaborative/tools/index.php/Category:Resource_Editors
In case you have trouble accessing that page (as per the comments below), here is the list of resource editors as of 6/26/13:
One thing you need to keep in mind is that code in your process and the code in the target process reside in different address spaces. So any address in your program is not necessary valid in the target process and vice versa.
This means the code that you inject cannot make any assumptions about addresses of functions or variables. Even your inject function'...
Would this driver exist in user space, or in kernel space?
Is it even possible for a non kernel mode driver to exist?
You can write a user-mode driver using the User-Mode Driver Framework, but that type of driver is effectively a user-mode service with access to some extra I/O functionality.
What we typically think of as a "driver" is a ...
If they were all to external targets then it would be the stubs for external functions when dynamically loading dlls.
This way you can limit the amount of pages that need updating when a new dll get loaded. Which lets the calling code be position independent with regards to the call target. Calls to external function are sent to that page and forwarded to ...
A dynamically linked library has the same executable header and structure as a standard executable. Therefore they can be debugged the same way that a normal executable can be debugged. It might be a bit tricker than usual, because in order to debug it, it has to be loaded into some process, and making that happen could be trivial (i.e. if it's loaded as ...
The implementation of AppInit DLL in windows 7 is as follows:
In user32.dll!ClientThreadSetup the LoadAppInitDlls export from kernel32.dll is being called for any process except the LogonProcess.
kernel32.dll!LoadAppInitDlls checks the LoadAppInit_DLLs registry key and if set calls BasepLoadAppInitDlls (except when offset 3 of the PEB has value 2).
Basically, all DLLs listed in that reg-key are loaded when any process is started.
For more info see Working with the AppInit_DLLs registry value.
All the DLLs that are specified in this value are loaded by each Microsoft Windows-based application that is running in the current log on session.
They are usually used by malicious code (tho it doesn't have ...
The surprising part for me is objdump can recognize anything in a PE file. According to Wikipedia,
.. PE is a modified version of the Unix COFF file format. PE/COFF is an alternative term in Windows development.
so apparently there is just enough overlap in the headers to make it work (at least partially). The basic design of one is clearly based on the ...
Question 1: What is causing these bytes to change?
These appear to be standard relocation fixups applied based on the DLL's Relocation Table.
Sub-question 1.1: Is is some sort of protection mechanism?
Sub-question 1.2: Was it recently introduced?
Sub-question 1.3: Can it be disabled?
Not easily, no.
Question 2: What do these changing ...