Hello Everybody

Could someone show me a few basic routines for hiding calls to my own PROC, API calls and jmp. Also do JCC Jxx do this own it on. If so the processer is really cool ... I read something about that here a few days ago or from old threads on disk. Anyway it had make me ready to seriouly learn this stuff.

I know it can be tracked by an api hooks and other methods. I more than half way accepted that fact and have no problem with the professionals and the big guys with a super emulators with 20 processers.

I'll be happy just to know that little Johnny at 9 years old or the office secretary doing lunch break don't crack my app so fast. So even the basic of ideas would really help and that's all i seek. I never had a clue honestly.

Thanks in advance
Posted on 2003-08-31 13:07:54 by cmax
Simply put them in a very obscure and dark corner of your program where no one will look. And make sure the program won't work without them. Encrypt code you don't want people to see. Check the first byte of all API functions that you call and make sure it isn't 0xCC (INT 3). And check the debug registers.
If you're making a registration key checker, you could encrypt all of the program with the key.
Posted on 2003-08-31 16:52:27 by Sephiroth3
Maybe store them as RC_DATA in your resource section then use LoadResource/LockResource and call the pointer that it returns. That should screw up a few minds :) the function call is then not hard coded at all, no permanent address. Anyone examining your code section would not even find the code in there, you could hide the address by moving it from the data section to the code section:
jmp @F

pProc dd ?

invoke FindResource,hInstance,IDR_PROC,RT_RCDATA
mov hResInfo,eax
invoke LoadResource,hInstance,hResInfo
mov hResData,eax
invoke LockResource,hResData
mov pProc,eax

CALL pProc
Not sure of all the technical details but it would be fun to try
Posted on 2003-08-31 16:59:24 by donkey
Nice idea donkey,
But how could I store code in that section.. I mean should I first compile it into .lib and then include into res.
Or maybe dump the code from memory?
Also there are few other problems, that code must not use any fixed offsets, or else it might crash. And when you lock it with LockResource you should probably set "executable" flag to that memory region.
Posted on 2003-08-31 19:03:17 by Mikky
Yeah, relative offsets (+/- 127 bytes) only and you would dump from memory. No direct api calls. But you don't have to store the whole procedure there just a few pure ML functions or sniplets from a larger procedure. We all have alot of routines in our programs that are just a large calculation. Stack variables would be fine, esp/ebp would be predictable, pass absolute addresses on the stack or in registers and they can be accessed from with the procedure. Ollydbg and a hex editor can be used to snip the appropriate code out of the main program save it to a file then recompile with it in resources. Just be sure to pass everything on the stack.

PlaceWnd proc hWin:DWORD,pSetWindowPos:DWORD,x:DWORD,y:DWORD,w:DWORD,h:DWORD
push h
push w
push y
push x
push NULL
push hWin
call pSetWindowPos
PlaceWnd endp

mov eax,OFFSET SetWindowPos
invoke PlaceWnd hWin,eax,x,y,w,h

Data in resource:
55 8B EC 6A 40 FF 75 1C FF 75 18 FF 75 14
FF 75 10 6A 00 FF 75 08 FF 55 0C C9 C2 18
Posted on 2003-08-31 21:06:42 by donkey
"Check the first byte of all API functions that you call and make sure it isn't 0xCC (INT 3). And check the debug registers."


How is this done... After a call where do you go. I thought the only thing that returns from API was result or nothing in EAX. Can this be done without an api hook. And how do you check Debbug Registers. Is there something somewhere where i can read about this.
Posted on 2003-09-01 02:28:58 by cmax
there is also using base address of where the import table is..


jmp dword ptr [4*base+value]

so if you know what order your imports are then you can call on them like that...

you can also do a call in the same way...

with this method you can call you procs all through one process so it make it hard to do patching with out hooking..

you can also make your own table but if they patch it and redirect to there own code then thats no good... i guess its also sort of true the other way..
Posted on 2003-09-01 03:36:05 by devilsclaw
Testing Testing 1 .. 2
There is only ONE holoday and that is the 4 of July when ALL the girls come out no matter what.

Great points guys. I got a feeling that when i am through i can guarantee little Johnny a FULL 50 year MISSION. But i do need a few more smaller pointers before i can do battle with me sons.

This is really great but i though something like

CALL FindFirstFile be hidden like this has SOME bearing ... Posted on 2003-09-01 09:28:53 by cmax
Ok, I won't laugh :)
It's not stupid really, if you work on it a little more (like doing some operations on EAX before calling) it could hide the call from dissassemblers. As it is now, however, if you debug it with OllyDbg it still shows you wich API call it is when you put the cursor on the call instruction. And I don't think it would fool IDA or similar programs either.
Consider this (didn't try it, though):

push param1
; do some stuff
:push param2
; more useless stuff
mov eax,FindFirstFile
add eax,somenumber1
xor eax,somenumber2
;do more stuff
xor eax,somenumber2
sub eax,somenumber1
;now EAX still holds the same number (pointer to FindFirstFile)
; but we (hopefully) confused the disasm
call @F
@@: jmp eax

If it looks confusing enough, it might help...
Posted on 2003-09-01 10:07:03 by QvasiModo
It's good to know that things can be done just by doing simple or stranges things. I never had a clue until now. Now i can play without thinking it will never work, i got to get this or is it that .... What a relieve. Now i can THINK.

Thanks Everybody

Posted on 2003-09-01 17:52:33 by cmax