Page 3 of 3 FirstFirst 123
Results 31 to 34 of 34
  1. #31
    de.bug's Avatar
    Join Date
    May 2009
    Gender
    male
    Posts
    30
    Reputation
    12
    Thanks
    9
    My Mood
    Amused
    The problem is your allocating new memory on every call and not calling delete [] to free it. Next problem is if you free it you can't return it which is why I suggested passing a buffer to hold the output. This is better suited to be a class though.

    Something like this
    Code:
    char* Decrypt( char* pIn, char* pOut, int BufSize)
    {
        int length = strlen(pIn);
        if (length > BufSize) return 0;
    
        //do your encode/decode and write output into pOut
    
        return pOut;
    }
    
    char* pDecoded = new char[64];
    
    if ( Decrypt( "encodedstring", pDecoded, 64) )
    {
        
    }
    
    // free the memory when done
    // note the [] used with delete, this is because you used new char[]
    delete [] pDecoded;
    A better solution is to use the pre-build event in VS and write a script using python, perl whatever to generate a header file with encoded strings. The advantage here is the script knows how many strings there are, the max length and can make a random key on each new build. I do this but use a class to access them, the class keeps track if a string is already decoded or not, allows you to have a valid pointer to a given string at all times etc.

    This is basically how i access do mine using a class and pre-build event to create the header file.
    Code:
    // to retrieve or decode a string
    char* pStr = g_pStringManager->GetChar( STR_SOME_STRING );
    
    // End of render frame secure them
    g_pStringManager->SecureAll();
    
    //In header file I simply generate defines
    #define STR_SOME_STRING "encoded_string_data"
    Think on the class based solution and build events would make a nice project for you to tinker with.
    Last edited by de.bug; 08-22-2012 at 01:25 AM.

  2. The Following User Says Thank You to de.bug For This Useful Post:

    Password77 (08-22-2012)

  3. #32
    Password77's Avatar
    Join Date
    Jun 2012
    Gender
    male
    Location
    Canada, ON
    Posts
    181
    Reputation
    10
    Thanks
    181
    My Mood
    Cheerful
    Thank you for clearing it up
    Quote Originally Posted by de.bug View Post
    The problem is your allocating new memory on every call and not calling delete [] to free it. Next problem is if you free it you can't return it which is why I suggested passing a buffer to hold the output. This is better suited to be a class though.

    Something like this
    Code:
    char* Decrypt( char* pIn, char* pOut, int BufSize)
    {
        int length = strlen(pIn);
        if (length > BufSize) return 0;
    
        //do your encode/decode and write output into pOut
    
        return pOut;
    }
    
    char* pDecoded = new char[64];
    
    if ( Decrypt( "encodedstring", pDecoded, 64) )
    {
        
    }
    
    // free the memory when done
    // note the [] used with delete, this is because you used new char[]
    delete [] pDecoded;
    A better solution is to use the pre-build event in VS and write a script using python, perl whatever to generate a header file with encoded strings. The advantage here is the script knows how many strings there are, the max length and can make a random key on each new build. I do this but use a class to access them, the class keeps track if a string is already decoded or not, allows you to have a valid pointer to a given string at all times etc.

    This is basically how i access do mine using a class and pre-build event to create the header file.
    Code:
    // to retrieve or decode a string
    char* pStr = g_pStringManager->GetChar( STR_SOME_STRING );
    
    // End of render frame secure them
    g_pStringManager->SecureAll();
    
    //In header file I simply generate defines
    #define STR_SOME_STRING "encoded_string_data"
    Think on the class based solution and build events would make a nice project for you to tinker with.
    Doing more Java and Python
    Need help with your hack? Ask me, I will try to help you with all my might .

  4. #33
    Departure's Avatar
    Join Date
    Nov 2010
    Gender
    male
    Posts
    818
    Reputation
    125
    Thanks
    1,785
    My Mood
    Doh
    I don't see the big deal about Xor, it is the most basic of all methods to encrypt, and the only thing in common with assembly is the "Xor" function which is just short for "Exclusive OR" which is a very common mathematics function. Beside from a simple shift encryption this has to be the most easiest method to decrypt... Now that I think about it I am sure it wouldn't be too hard to make a shift encryption routine that would harder to decrypt than a simple Xor as it uses a constant to decrypt... atleast with something like a vigenere shift encryption it is nearly impossible to decryption without knowing the key. <--- I dont want people saying about a frequency analyzing the encrypted vigenere is considered easy as we all know its not that simple with short words or phrases(as used in hacks).

    Anyway never mind my ranting on, I just thought to inform the misinformed that Xor is not as 1337 as some people may think.....

    P.s
    Just to clear something else up Xor can not be detected as some suggest, Xor is used all over the code to zero out registers, values ect.. ect.. Xor value with it self will always return 0 so it is very commonly compiled from high level languages to zero out a value or register value, Try it for your self, create a small program that zero outs some value and then open that program in a debugger/decompiler ect.. and you will see there is a good chance it has been compiled down to a Xor statment,
    Last edited by Departure; 08-25-2012 at 09:29 AM.
    DJector.Lite
    Get the advantages of new injection technology, with 1 click easy to use injector, work for all platforms x86/x64

    Download

    D-Jector
    Get the most advanced and full featured injector around, works for any game and any platform x86/x64, nothing comes even close.
    Download

  5. #34
    Jason's Avatar
    Join Date
    Apr 2010
    Gender
    male
    Location
    /dev/null
    Posts
    5,706
    Reputation
    907
    Thanks
    7,297
    My Mood
    Mellow
    Quote Originally Posted by de.bug View Post
    You made some valid points but I'll stand by what I said about the scope of a variable. Just because garbage collection is broken or may not happen it's not good coding practice to return a pointer to a variable declared inside a function unless you define it as static. Either way this code is broken due to the massive memory leak it creates.
    No, no. You're confusing the issue of returning stuff from functions. I'll agree that it can be better, and more obvious, to add an extra parameter to handle the buffer (i.e functions like itoa, fgets, etc), but it is still perfectly valid and reasonable to return a pointer to a heap allocation from within a function, it should just be properly documented so that the caller knows that the return value will need to be free'd. There is no chance of the pointer being "garbage collected", because there is no garbage collection in C++ (unmanaged, of course), you deal with it yourself.

    For example, if you were writing some sort of function that deals with indeterminate quantities of data, it is far easier, and more efficient, for the function to control its own memory allocation.

    Consider the following: Write a function which reads the contents of a file into memory.
    How are you going to approach this with a predefined buffer? Do you just ALWAYS allocate a massive buffer and hope that each file read is smaller than the buffer, or do you handle the dynamic allocation within the function, and then just free the result?

    Here are both scenarios.
    Code:
    static unsigned char *read_file(const char *filepath, unsigned char *buffer, size_t bufsize, size_t &nbytesread)
    {
    	FILE *fp = fopen(filepath, "rb");
    	nbytesread = 0;
    	if (fp)
    	{
    		fseek(fp, 0, SEEK_END);
    		size_t filesize = ftell(fp);
    		fseek(fp, 0, SEEK_SET);
    
    		if (filesize > bufsize)
    			return NULL;
    
    		fread(buffer, 1, filesize, fp);
    		fclose(fp);
    		nbytesread = filesize;
    		return buffer;
    	}
    	return NULL;
    }
    Code:
    unsigned char buffer[20480];
    size_t filesize;
    if ( read_file("example.txt", buffer, sizeof(buffer), filesize) )
    {
        buffer[filesize] = 0;
        printf("%s\n", buffer);
    }
    Not exactly optimal. You might read a bunch of small files and only need say...1 KB of space for each one. Or, you may need to read a 20MB file. However, if you handle the dynamic allocation internally, then it becomes a lot cleaner:

    Code:
    static unsigned char* read_file(const char *filepath, size_t &nbytesread)
    {
    	FILE *fp = fopen(filepath, "rb");
    	nbytesread = 0;
    	unsigned char *buffer = NULL;
    	if (fp)
    	{
    		fseek(fp, 0, SEEK_END);
    		size_t filesize = ftell(fp);
    		fseek(fp, 0, SEEK_SET);
    
    		buffer = new unsigned char[filesize];
    		if (buffer)
    			nbytesread = fread(buffer, 1, filesize, fp);
    		
    		fclose(fp);
    	}
    	return buffer;
    }
    Code:
    size_t filesize = 0;
    unsigned char *contents = read_file("example.txt", filesize);
    if (contents)
    {
        printf("%s\n", contents);
        delete [] contents;
    }
    You just need to remember to call delete[] on the result when you're done with it.

    Quote Originally Posted by Jeremy S. Anderson
    There are only two things to come out of Berkley, Unix and LSD,
    and I don’t think this is a coincidence
    You can win the rat race,
    But you're still nothing but a fucking RAT.


    ++Latest Projects++
    [Open Source] Injection Library
    Simple PE Cipher
    FilthyHooker - Simple Hooking Class
    CLR Injector - Inject .NET dlls with ease
    Simple Injection - An in-depth look
    MPGH's .NET SDK
    eJect - Simple Injector
    Basic PE Explorer (BETA)

Page 3 of 3 FirstFirst 123

Similar Threads

  1. [Release] Encrypted Strings
    By Flengo in forum Combat Arms Hack Coding / Programming / Source Code
    Replies: 6
    Last Post: 12-24-2012, 07:23 PM
  2. [Info] nmconew General Packet Format and Encryption
    By Fovea in forum Vindictus Hacks & Cheats
    Replies: 11
    Last Post: 05-15-2011, 03:08 PM
  3. Program 4 auto-Serials and encryption
    By Web-Designer in forum Coders Lounge
    Replies: 3
    Last Post: 01-03-2011, 01:41 PM
  4. [RELEASE||HELP]Compression and Encryption of Byte Arrays
    By topblast in forum Visual Basic Programming
    Replies: 0
    Last Post: 12-24-2010, 02:21 AM
  5. Strings and chracter arrays
    By zeco in forum C++/C Programming
    Replies: 0
    Last Post: 08-04-2009, 04:14 PM