This, I believe?
http://cboard.cprogramming.com/showthread.php?t=105728
This, I believe?
http://cboard.cprogramming.com/showthread.php?t=105728
Originally Posted by Adak
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.
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.
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.
And no globals, right?
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
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.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Is it really?
It's not cracking, hacking, copyright violation or copyright violation, as I see.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.
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.
Last edited by King Mir; 07-30-2008 at 08:11 PM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
>> 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.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
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'Okay, this may sound like a more advanced technique (if it isn't, then I guess I'm really still a newbie.
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 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!
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.
Yes, well at least, kind of.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.
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.
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.
Bingo!
Last edited by whoie; 07-31-2008 at 11:07 AM.
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
