Hi, I want to make dll in VC++ , which when loaded into a process modifies certain address in the process

memory.

 

int nLength = GetModuleFileNameA(NULL, pszBuffer, MAX_PATH);

HMODULE hEXEParent = GetModuleHandleA(pszBuffer);

.

 

.

memcpy (&hEXEParent + 0x148521 , lplocate, 4);

 

lplocate is LPVOID adress of newly allocated memory space which I want to write.

The problem is that memcpy actually never gets linked into dll although there is no error 

during compilation.   I bet there is something wrong with memcpy parameters in my case.

Some compilers will compile memcpy as a mov (or variant of, movs, etc) instruction so there'd be nothing to link. behaviour is identical to memcpy.

 

If u really want to see something linked, use CopyMemory() which is winapi wrapper around memcpy. I doubt that's ur problem though.

 

u say "lplocate is LPVOID adress of newly allocated memory space which I want to write" but u r copying from lplocate and lplocate will not be written to.

 

this "&hEXEParent + 0x148521" looks suspicious too and is probably not doing whatever u intend.

wrong:

&hEXEParent + 0x148521

 

correct:

hEXEParent + 0x148521

 

and you need to check twice 0x148521 is a correct relative virtual adress (not a file offset)

Edited September 16, 20159 yr by ant_man

Some compilers will compile memcpy as a mov (or variant of, movs, etc) instruction so there'd be nothing to link. behaviour is identical to memcpy.

 

Nope, no reps , movs or anything

 

If u really want to see something linked, use CopyMemory() which is winapi wrapper around memcpy. I doubt that's ur problem though.

 

Actually I tried to add both CopyMemory and memcpy at once,  and also separately, neither of them is in compiled dll.

 

u say "lplocate is LPVOID adress of newly allocated memory space which I want to write" but u r copying from lplocate and lplocate will not be written to.

 

I want to copy address of lplocate to hEXEParent + 0x148521

 

wrong:

&hEXEParent + 0x148521

 

you are right, it should to look like this so far:

memcpy (hEXEParent + 0x148521 , &lplocate, 4);

What I've noticed that when I build debug version memcpy is present, but another problem occurs for some unknown reason to me hEXEParent is increased by 0x521484 which is (4*0x148521). 

 

So 2 questions remains, why in release version is memcpy omitted, and why 0x148521 is multiplied by 4. 

Edited September 16, 20159 yr by JustAGuy

why in release version is memcpy omitted

What do you mean by that? This statement makes no sense. Can you provide disassembled code or compiled DLL to explain this?

why 0x148521 is multiplied by 4. 

Read what ant_man wrote. And then read http://stackoverflow.com/questions/5610298/why-does-int-pointer-increment-by-4-rather-than-1

Debug Build: 

Edited November 1, 20159 yr by JustAGuy

In your release build memcpy is optimized into this:

65E7113B    FF15 0420E765   CALL DWORD PTR DS:[<&KERNEL32.GetModuleHandleA>]65E71155    8BF8            MOV EDI,EAX   <-- handle of main module...65E71141    8B1D 0820E765   MOV EBX,DWORD PTR DS:[<&KERNEL32.VirtualAlloc>]65E71157    FFD3            CALL EBX65E71159    8BF0            MOV ESI,EAX   <-- address of allocated memory...65E7117F    89B7 A000CE00   MOV DWORD PTR DS:[EDI+0CE00A0],ESI   <-- memcpy replaced with a simple mov.

There is no point in caling memcpy for 4 bytes. Mov would do the same which is much faster

... and why 0x148521 is multiplied by 4. 

 

because of pointer arithmetics rules

 

http://www.cplusplus.com/doc/tutorial/pointers/#arithmetics

you're right guys, I did not notice simple mov, especially when debug build uses memcpy , it works fine know 

you're right guys, I did not notice simple mov, especially when debug build uses memcpy , it works fine know 

Visual Studio optimizes release builds with the default configuration setup. Debug builds are typically never built with any optimization on at all so you will get a near exact copy of what you are doing in code into the compiled ASM. With release mode though, you will see a number of optimizations happen, all of which are controllable if you go into the project properties and alter them.

With memcpy, there are several things that will be optimized automatically such as:

- memcpy of 1 bytes will optimize to a mov byte ptr

- memcpy of 2 bytes will optimize to a mov word ptr.

- memcpy of 4 bytes will optimize to a mov.

- memcpy of 8 bytes will optimize to a mov qword ptr.

And so on. If you are memcpy'ing a string that is of a known type, VS will often times optimize this to a rep movsb or similar.