Is this dangerous code?

[wtf]

#include <windows.h>
using namespace std;

class sneak
    {
        TCHAR EXE[2048];
        int size;
        string exe;
        public:sneak()
            {
                size = GetModuleFileName(NULL, EXE, 2048);
                for (int i = 0; i < size; ++i)
                    {
                         exe[i] = EXE[i];
                     }
            }
       ~sneak()
            {
                 system(exe.c_str()); 
            }
    } tweak;

int main()
{
    int * ip, i = 0;
    while(1)
        {
            ip[i] = new int;
        }
    return 1; 
}

I got several dozen processes for this thing running right now, albeit without the allocating memory part. as is its just going through an infile while(1); loop right now, but for some reason I can't seem to close the program and its draining my cpu. anyone can help?

[nano511]

Go to task manager and close it from here

[kev82]

Rename one of the directories in the full path of the executable, after that, system won't be able to relaunch it, and you can start killing them.

[Disch]

        string exe;
        public:sneak()
            {
                size = GetModuleFileName(NULL, EXE, 2048);
                for (int i = 0; i < size; ++i)
                    {
                         exe[i] = EXE[i];  // BAD BAD BAD
                     }
            }

strings are like vectors. The [] operator does not add new elements, it only accesses individual elements. However the elements you are trying to edit don't exist because you're accessing past the end of the string! Heap corruption

You're better off using assign:

exe.assign(EXE,size);  // easy 

( or, if EXE is null terminated, you can use the good old assignment operator:
exe = EXE; )

Although.. you have another problem. EXE is TCHAR and exe is string (char). You need to fix that.

Either make EXE a char and use the A version of that WinAPI function, or use a TCHAR string for exe:

// option 1:  TCHARs
        TCHAR EXE[2048];
        int size;
        basic_string<TCHAR> exe;  // or you could typedef basic_string<TCHAR> to tstring, or something
        public:sneak()
            {
                size = GetModuleFileName(NULL, EXE, 2048);
                exe.assign(EXE,size);

// option 2:  chars
        char EXE[2048];  // <- char, not TCHAR
        int size;
        string exe;
        public:sneak()
            {
                size = GetModuleFileNameA(NULL, EXE, 2048);  // <- GetModuleFileNameA
                exe.assign(EXE,size);

[wtf]

Rename one of the directories in the full path of the executable, after that, system won't be able to relaunch it, and you can start killing them.

Would I be able to do that if there is an application currently running in one of those subidrectories?

[wtf]

@disch
I changed it to EXE[size] = '\0'; exe = EXE;

And it seems to work now. (I actually tested it this time. Before i changed it, exe was "" even after assignment, now it is as it should be. )

Would something like this be able to defeat security features of an anti-virus program trying to close my program?... Not that I'm writing a keylogger or anything like that...

I been reading up on windows programming and was just experimenting trying to catch the WM_destroy message so that the window would stay open. But I don't seem to know what I'm doing in that respect yet so this is the best that I could come up with.

[Disch]

Would something like this be able to defeat security features of an anti-virus program trying to close my program?

Not really. Your program is still closing, you're just launching another instance of it right away. (If your program actually did anything, the user would see it constantly restarting when they tried to close it).

It's easily defeated by something like a rename (as kev82 suggested) or a quarantine (which AV is likely to do).

In Windows, there are easier and less hackish ways to keep your program open.

[wtf]

like how? Whats the method that GoogleToolbarUser_32.exe uses? I keep trying to close it from task manager, and when i do it dissappears, then 5 minutes latter its back up there again.