a more advanced technique

Okay, this may sound like a more advanced technique (if it isn't, then I guess I'm really still a newbie. ;)). But I'm trying to copy a function from one program to another, not an address or anything, the whole function, assembly and all.

I am getting the function's base address with &MyFunction, but does this really work?
I tried to get the size by subtracting that from the address of a variable I placed directly after it, but I quickly realized that doesn't work. When I place another right before the function I see that the functions and variables aren't even stored in the same location in memory.

So... How do I get the starting point in memory of the function? And how do I get the function size?

implementation-specific.

I want to execute a function in one program in another, after the original function's program has ended.

Oh. Well just use a lib then and system or something.

Quote:

---

Originally Posted by Yarin

I want to execute a function in one program in another, after the original function's program has ended.

---

Export that function to a library, either static or dynamic, and have both programs link with it.

No, the whole idea of this, is that once the function is done executing, there are no traces left that it ever existed.

I'm using VirtualAllocEx and WriteProcessMemory, and using CreateRemoteThread to execute the new function I've copied over.
But when I do that, the computer instantly crashes. I'm guessing this is because the data that I copied over is not the right size or isn't the function at all. How do I accomplish this?

What is the purpose of doing this?

Self delete without possible restoration of the deleting agent(s).

Quote:

---

Originally Posted by Yarin

No, the whole idea of this, is that once the function is done executing, there are no traces left that it ever existed.

---

Doesn't that make it trivially impossible, since to execute the same function there must necessarily be a trace left to execute?

Yes and no... Look, I have an idea on how to cover my footstep covering footsteps; to the point that it becomes innoteworthy dirt.

The thing is, I need to know how to do this.

Seems like it would be a problem better suited for assembly language.

Why do you want to do this? It sounds like a virus or a misguided attempt at an uninstall program.

If you just wanna export functions from other files, just create a DLL and include it in your code with LoadLibrary.
Then, get the function's address by using GetProcAddress.
Something like this..
dll.dll:

Code:

---

__cdecl(dllexport) void func()
{
 cout << "Hello world!";
}

---

includedll.cpp:

Code:

---

typedef void (*myFunc)();
myFunc func;
HANDLE dll = LoadLibrary("dll.dll");
func = (myFunc)GetProcAddress((HMODULE)dll, "func");
func();
FreeLibrary((HMODULE)dll);

---

As to why your "copy the function and execute" wont work, I suspect the problem is that the code isn't completely free of relocations (references to absolute memory locations, for example variables, constant data, vtables for C++ objects or jump tables for switch statements). You could check this by looking at the code in the executable file itself, and compare that with the code in memory - if it has changed, then you have relocations.

You may also find that if your application itself doesn't load a DLL that is needed by the code you are calling, you may have a relocation in the code referencing the DLL, and it will most likely point to invalid memory, which would lead to a crash.

--
Mats

Quote:

---

Originally Posted by Yarin

Yes and no... Look, I have an idea on how to cover my footstep covering footsteps; to the point that it becomes innoteworthy dirt.

The thing is, I need to know how to do this.

---

OK, I'm curious too. What are you trying to do?

This, I believe?
http://cboard.cprogramming.com/showthread.php?t=105728

Quote:

---

Originally Posted by matsp

As to why your "copy the function and execute" wont work, I suspect the problem is that the code isn't completely free of relocations (references to absolute memory locations, for example variables, constant data, vtables for C++ objects or jump tables for switch statements). You could check this by looking at the code in the executable file itself, and compare that with the code in memory - if it has changed, then you have relocations.

You may also find that if your application itself doesn't load a DLL that is needed by the code you are calling, you may have a relocation in the code referencing the DLL, and it will most likely point to invalid memory, which would lead to a crash.

---

I've thought about that, and I don't believe it'll be a problem. I've made sure that the function has no outside references. All the DLL imports are done dynamically, and other than those function calls, all I do are simple operations with variables that don't even require a header to compile. And apparently kernel32 is in the same address space of all programs, so I think I'm in good shape.

Quote:

---

Originally Posted by Elysia

This, I believe?
http://cboard.cprogramming.com/showthread.php?t=105728

---

Right... I've already said what I want to do.

>> Seems like it would be a problem better suited for assembly language.
Hmm, what would asm to that c/c++ can't in this situation?

>> Why do you want to do this? It sounds like a virus or a misguided attempt at an uninstall program.
I'm making a security program, that's suppose to zero-out and delete the specified data, including the program itself. By doing this type of injection, there shouldn't be any physical remnants left.

Quote:

---

Originally Posted by Yarin

I'm making a security program, that's suppose to zero-out and delete the specified data, including the program itself. By doing this type of injection, there shouldn't be any physical remnants left.

---

Why does a security program have to delete itself? Makes it kind of hard to provide security when it's no longer around, doesn't it?

It's not the keep-viruses-off kind of security. Let's just say it's just suppose to prepare the computer for unwanted visitors.
You're getting a little too nosy here.

Hey now, it's not like Yarin is writing a virus. Yarin has been a member for some time now, so I think it is someone whom we can trust.

Quote:

---

Originally Posted by Yarin

I've thought about that, and I don't believe it'll be a problem. I've made sure that the function has no outside references. All the DLL imports are done dynamically, and other than those function calls, all I do are simple operations with variables that don't even require a header to compile. And apparently kernel32 is in the same address space of all programs, so I think I'm in good shape.

---

And no globals, right?

--
Mats

Quote:

---

Originally Posted by Yarin

>> Seems like it would be a problem better suited for assembly language.
Hmm, what would asm to that c/c++ can't in this situation?

---

With asm, you can have control over how long the code is and what representation it has. I think. So then you could find out the length of the machine code more easily. For instance, who says the compiler won't optimize the function away completely?

Sorry if you think my questions are intrusive, but it just seems an odd thing to want to do.

>> It's not the keep-viruses-off kind of security. Let's just say it's just suppose to prepare the computer for unwanted visitors.

At any rate, this sort of discussion goes against forum rules. ;)

Is it really?

Quote:

---

6. Messages relating to cracking, (erroneously called "hacking" by many), copyright violations, or other illegal activities will be deleted. Due to the overlapping boundaries of code with malicious intent, and other legitimate uses of it, the moderators will assess each potential infraction on a case by case basis.

---

It's not cracking, hacking, copyright violation or copyright violation, as I see.
And further, the rules do state that moderators assesses each case and decides if it's malicious intent or not, and from what I can see, it is not. And I would trust Yarin's word.

You can do this in assembly, but C doesn't give you enough control to isolate a function like that.

I'm still confused what you are trying to do. Maybe this can be solved with a script of some sort? A script can generate another script that can delete the source of the first, easily enough, and that can be passed to the interpretor or shell so that the original source is not needed.

>> It's not cracking, hacking, copyright violation or copyright violation, as I see.

I think that overwriting the memory of another process and then 'disappearing without a trace' most certainly falls within that category. Could it have legitimate uses? Of couse. But the point is, it is a form of cracking.

Quote:

---

Originally Posted by Yarin

Okay, this may sound like a more advanced technique (if it isn't, then I guess I'm really still a newbie. ;)). But I'm trying to copy a function from one program to another, not an address or anything, the whole function, assembly and all.

I am getting the function's base address with &MyFunction, but does this really work?
I tried to get the size by subtracting that from the address of a variable I placed directly after it, but I quickly realized that doesn't work. When I place another right before the function I see that the functions and variables aren't even stored in the same location in memory.

So... How do I get the starting point in memory of the function? And how do I get the function size?

---

I gather you are doing this for Windows, so I'm not much help to you there with the specifics. But, just a nit-pick, you aren't copying assembly. You will be copying op-codes. Just sayin' ;)

I have had to do something similar for writing data to and from flash memory a long time ago. The same flash memory that the program itself was in, so I had to copy the function I needed out of the flash and into RAM, then set the program counter to it, and then start the erase and write cycle. So, there are plenty of legitimate reasons for doing this.

It has been a long, long time since I have done anything close to this level of programming for Windows, and then not even that much. But, the size of the function can often be obtained from the linker map file. Are you generating the listing files when you compile? That's how I had to do it for my memory copier IIRC. It was manual, there was no way to reliably calculate the size of the function I needed for my buffer at compile time (there was no memory allocator, I only had 2k of RAM anyway). So I just made an array using the size that I was given by the linker map for the function. Of course, putting that function by itself in it's own module, and then ensuring that you aren't calling any other functions in it made my task far simpler.

Are you calling any other functions? That would be a problem! I do believe that a function pointer on Windows will give you the address in memory that you need, and I also believe it is the same size as a pointer to char IIRC. You'll have to confirm that on your own though. Perhaps you aren't respecting the right calling conventions when you set up your "call buffer" and that is why it is crashing. If you get the size right, and it is still crashing, that is what I would suspect first.

Does Windows secure memory pages so that some are for data only, while others are executable? I have no idea, but that's another question. That would be a real BIG problem, and probably a show-stopper right there.

Good Luck! :)

Quote:

---

Originally Posted by whoie

...I do believe that a function pointer on Windows will give you the address in memory that you need, and I also believe it is the same size as a pointer to char IIRC. You'll have to confirm that on your own though.

---

Of course it does. This is basic C++. An address is stored in a pointer and the size of a pointer is always the same, no matter what it points to.

Quote:

---

Does Windows secure memory pages so that some are for data only, while others are executable? I have no idea, but that's another question. That would be a real BIG problem, and probably a show-stopper right there.

---

Yes, well at least, kind of.
Windows has page protection. Read, write, execute and stuff.
You can modify those with calls to Virtual Memory functions. To execute code, the execute flag must be set or you'd get a crash.

Quote:

---

Originally Posted by Elysia

Of course it does. This is basic C++. An address is stored in a pointer and the size of a pointer is always the same, no matter what it points to.

---

You're probably right for the PC architecture, but that's not universally true. From what I recall, char* and void* are the same size, and function pointers are all the same size as each other, but that's it. Perhaps things are different in C++, but in C (which is where C++ gets its memory model) that's all you are guaranteed IIRC.

So converting a function pointer to a char* and back isn't guaranteed to work. Sometimes code space is addressed differently than data space. In fact, char* and void* are often the largest data pointers, while others are smaller. I've worked on architectures with 32-bit char* and 16-bit for all other data pointers. Function pointers were also 16-bit on that architecture. That's because the number of bits in a char was 16, not 8, but the address spaces for code and data were limited to 64K. So 16-bit worked fine, but the compiler folks wanted to hold programmer's hands who weren't comfortable with a world where char's weren't 8 bits. So they doubled the size of the char* so that the first 16-bits was the actual address, and the second 16-bits indicated the first or second octet. It saved space for strings and such, and made the world "seem right", but it was more of a pain than a help IMO.

Quote:

---

Originally Posted by Elysia

Windows has page protection. Read, write, execute and stuff.
You can modify those with calls to Virtual Memory functions. To execute code, the execute flag must be set or you'd get a crash.

---

Bingo! :) I suspected as much.

Quote:

---

Originally Posted by whoie

You're probably right for the PC architecture, but that's not universally true. From what I recall, char* and void* are the same size, and function pointers are all the same size as each other, but that's it. Perhaps things are different in C++, but in C (which is where C++ gets its memory model) that's all you are guaranteed IIRC.

---

Hmmm. I haven't worked on other architectures, so I may suspect you are correct.
I don't know what the standard says, so you're probably more right than I am :)

Quote:

---

I don't know what the standard says

---

Standard says you can convert any pointer to void* and back without loosing data.
No garantees for over pointer conversions

Nothing about the size?

Quote:

---

Originally Posted by Elysia

Nothing about the size?

---

The size of a pointer is not defined by the standard. Standard C or C++, on just x86 architectures, can have 16, 32, 64 or 48 bit pointers, for example. 16-bit pointers are used in small real-mode, where the entire application can fit in 64KB. 32-bit pointers are used in "large" real-mode and 32-bit flat model. 64-bit pointers are obviously in X86-64 mode. 48-bit pointers would be if you use segmented mode with 32-bit pointers, and there are compilers that use that mode, although I do admit that you will be looking into the smaller markets of specialized embedded compilers, and not gcc or MS based compilers.

In other architectures, we also have pointer systems where a pointer has to be aligned to 32 bits, and bytes are fetched via a supplementary value of "byte within word". So a pointer to int or function would hold only the 32-bit aligned pointer, where a char * would have a "byte-within-word" value stored along with the pointer. These aren't common machined, but I do believe that some older IBM machines are using this method.

--
Mats

I get they may differ in size, but the question is: is all pointers guaranteed to be the same size on the same system?
Ie sizeof(void*) == sizeof(int*)
Or can they be different sizes, even on the same system?

Quote:

---

Originally Posted by vart

Standard says you can convert any pointer to void* and back without loosing data.
No garantees for over pointer conversions

---

Read that again carefully, I think you might see that it says something like "object pointers" or "pointer to type T."

You'll get a compiler diagnostic if you try to convert a function pointer to a void*.

For function pointers, I'm 99.999% sure that you can convert any function pointer to any other function pointer and back without loss. That's not guaranteed to be true for function pointer to void* and back. Sometimes function pointers can be quite a bit larger than void*. Particularly on Harvard-type architectures which, besides the size issue, use entirely different buses for data and code.

Quote:

---

Originally Posted by Elysia

I get they may differ in size, but the question is: is all pointers guaranteed to be the same size on the same system?
Ie sizeof(void*) == sizeof(int*)
Or can they be different sizes, even on the same system?

---

I know for a fact that they are not guaranteed to be the same size in C, and they aren't always in reality either. I just don't know for sure about C++, but I would be surprised if the same weren't true.

Quote:

---

Originally Posted by whoie

Read that again carefully, I think you might see that it says something like "object pointers" or "pointer to type T."

You'll get a compiler diagnostic if you try to convert a function pointer to a void*.

For function pointers, I'm 99.999% sure that you can convert any function pointer to any other function pointer and back without loss. That's not guaranteed to be true for function pointer to void* and back. Sometimes function pointers can be quite a bit larger than void*. Particularly on Harvard-type architectures which, besides the size issue, use entirely different buses for data and code.

---

Also, function pointers to virtual functions aren't guaranteed to be like "normal" function pointers.

--
Mats

Quote:

---

Originally Posted by Sebastiani

>> It's not cracking, hacking, copyright violation or copyright violation, as I see.

I think that overwriting the memory of another process and then 'disappearing without a trace' most certainly falls within that category. Could it have legitimate uses? Of couse. But the point is, it is a form of cracking.

---

Why couldnt we talk about cracking here? I woud love to learn about that stuff too.

Because it's often used in illegal stuff. Although there are legal uses, that's why the moderators decide on a case-by-case basis.

Just got done reading this thread. Rule #6 does apply due to this:

Quote:

---

Originally Posted by Yarin

Yes and no... Look, I have an idea on how to cover my footstep covering footsteps; to the point that it becomes innoteworthy dirt.

---

Quote:

---

Originally Posted by Yarin

It's not the keep-viruses-off kind of security. Let's just say it's just suppose to prepare the computer for unwanted visitors.
You're getting a little too nosy here.

---

IMO this shows ill intent and a desire to do harm to another computer system. You can claim it is for self defense but that is a old arguement in world history that rarely holds true for very long.

Yarin is also on thinner ground due to his previous history here at cboard.


If this thread stays on the current course of pointer sizes then it'll remain open, but if it reverts to the previous topic it will be closed.

>> IMO this shows ill intent and a desire to do harm to another computer system.
The program is a Zeroing-Out program, to delete sensitive data.
How do you come to the conclusion that I'm trying to hurt someone else's system? Sure, this method may be used in bad software, but if that's reason enough to paste a crook sticker on me, then we might as well stop using exes all together, after all, most viruses are exes.

>> Yarin is also on thinner ground due to his previous history here at cboard.
How? I've never been involved in any illegal stuff before. Only a personal opinion disagreement catastrophe.

Quote:

---

Let's just say it's just suppose to prepare the computer for unwanted visitors.

---

Can mean and be interpreted many different ways. Due to your history I choose to interprete it on the more conservative side.

Quote:

---

How? I've never been involved in any illegal stuff before. Only a personal opinion disagreement catastrophe.

---

Do you really want me to go into this in public Queatrix?

>> Do you really want me to go into this in public Queatrix?
Queatrix is an old handle, I prefer by my new one. Even so, please PM me anything you have to show that I was ever involved in viruses or anything related.

EDIT:
Better yet, go ahead and post it.

Quote:

---

Originally Posted by Yarin

>> IMO this shows ill intent and a desire to do harm to another computer system.
The program is a Zeroing-Out program, to delete sensitive data.
How do you come to the conclusion that I'm trying to hurt someone else's system?

---

Perhaps is the need to "cover your tracks". Why is that necessary, or is that too nosy again?

You can harm another system without using a virus. I didn't actually mention virus, you did.

Now from your behavior as Queatrix and the fact that you technically in violation of Rule 14 you don't get as much benefit of the doubt as other people.

And when I see

Quote:

---

You're getting a little too nosy here.

---

I immediately get suspicious.

If you disagree you are more then welcome to ask another mod to look it over and give their opinion. If you notice I haven't closed this thread, just warned against the orginal topic matter.

Quote:

---

Originally Posted by Elysia

Hey now, it's not like Yarin is writing a virus. Yarin has been a member for some time now, so I think it is someone whom we can trust.

---

You seriously award trust to people proportionate to how long you've tolerated them?

I'll let you know when I need blood. :cool:

I give benefit of doubt to people who have been around long and know the rules and haven't posted a lot of things that got locked/deleted from what I've seen.
It's that simple.

I still think its strange to prohibit talking about cracking/hacking etc. If somebody really wants to learn that he wont be put off by some forum rules and knowing the "dark side" of coding does help to make you a better programmer even when you dont write viruses yourself.

Quote:

---

Originally Posted by KIBO

I still think its strange to prohibit talking about cracking/hacking etc. If somebody really wants to learn that he wont be put off by some forum rules and knowing the "dark side" of coding does help to make you a better programmer even when you dont write viruses yourself.

---

Then they can find another appropriate forum.

Quote:

---

Originally Posted by KIBO

I still think its strange to prohibit talking about cracking/hacking etc. If somebody really wants to learn that he wont be put off by some forum rules and knowing the "dark side" of coding does help to make you a better programmer even when you dont write viruses yourself.

---

That's because it's most often used in ILLEGAL purposes, which we do not condone.
Besides, mods DO review these cases on a case-by-case basis, as the rules state.
If it's for legitimate reasons, it's OK.

I understand the reasoning why its forbidden but dont you see my point?

Now its like that people who want to write viruses do it anyway and people that dont want to do it are kept in the dark forever. The knowledge on virus tricks always helps you, even if you dont want to do "evil" things with it.

Quote:

---

Originally Posted by KIBO

I understand the reasoning why its forbidden but dont you see my point?

Now its like that people who want to write viruses do it anyway and people that dont want to do it are kept in the dark forever. The knowledge on virus tricks always helps you, even if you dont want to do "evil" things with it.

---

Ehm, yes and no. The more places you can find public information about such subject, the more likely it is that some "script monkey" [that is, someone who doesn't know muh him/herself, but can "copy and paste"] will be able to do some harm by using information on this forum. That is why this rule is, it prevents the SPREADING of such information.

There is a second reason: Some of the members here access the board from work. Websites that have "cracking" content is sometimes black-listed by the nanny-state proxyservers that companies use to prevent "web misuse".

--
Mats

Further, it's often illegal to help in aiding people who do bad things.
And to further the point, some people simply don't want anything to do with people who do bad things.
Those are 2 more good reasons why the rule exists.
So again, if you provide that your case is a legitimate one, those "forbidden" techniques doesn't become "forbidden" anymore if the moderators deem it fit to discuss.

you're right ;)