reverse engineering

Ok i may just be new to this fourm but i realized that meny of you dont seem to know much about protecting your programs. useing special coading like useing hex strings wont help you at all. the only proven methods that make it extreamly hard to extract coad is to check and see if some one is useing debugging api's probaly te best one to check is ReadProcessMemory or WriteProcessMemory as they allow them to look at your coad and modify it directly in memory very few hackers use c++ to hack a program. but thry do have to use these api's to make modifications to your program or to read what it is doing in memory. if you check and see if your porgram is being debugged then you have a greater chance that you will force them into useing a disasembler of some kind and you can throw those off by calling your fuctions useing global varables that temproaly store the adress of the function your about to call. cuppled with placing fake copys of your functions in memory.

using these methods will prevent all ametures from hacking your program but the pros who spend sevral hrous to sevral days will still get passed these.

btw. there are c/c++ decompilers but they are very hard to get ahold of and most hackers dont use them.

[edit]
oh i frogot another good mthod to use is to create an independant thread that checks to see if your program had been suspeded (paused/halted) and if so closes the program. i dont know if any of these methods work agenst softice but i'm almost sure that they will. as softive has to obey the same rules as any other program in windows.
[\edit]
[edit]
sorry i didnt read through the whole thread. i want to add that though there are c/c++ decompilers tehy dont keep variable names and such unless you compile them into your code ad debugging information. they will simply decompile working coad that is often ilegable without sevral hours of reading through it
[\edit]

Can anyone tell me where can I get SoftIce???

www.compuware.com

Why not just use windbg with two machines :) Granted SoFtIcE _legally_ costs hmm 1000.00 US somthing last time I looked well not really looked cause someone else pays those bills...

PS: when will this thread die? it's has far more disinformation than information...though maybe it will help in futher confusing the masses. It's good for a laugh though...

Quote:

---

Originally posted by briball

There is a defense against softice though, but I'm not sure it is this "MeltIce" since I can simply change file names. I accidently left it on (I have to restart to toggle it on or off) and tried to run a MS game. It "detected a debugger" and shut down. I never investigated, so your guess is as good as mine.

---

Perhaps...Age of Mythology... :) :) ;) that's just a guess at which game you were trying to play though...

Ha! That was a good guess of the game I was playing, just slightly off. It was Age of Empires II. If Age of Mythology does it as well then there is a new trend. I don't think it will be mainstream soon however.

Developing something for MS has its advantages I guess. Like access to the most sophisticated techniques to control Windows.

Anyway, SoftIce is useful for seeing what goes on in near real-time, but I have always used a dissassembler with it as well. Change some jmp or je commands in a hex editor and you bypass a password protection, etc. However, to figure out complex algorithms like this...Someone's better off just buying the information from you than spending so much time.

Original source is not and never was the point.

First, there is a distinct difference to Crackers and Hackers.

The former will almost ALWAYS work in assembler, and if softice is detected there is always w32dasm or IDA. Real Crackers are non destructive, the challenge is to find the best way to overcome a particular security system. The point is NOT free software. If you take the time to search the modern reverse sites, you will find tutorials for shareware/commercial proggers to help them make the security stronger. Softice IS the most powerful tool around at the moment, but certainly not the only one to use, for an experienced assembly progger, a dead listing (disassembly) is all thets needed, then a hex editor to patch. As stated before, nearly always the code is cracked then the software thrown away. The idea that crackers need to reverse just the simple code is ludicrous, many reversers are techs or proggers themselves, and after reversing a few harder pieces some of which can take weeks, it enebles you to go on and produce stronger code.

Hackers are mostly young, dumb and short of patience, these ones WILL give up after 10 minutes, but a cracker relishes reversing a tough protection scheme.

Finally, any code that runs on computers CAN be cracked, try a google search for clsid+pagemill or any such multi strings and you will start to get the picture. If you use C or C++ or VB using MS libs, then newbies will be able to open it in half an hour. Go seek the tutorials, for there are thousands and LEARN, don't fear them learn from them, and consider learning Assembler for your protection

Regards

eNkO:cool:

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:004ECD4B(C)
|
:004ECD54 FF75C0 push [ebp-40]

* Reference To: ADVAPI32.RegCloseKey, Ord:0117h
|
:004ECD57 FF154C005400 Call dword ptr [0054004C]
:004ECD5D 837DEC01 cmp dword ptr [ebp-14], 00000001
:004ECD61 0F85F3000000 jne 004ECE5A

* Possible StringData Ref from Data Obj ->"CLSID"
|
:004ECD67 68D4A95A00 push 005AA9D4
:004ECD6C 8D4DE0 lea ecx, dword ptr [ebp-20]

* Reference To: MFC42.Ordinal:0219, Ord:0219h
|
:004ECD6F E808220200 Call 0050EF7C
:004ECD74 8D45DC lea eax, dword ptr [ebp-24]
:004ECD77 C645FC03 mov [ebp-04], 03
:004ECD7B 50 push eax
:004ECD7C FF75E0 push [ebp-20]
:004ECD7F 53 push ebx
:004ECD80 FFD7 call edi
:004ECD82 33DB xor ebx, ebx
:004ECD84 3BC3 cmp eax, ebx
:004ECD86 7512 jne 004ECD9A
:004ECD88 8D45D8 lea eax, dword ptr [ebp-28]
:004ECD8B 50 push eax

* Possible StringData Ref from Data Obj ->"{6E996511-A3ED-11d1-B7B8-0060975AE13F}"
|
:004ECD8C 685CD85A00 push 005AD85C
:004ECD91 FF75DC push [ebp-24]

* Reference To: ADVAPI32.RegCreateKeyA, Ord:011Ah
|
:004ECD94 FF1534005400 Call dword ptr [00540034]

* Referenced by a (U)nconditional or (C)onditional Jump at Address:
|:004ECD86(C)
|
:004ECD9A FF75DC push [ebp-24]

moral here DONT use unencrypted strings in codee, this bit of code is part of a routine relating to wether or not this key exists in Win Registry, if it does the trial is over. You will notice the (C)onditional jump reference so we know where to go back to. A simpler approach would be to change CLSID to KLSID then the return is always false. This is not the only protection in this piece of software there is also the infamous 0013C680 (15 days in seconds Hex) plus a couple of others, but all laid bare by 'dead listing'

This is why code that is not at least somewhat polymorphic will never be safe. Once you've been reading assembly for some time, it is just as easy to understand as c++, and is shipped with the product! Polymorphic code cannot be statically disassembled, and with appropriate checksum tests and similar environment checks during the "unrolling" of the code, you can prevent direct cracking efforts. This leaves only virtual processor technology that can read execution path, and patching can be made a non-polynomial problem with proper interlocking security checks.

Quote:

---

Originally posted by Mick_2002
PS: when will this thread die? it's has far more disinformation than information...though maybe it will help in futher confusing the masses. It's good for a laugh though...

---

I completely agree. This thread has quite lifted my spirits, and I lift my spirits to it in toast for the good times to come... :)

More safe thing will be integration of a kernel mode Driver ,because many programmers dont have Kernel mode debugger.
A best aproach would include polymorphic functions to fool the disassembler + sensitive algorithms in device drivers + and threaded (APC from DD) way to call the entry points so that debugger just gets fooled.
Periodical code overwriting ,extracting encry. code in memory and then executing it etc. are also better ways to eliminate the cracking of code.

P.S. Wait for few days I will post a very goood sample on anticracking.(AntiDebugging and AntiDisassembling tech.)

Quote:

---

Originally posted by Krishnaa
More safe thing will be integration of a kernel mode Driver ,because many programmers dont have Kernel mode debugger.

---

Plenty of Kernel mode debuggers are just a download away. As are the symbols. As a matter of fact I believe windbg and the OS symbols ship on the support CD's.

Yaa ,but think you can have total code rewriting implemented in that too. It makes any debugger hard to simultaniously debug many threads in diff. rings.

I seen in this thread several times about detecting if the program is being debugged. How is this done? Someone mentioned that there was an API to tell if debug CPU flag was on.


Thanks
Doc

IsDebuggerPresent() is the API.

It is however a pretty pointless. You may be able to keep out some of the extreme newbie crackers with this, but it isnt exactly difficult to view the API dump in Wdasm and NOP it out or jump it.

You can even use something like sice or frogsice to trick it into thinking the debugger isnt there.

All thats been said is without a doubt true. Ive learned by looking at other code and one technique if come accross to prevent reverse engineering has stood out from the rest. I have found the some app's use the ReadProcessMemory() (a windows api func) to veryify that that people have not altered you code. Remember most if not all breakpoint will change the in process memory so if you compare a segment of code while its in memory you can prevent people from inject jmp statements by actually checking veryifying the in proc memory. Break pts are usually an injected "int 3" statement which causes an exception which your debugger will catch and then say hey look we reached a break pt.
So you should beable to prevent people from even puting bp's in critical sections of code and remember dissassembling is alot easier when you can step through a working model of the code

Disassembly really isn't that hard. A determined dis-assembler can easily subvert pretty much any protection scheme you can come up with. Speaking from personal experience, I have disassembled entire operating systems; I have traced through and disassembled encrypted code segments; I have disassembled code that attacks debuggers; I have succesfully disassembled self modifying code written to prevent disassembling. All not terribly hard to do.

Most code protection schemes are load time schemes. The easiest way to attack your code, I would imagine is to attach a debugger, catch a key event like WM_COMMAND, and then snapshot/dissassemble/debug from there. It's pretty hard to imagine anything you could do to hold off a determined reverse engineer for much more than an afternoon.

Unfortunately, anyone who has the skills required to dis-assemble large blocks of code will also have the skills needed to subvert your code protection scheme.

On the other hand, you're going to end up investing a huge effort re-creating linker/loader relocation, which you're going to lose as soon as you try to protect your code segment in the binary.

Not worth the effort. My advice: get a new boss. Any real boss with real code worth really protecting should understand immediately why this is a waste of time.