Making source code unreadable will protect it from some newbie kind of person from reading and understanding it.
There are cracking wizards who crack your software by patching various places by JMP and make eveything working.
Printable View
Making source code unreadable will protect it from some newbie kind of person from reading and understanding it.
There are cracking wizards who crack your software by patching various places by JMP and make eveything working.
Personally i wouldnt rely on a single bool setting the entire applications registration state. Thats where a JE (74) op code can easily be changed to a JNE (75) or even a JMP (EB). Extremely simple to patch.
Instead, theres a guy on this forum with a webpage called "Sams Simple Samples". On his site theres an excellent example of how to setup function pointers. Well instead of your app returning a bool, return an integer no matter what and dependant on its value, call a different function from its pointer. Great fun to mess with even if you dont want to use and well worth a look.
Function pointer manipulation can be breaked by using API Spying+debugger.
Nice suggestions. My code was simply an example of renaming functions to obfuscate code. I wasn't recommending the use of a single bool to hold the registered state. A more creative solution is required, and yours is good.
I think it's probably better not to store the registered state of the application in memory. It probably a good idea to call your validation routine every time you need to know if the app is registered. Also, don't put all your eggs in one basket. Have several validation routines, each which validates in a different way. Whenever your code needs to know if the application is registered, you could call one of your registration validation functions at random.
Make your code complex and be creative, but remember to keep it tight. You don't want to cripple your apps performance with deliberately redundant code.
Write a bunch of functions that check the validation. Organize each of them in a different manner, so they don't produce the same assembly pattern. Make all of them inline (or better force_inline, if the compiler permits this). Have the functions call a bogus function pointer if they don't find a validation -- i.e. crash the app. Don't use only one validation pattern, but 2 or 3.
Use the functions often, and randomly spread thru your code.
Make up a fake validation routine and use that in a timer, with a messagebox that sais "Not registered" or so. Leave the string as is -- visible in the PE. This will lead a large part of the wannabe crackers on the wrong path.
Good suggestions Gabriel. Particularly the inline validation functions. If they've gotta patch your app, make them patch it in 100 places.
Furthermore, calling on the bogus pointer Gabriel suggest could in fact be the "key is valid" action. Supplying an exception handler futher up in the code will catch the crash and perform the validation.
Just another slant on the theme.
Have anybody worked with finding length of function of any kind.
I can find it when it has prolog and epilog of std. way. But it's problem to determine the length when functions are naked and have multiple returns depending on situations.
Have a look at this snippet:
Code:/*
The ideea behind this snip is to make the code look like
nonsense at a first glance, when dissassembled or watched with a debugger
*/
LPSTR lpszMessage = "Testing";
_asm{
push eax
push 24
push lpszMessage
/* save EAX */
call stealth /* this will put the address of the
next instruction (_emit..) on the stack*/
_emit 0xea /*this is the opcode of a absolute far jump;
it will take the next four bytes as operands,
or, at least, it will look like this, dissasembled;
this means that the opcodes for "pop eax" and
"call the_test" will dissapear, being treated as operands by
a disassembler */
stealth:
pop eax /* remove from the stack the address pushed by "call stealth" */
call the_test /* call your proc */
pop eax /* Pop twice in EAX, cause with _cdecl*/
pop eax /* the caller must restore the stack*/
pop eax /* restore the EAX, pushed at first */
}
/*
naturely, if someone takes a closer look, he will notice that "call stealth"
is translated to a call to an address that is not a mnemonix, but inside an instruction;
taking the code and analyzing it with "paper and pencil" can reveal the real
functionality. The problem is, that if one has enough stealth calls, that vary in their
implementation, the hacker's job becomes harder.
*/
Simply gr8 idea ! ,whats if call stealth is replaced by
MOV EIP ,stealth :D
You cannot use EIP as move targer AFAIK; i.e. you cannot directly manipulate EIP. But of course that you can "hide" a few well thought "PUSH the_test", and then do a RET **evil grin** ;) It will look like the return point of a proc, when it actually is a call to the_test.
For example: take the address of the proc you want to call. Scramble it using some validation and push it. Do some other work and then do a pop, unscramble, push. Again some other work, then a ret. If the unscrambling wan't successful (i.e. not registered) it will ret into Wallhalla :D
I see ......
What are other options to make EIP contain function address and stack is correctly filled.
In the case of push test_fun and ret , it's neccesory that the function do not accept parameters with cdecl. I tried and the function got corrupted stack.
Eeeeeeeeeeeeeeeha , got it ...It works fine for a naked function , ... ... So it need to be manipulated with naked functions. and naked function will call the actual thing.And to make it toughest we can keep naked functions encrypted in data seg.
Following is the code..
void _declspec (naked) myfunc(void)
{
MessageBox(0,"Hi ","How r you",0);
exit(0);
}
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
// TODO: Place code here.
void * ptrxx=(void*)myfunc;
__asm{
push ptrxx
ret
}
}
One problem with above code snippet , it's all MyFunc's responsibility to drive the program control , because as MyFunc ends , it will show a great error , because of corrupted stack. Thats why I have called exit(0) in that.
I recommend you guys code the protection schemes in asm directly, using MASM32, and then linking it to your code, since VCPP assembler is very poor.