In-memory execution problem

[kbw]

Looking around, libelf seems to be the thing to use.

A function is just code that's already been placed in memory and all ready to be run. An executable isn't. This is what I think you should do.
1. Try to understand some description of ELF. This is a good place to start. http://www.freebsd.org/cgi/man.cgi?elf%285%29
2. Revisit your libELF sample to get a feel for what libELF provides and how.
3. You haven't explained what in the executable you wnat to run. You need to decide what part of the program you want to run.
4. Work out how to get hold of the function you want to run.
5. Work out how to load that function into memory such that you can run it (with libELF's help).

[vladimirr]

Guys Thank you, I found out why:

DEP (Data Execution Prevention) security measure by microsoft.

Also, nobody mentioned that I can use .text and .data segments in ELF exe in __asm function

I didn't try it, but I will do hoping that it won't fall in DEP hole.

or even transforming those into the raw binary data 0x** ..etc

Also I will do a research on bypassing DEP in C++ .

Cheers,
Vladimir.

[Computergeek01]

DEP (Data Execution Prevention) security measure by microsoft.

I'm pretty sure it was Intel who invented it but that's not important. If it's a problem then you could just TEMPORARILY turn it off in your systems BIOS. Keep in mind that in addition to providing critical security features it is also used as a crutch to maintain stability in some poorly written applications. EDIT: Can anyone think of a VM that could sandbox this functionality for OP?

Bypassing DEP is one of those "fun" topics where even if you care enough to sink a few years into studying it you'll still be that much time behind the modern implementation. It's a bit obvious and therefore easy to detect, but writing a driver to disable it is still the go to way to do about this, at least in Windows that is but I can't imagine *nix being that much different. It's mostly a hardware setting after all so there aren't a whole lot of other channels to go about doing it.

FOR_THE_RECORD: The right answer was to rewrite your embedded application as a stub\.so file. This is not a new problem and the approach suggested to you is well documented on every OS out there.

[helios]

What I understand from reading Wikipedia, both VirtualBox and VMware emulate DEP if the host has the virtualization instruction sets.

[vladimirr]

I am using Windows 7, and i was mistakenly saying ELF (for linux), it's PE.

@Computergeek01 Thanks for you answer, but when I turn it off from by bios, other machines will have the DEP functioning , so there's no particular change in the program.

@helios is there an algorythm in C++ to bypass it ? in both the pc and VM

[helios]

The way to "bypass" it is not to. Just copy the desired code into a page marked as executable.

[Computergeek01]

@ OP: And? Do you find that there are a great number of remote computers that you would like to display the phrase "hello world" on? If your environment is Windows 7 then don't let yourself get bogged down with silly old DEP\LSM. You're going to have a heck of a time with session isolation, lsass || csrss and remote authentication as it is. That's after you get passed the firewall (which is surprisingly easy on 7 once you establish your credentials and learn where to look. It was, and still is, a migraine to do on XP_SP2).

Look OP, if you're just trying to impress your friends with things that not everyone can do on a computer then look for up and coming stuff that's in development like 'RoCE'. That way you may at least be able to do something productive with your results for all of the time and effort you'll put in.

[vladimirr]

lol i'm not gonna "impress my friends". It's a program that really needs this function.
and btw, what do you mean with "OP" ?

i'm not gonna display "hello world", i'm gonna display "f*ck you" in every computer.

@heios i can use __asm maybe, i'll try it now.

[helios]

I suspect OP is really not up to the challenge.

[Computergeek01]

OP = Original Poster = You without the ambiguity of someone else thinking that i am talking to them.

Assembly? No, don't bother. Most AV suites have a hairline trigger for any program that even contains the address for that function (or is it a macro?). The way to do what you're looking is to compile the embedded application into your "sabot" (for lack of a better term). Then upon execution create a file map with "CreateFileMapping()". Then map the resource from the outer binary to memory with "MapViewOfFileEx()". From there you write it out to the disk with "CreateFile()" and "WriteFile()", use "GetTempFileName()" and prepend a space to the beginning of the resulting string if you really want to be a bastard about the whole thing. I'm telling you right now though that you're wasting your time with this stuff. After a certain point no one will understand enough of what you're talking about the be impressed by your boasting and you're years, or a prison sentence, away from being able to develop any of it into a legitimate revenue stream.

[helios]

Most AV suites have a hairline trigger for any program that even contains the address for that function (or is it a macro?).

It's neither.

Honestly, I'm still not clear on what OP wants to do, or why he needs to load a binary to memory to do it, or why he thinks he needs to do that.

[Computergeek01]

My past few posts were under the assumption that he is looking for some kind of self-extracting executable. As for why? Your guess is as good as mine. My only guess is that maybe he doesn't know enough yet to know that there are better alternatives?

[vladimirr]

Ok, i will tell you what i'm doing.

There's a malware, and I'm making a new way of hiding it.

A program of random tasks with a malware hidden inside to be executed inside those random tasks.

So the AVs won't recognize the malware with digital signature.

Thats it. (educational purpose) :D

[vladimirr]

and the ISSUE is the pogram will crash.

even if I run this: http://www.exploit-db.com/exploits/13729/

"a shellcode" and copy the wole code as is, it ill crash.

I have 64bit windows, i tried it on my second machine 32bits and had the same issue (program crash)

The question was about WHY the program is crashing even though i tried it in two computers ? (compiled/ran it in two computers)

EDIT: I debugged the program, before it crashes the debugger shows an error :
"Don't know how to continue because memory at address 00000003 is not readable. Try to change EIP or pass exception to program."

[Computergeek01]

@ OP: I really don't know how you ended up at that site, but that is not an exploit database.

This is an exploit data-base: http://www.cve.mitre.org/index.html
and so is this: http://nvd.nist.gov/

But that site you linked to is just here say and garbage posted by script kiddies trying to look cool for their friends. Before you even say it, no, I do not except a social media profile as evidence of someones credibility, especially not when they post the kind of crap that you are polluting this site with.

You do not write assembly code with a char array of arbitrary hexadecimal values cast to integers. The fact that they didn't just start off with an array of integers in the first place maybe should have been a hint to you. Assembly code in C++ requires the 'asm' declaration (hey look at me! I finally found out what it was.): http://en.cppreference.com/w/cpp/language/asm

Now we can start in on the fun part, that is tearing apart this wretched excuse of a main function:

int main(int argc, char **argv) {
        int *ret;
        ret = (int *)&ret + 2;
        (*ret) = (int) shellcode;
}

Literally speaking, the only part of this that was done correctly is the entry point. The first thing the author does here is declare a pointer. OK fine, but a pointer to what exactly? The answer at best is nothing, otherwise it is undefined which is so much worse then nothing. The very next line, he tries to assign the address of an undefined pointer, so a pointer to a (not?)pointer (which by the way they cast to be a pointer, probably because the concept of indirection is just too much for this one to handle) which they try to off-set by 2 for some reason... I don't even know what they are attempting here. With you I think I was at least able to discern what you're trying to do, your entire premise is flawed by the way, but heuristics is an issue worthy of a thread all on its own. This is just like someone feel asleep on the keyboard and posted when ever was written to the screen. This only compiles because neither C or C++ care one tiny bit if you shoot your self in the foot.

If you see an errant superscript in there it's because I was trying to be clever and keep track of the red flags. But that whole thing is a red flag. I'm not doing this to insult you OP, it's better that you learn now why "script kiddie" is used as a derogatory term.

[vladimirr]

Okay, so

int main(int argc, char **argv) {
        int *ret;
        ret = (int *)&ret + 2;
        (*ret) = (int) shellcode;
}

is garbage, but I didn't even use it, I used

void *exec = VirtualAlloc(0, sizeof shellcode, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    memcpy(exec, shellcode, sizeof shellcode);
    ((void (*) (void))exec)();

also I used
((void (*) (void))exec)();
alone before that.

Do you think that DEP is behind the crash ?

or there's logical mis-coding ?

Do you mind if you give me a "Direct" answer ?

Vladimir.

EDIT: exploit-db site i found a big banner of it in kali linux in the default portal of the browser. I don't care about people "skids" or whatever, i care about my mission to be done perfectly no matter how and why.

[Computergeek01]

Do you think that DEP is behind the crash ?

I haven't compiled it, so I never debugged it but I don't actually think it gets that far. Are you trying to inline a call with memcopy? It's an imaginative approach but that isn't how that works. That's a dead end approach.

or there's logical mis-coding ?

It's an error in logic. Like I said, this isn't even close to how you write assembly into a C++ app.

Do you mind if you give me a "Direct" answer?

We did. If you want to write an self-extracting executable then I outlined that procedure above. If you want a program that runs inside of another program then helios gave you the answer yesterday. You would just have to change where he says ".so" to ".dll" because you hinted that you were using *nix, not Windows. If you want to know how to write what ever is being attempted with that assembly code then you'd have to tell me what that objective is first, I don't know x64 syntax (which is likely the wrong one for either of your systems btw).

[helios]

I don't even know what they are attempting here.

I presume they were trying to store the pointer to the array in the return address on the stack, such that when main() returned, it would jump there. It seems like it's highly dependent on the compiler generating a particular stack layout.
I don't know, I just don't see the point. All it does is, I think, call system("cmd") in a roundabout way.

[vladimirr]

I found the problem.

PVOID istead of void

and everything run smoothly.