Hi all
I'm working on a protection algorithm for my
proposal.I write my algorithm here to everyone
because the cracker are the best protectors if
they want and can tell me this algorithm's weak
points.

I send you abstract of my protection tec.

ONLY FOR EXE FILES.

Phase 1: adding some debugger detection
algorithms to EXE.
Phase 2: replacing all jumps as folowing:
--- ---
--- ---
jxx y jmp a
--- ---
--- ---
a: push r
push t
int 3
there 'r' is some needed data such as process
ID,Jump type,etc. and 't' is target address
of jump that is coded in an algorithm such as RSA.
phase 3: writing a low level hook for "int 3" that
decodes the target address of jump and jumps to
it if is necesssary.
Phase 4: adding an packer surface to program.my
tec in this phase is based on UPX that is an
opensource packer.

protection features:
1-No debugger and dumper can debug this application
because of INT 3;
2-packer surface will make trouble for disassembling.

thanks for help.
sincerely yours.

Hello,

Your protection idea to use int 3 isn't new.
Actually its a rip off of Armadillo nanomites.

I assume you are going to use a driver to hook int 3.
Im not really sure to understand how you will handle the jmps though.

how do you know where to jmp ? how do you handle the flags? etc

Also, UPX won't help to protect against disassembling. Sorry.

Some immediate problems with the "replacing jumps technique":

1.
It seems like you least said will be short of opcode bytes to do that replace (especially if you will encode the addresses with RSA, which is completely unnecessary btw).

2.
Replacing all jumps like that will make the program so slow that it will be unusable.

3.
Mass-replacing opcodes in general is prone for errors, especially with short opcodes like jumps, which will in turn also make the target unusable.

I'd like to know how you plan to use RSA. I.e. who's having the private key? and will it be signing you will be doing? Have you thought about performance? Theres a reason symetric ciphers were invented and still being used today.

Thanks in avance.
-- CyberHeg

Yeah, that's what I implied above too...

thanks for imediate answer!
I only tell "such as RSA" that mean I have no
perfect decision for algorithm.
I know it's aproximately 20% of a program is
its jumps,and this algorithm will slow down it,
But nowadays with the speed of increment of
computers performance,I don't this think slowing
down is very important.
I only want to know other than performace problems,
is there any stucturaly problem in this algorithm
that prevent of making a program work when it is
protected in this way?
Is there any better way to protect???
about jumps targets,perhaps this show it better:
---
---
jxx a
---
---
is replaced by:
---
---
jmp loc1
---
---
loc1:
push r
push t
INT 3
the target 'a' is now coded and is 't'.
r show flags,etc that is needed.
The decoding of target adress will be in the HOOK.
ALL suggestions are welcome!

thanks

bullshit

Hello,

Hooking an INT requires to deal with a driver since it can only be achieved in Ring0, at least on NT environment...but you can find some good source code on INT hooking with drivers.

Even with hooking the INT3, I'm not sure that Softice can't handle this...

Before going any further on developping the protection, make sur Sice can't trap the hooked INT3. If it can, your projet will be good to be directed to the trash bin. (A simple I3HERE and/or bp int3 and all the protection is dead).

Regards, Neitsa.

Ok, here's a 30-second crack for this scheme:

1.
Dump exe from memory.

2.
Search/replace-patch all the push/push/INT3 sequences with "call <own dumped copy of decryption procedure>".

3.
Enjoy your working exe.



No, not a single way! Ok, just kidding, maybe a couple... of millions.


And again, please see my comments above, about the relatively grave problems with the whole jump patching concept to begin with (not only performance related, and about that, the performance hit with your described method will be far from "not very important", believe me...).

Hi
What an exact attack!
I thought this attack on this algorithm
but I can't find any better way to prevent
dumpers and debuggers to dump or debug
my protected application.



Is there anybody to tell me Only one way
to prevent debuger and dumpers to debug or
dump my protected application?
Who can tell me a better algorithm?

Note:I know it is almost impossible to make a
program protection uncrackable,But I only want
to prevent a normal crackers to crack it.

sincerely yours

As you say yourself, you can never really prevent it, only make it harder. One theoretical way to make it harder to dump the program, while still sticking to at least a similar concept as the original one is to keep encrypted copies of certain code pages in dynamically allocated memory (possibly in a separate process space), and then decrypt them in response to page fault exceptions generated by manipulating the memory permissions on the corresponding code section pages. One important difference from your scheme is that the encrypted data will not follow with a dump. It will also be much faster and less prone for errors.

Hi
I read the last reply,Perhaps I don't get the algorithm correctly,
but in general,Paging a program will make to many problems because
of Jumps.
With the Locality Law a large number of jump targets in a page will
be in the same page,but calculating the other jump targets that is
not in the same page is a problem and replacing new page with old
one will happen to many times that will slow down the program to
much(even there is no decryption).
But if I don't get algorithm correct,please tell me more detials.

Sepecialy thanks dELTA for its replies.
sincerely yours

I'm not sure what you mean, there is no need whatsoever to care about any jumps or jump targets with the method I suggested? And no, it will not be slow, and especially not compared to what you suggested earlier. You do of course not have to replace the protected pages for each instruction, you could for example replace one restored page with a "tripwired" empty page (preferably using an algo that selects these pages to be far from each other in memory) everytime you restore another such protected page due to a memory violation exception from it.

Also, if at all possible I'd prefer not being referred to as "it".

Hi
Before every thing,My english is not very well then I
am sorry for errors.I correct my sentence:
Sepecialy thanks dELTA for his/her replies.

But As I said,I don't get the algorithm correctly:

You mean all the code segment is encrypted?then its decrypting gets
too long.

In addition,This method will prevent debugging?If this algorithm is as I
think,a debugger can run the program normaly and debugger prevention
will not be added.

thanks so much for help.

As dELTA states, the performance hit of your suggestion is FAR from non-trivial. I can speak on this idea from experience. A while ago I was playing around with writing a "profiler" tool that could do a sort of coarse grained trace of control flow altering instructions like jmps and calls. I implemented this as an IDA plugin to get all of the jmp references and then wrote a debugger to set int 3 breakpoints on them and log them... This is similar to what you are proposing, but I digress... Suffice it to say that I ran Notepad under this scheme, and a couple minutes later the main window came up on the screen, lol. Perhaps this is an acceptable overhead for tracing an application. It is not, however, acceptable from the end user point of view. And just in case you think I'm running this on an old Pentium 100 MHZ, it is a reasonably up to date machine with a 2.2 GHz processor and 1.5 GB memory.

Cheers,
Clandestiny

afshin_pir, don't worry about the English, just kidding.


No, you can select any arbitrary number of random pages to do this with, not necessarily (and not to be recommended) all of them.

And no, this scheme does not have anti-debugging "build into it", but it is probably most wise to separate the two (anti-dumping and anti-debugging) for best results anyway (search for separate anti-debugging tricks). Well, actually you do get something of an implied "protection" against direct debugging of the application by a ring 3 debugger anyway, since it won't be able to attach to the process when it is already being debugged by your parent protection process.

Hi
then you mean at the last phase I use an algorithm that
run my application in debug mode then a debugger can't
debug it.
But still for dumper i think that the program will dump in this way:
---
---
b:
decrypt a
---
run a
--
jmp b

when replaced by:
---
---
b:
decrypt a
---
dump a <----cracker jmp to dumper for dumping a
run a
---
jmp b

You don't think so?
sincerely yours

I think along with stupid newbie questions, questions related by protectionist authors should also be banned on this board.

Pseudo crackers-who-can-also-protect-and-knowledge-is-free-so-give-out-how-leet-you-are-by-teaching-others-how-to-protect stuff should also be banned.

I think we are endangering our cracking by going into too many protectionist advise. It seems people on this board are begging to big companies who may be lurking around(look how leet I am!!! I can also protect!!! Offer me a gazillion dollar paying job in your organization.pleaeeaasseee!!)

What do you think?

Flame On

Have Phun

hello,
this type of redirection is also done on a malicious protection I investigate year ago :

prg -> self decryptinghread
thread call drivers which also decrypt himself and instaure permanent int1, int3, dr content, GD hook&check
now, in thread
push adress
embedded int3
then you go to drivers which check debugger and process responsible of the int if ok set some parameters then go back to thread int3 handler
thread int3 handler decrypt pushed adress and alter program flow to go on.

It is of course difficult to debug, but as you are tending to hook system, any unsuspected mess with stack, NMI, interrupt levels tend to reboot. What will you do on a dual processor system ?

Such protecting system are not safe for the host computer, that is not good. Look how UCF is protecting some of their patch and you will see some obfuscation that bore tracers and reverser to death.

hope it will help you a little.
Regards

Hi
This algorithm is not very well as what it said in replies.
But:
Last reply is correct when I only push target address.
my algorithm pushs two values:

that:
r = required data such as register values,process ID,etc.
t = target

when I have process ID in hook my pushing r to stack I can
simply test that if our protected program is maked that interupt,
else we alow normal running of every thing.

sincerely yours

I'm not sure where this "b:" location is supposed to be located, and neither why it is in a loop, but if these protected memory pages are spread out in a random fashion, you can also quite easily prevent direct enumeration of them, which means you'd have to manually "touch" them all to secure a good dump. Also, making any such modifications would require changing the code of the parent debugger process in a non-trivial way, and then we are just back to the "nothing is uncrackable with enough effort" fact.

Hi.

Where can i find more information about nanomites?
I am intrested in it.

yours sincerely.
mahdavi.

clearly using RSA is not necessary. your protection schema is not based on encryption technique. it should be based on avoidind debugers and dumpers and dissassemblers and so on.

Hmm, I've heard about this great place, a messageboard I think... The admins are supposed to be really great too (not to mention handsome), I just can't seem to remember the name, RCE something... I've even heard they have a working search feature.

Oh No. They actually have a "SEARCH" function into which one could put something such as "nanomites" and actually find information? Who'd a thunk it.

Regards,

Hi all
After these replies I decide to change my algorithm
and goto paging tec.
The changed algorithm is following:
1-I will add some ring0 debugger detection to application.
2-Then I split code segment virtualy to parts,for example p1 to pn
3-Adding decryption code for following encryption to application
4-I change the jump target for each i>1 as following:
ti' = e(ti) xor MD5(i-1,ki)
that:
ti :last jump target
ti' :new jump target
e :encryption using Raijndal algorithm
MD5(i-1,ki) :means MD5 algorithm on virtual part i-1 using pattern ki
ki are a combination of TR(Trap flag) .

features:
1-Debugging this program is not too easy,because adding breakpoint
(INT 3) will change MD5 hash and targets will change.
2-Dumping is not correct.because for debugging we run application
in debug mode that TR=1,This will change ki and jump target will be
protected.

what about this algorithm?
do you think we can attack this one easily?

sincerely yours

I don't completely understand what you are saying here, you are quite unclear, but it seems you are still messing with the jumps and have also added tracing with the trace flag? This will still be all too slow if applied to larger portions of the program...

imho is MD5 overkill. you can detect breakpoints too using some way simpler hash algorithms.