reverse engineering

Bengi,

As i said earlier, i don't mind RE, if you want to crack my software, go for your life. My point earlier about the EULA was simply an answer to a previous post which stated that there was nothing legally wrong with reversing an application. I reckoned that if you forbid it in the eula, then you're denying people the right to reverse your app. But it seems i was wrong there, as a number of people have pointed out. I wasn't trying to suggest that reversing is *bad*, if that's what people want to do then fine. Everybody's got to have a hobby ...

I'm convinced that in general, the people who will search for a crack because they don't want to pay you $10 or whatever, would never have bought your software in the first place. So it's likely that in the majority of cases, you haven't really lost any custom.

Thats it ..

Jase seems to be understood my meaning.

BTW ,(to all) What good tools you know ?
I use SoftICE , PeBrowseDebugger , TRW2000 on 98 , IDA Disassembler , Win32DASM , Resource Viewer and almost everything from Sysintyernals , API spy , VC++ debugger , WinDBG (sometimes).

IF anybody has better tools let me know.I am freak of such tools.

HI,

To all SoftIce bashers. :-)

I dont think SoftIce can present C/C++ code to the user if the binary is built in release mode.

SoftIce works by deciphering debug symbols from the binary. It understands the debug symbol format as incorporated into the .exe or .dll by Microsoft VC, etc, and uses them alongwith the code base pointed to by the programmer, and helps him debug.

Binaries that are "Release" build donot have these symbols, and cannot be deciphered into exact code.

Yes, they can be presented as assembly, and they can probably also be interpreted into an approximate C/C++ code. But, getting the exact representation of the original code is not possible.

Any comments? :-)

Thanks,
Siddhartha

It's already discusssed , see previous post to this thread.

Siddhartha:
thats IDA's job =)

Hello All ...!!!
Interesting & impressive discussion is going on...A good thread to start with...My first post...!!!
Can anybody here tell me how to get SoftIce...? someone said that it is a freeware? is it? then please share a link so that all here may actually see what SoftIce is? and what is it capable of?

Thanks

It's not freeware friend , how it can be , it's worlds best debugger.

But you might find it cracked , and I recommand you to purchase it from NuMega , it deserves the cost.
If you dont want to purchase softICE now , then no problem , get started with VC++ debugger itself. Few Debuggers are realy free for download like w32dasm , PEBrowseDebugger etc. Main thing is you need to start studying the OS and it's working.

It's certainly not free, that;s for sure ...

http://www.compuware.com/products/devpartner/softice/

And seeing as it costs $800 , i'm surprised any crackers out there are able to use it. That is unless they steal it from somewhere.

Quote:

---

Originally posted by Krishnaa
But you might find it cracked , and I recommand you to purchase it from NuMega , it deserves the cost.

---

Did you pay $800 for it then Krishnaa ? I doubt it :)

As this begins to degenerate into a cracker discussion, this thread is closed now.

If someone has something valuable to add to this discussion -- i.e. something that hasn't already been stated and really adds value to this thread -- please send me a PM.

At the request of some users that participated to this thread, I will reopen it and let the discussion continue. Please keep following two things in mind:

- Discussing how to crack copyrighted software or how to obtain tools to do such activities is prohibited. Also, discussing ways on how to obtain any copyrighted data without paying for it is prohibited. I'm very serious.
- Please do not allow this thread to degenerate into a flamewar.

I do reopen this thread in the hope that it developes into a constructive discussion about software protection and debugging techniques.

Thanx Gabriel Pal !
I agree to you , nobody should start discussing how to crack...instead lets talk about understanding engg. concepts of Reverse Engineering and securing our software.

Okay, im glad we can continue this discussion.. thanks for reopening it.

From my experience the following can help:

1. Avoid commercial protection systems such as well known packers/distributors. Theres always a previously written unpacker available that even the most basic of users can work.

2. If youve got the knowledge try and customize your packing slightly yourself. Change headers etc. Another option is mess with your compilers advanced options. Theres a very good article by "Todd C. Wilson, Fresh Ground Software" where he developed a class called 'AgressiveOptimization'. Now this class not only pre-packs your exe on compilation, whilst it does it it also mixes up the PE table sections making it gibber when decompiled using WinDasm.

3. Remember that debugging using a tool such as Softice, Ollydbg or TRW2000 although all are excellent, become an absolute nightmware when the code starts spawning off threads. If you are going to develop a routine, why not have 10 threads, create a mutex, a bit of syncronization and let each thread take its turn in manipulating your registration data.

4. Custom structures can somtimes cause problems. Maybe try some of these?

5. You can hide string routines from the 'string ref' sections of WDasm simply by turning them from CStrings into char arrays and storing the ASCII value rather than the char itself.

6. Finally my last suggestion, and ive been meaning to actually get round to coding this is i am going to attempt to dump a section of the code out from my application to a seperate object. When the application is registered the missing data will be given to the user and the application will import the data chunk at runtime, sling it in memory and commence execution.

7. If you do generate registration codes, dont generate one when the use enters his name etc and then compare it to the fake register code he entered. Youve just done a favour for the cracker and shown him how to generate a real code. Instead, decrypt the code he entered and see if it matches his name and details.

8. When your comparing, avoid functions like CString.Compare. Intead do a char by char comparison or similar.

9. If you want, avoid common windows messages and API. Instead of using GetWindowText, use SendMessage(WM_GETTEXT).

10. Dont have a nice big display box saying.. 'Thanks for registering'. Move the code which verifies the regcode somewhere completely different, and delay in checking if they entered a valid one or not. You just end up giving the cracker an entry point into your app otherwise.

Just a few simple solutions to keep out the newer wannabe crackers.. coz lets face it youll never beat all of them out there ;)

Yaa , threaded code is hard for debuggers , but many debuggers have ability to trace EIP.
I believe that polymorphic code like encrypted functions with great use of JMP and changing few registers without purpose can secure the code much.

One more idea for securing the code from RE is to place the sensitive algorithms inside a VXD/Device Driver and pass the IOCTLS without many non-understandable arguments.
We can secure our memory area's from being dumped by debuggers like softICE by creating handles (logically) to them , the memory will be allocated by driver and a logical indexed handle will be given to Application , and application will manage all memory to be secured in such manner , memory can be acceses by sending IOCTL's.
A debugger can trap DeviceIoControl to know what mechanism is used to communicate with driver. I am working on finding a method to call the DeviceIoControl unnoticely , but not got better success. I got one solution to use DLL's without statically linking and without calling LoadLibrary and GetProcAddress. => We can find the function address without calling GetProcAddress and check whether the function is being spyed or whether it's modified , if not lets go modify EIP to call it , dont call it direcly using call or JMP , still i am improving that.

Do you have found better algorithms ?

A few recommendations :

1) Never follow your registration validation routines with a MessageBox("Valid/Invalid Key") type response. The cracker can breakpoint the message and find the validation routine very easily. A simple patch of a few bytes will probably render your algorithm useless. Try starting up a thread, and validate in there. You may then want to start a timer, post a message or spawn another thread. The response to the message or timer or new thread will be the result of the validation.

2) Never hardocde string into your code, as these can located in your code very easily. You don't even need softice, you can use notepad.

So ... instead of

Code:

---

CString sMessage = "Thanks for registering the software";

---

... Build up the string character by character. Like so :

Code:

---

CString sMessage = "";
sMessage+="T";
sMessage+="h";
sMessage+="a";
// etc

---

The message no longer appears in your binary. I recommend this approach with ALL sensitive messages which may help the cracker identify places in your code.

3) Do not go to the lengths of making your code completely unreadable to yourself, you will just make your life much harder, and your code will be harder to maintain. Providing you send out a release copy, the function names are NOT in there, no matter what anybody else might say.

So, there is no need to rename

Code:

---

bool m_bIsRegistered;

bool CMyClass::ValidateRegistrationNumber(int nNumber)

---

into

Code:

---

bool m_bShow Window;

bool CMyClass::TranslateParamaters(int nNumber)

---

It may seem like a good idea, but trust me. I did this and now some of my classes are horrible. If you want to know whether or not a symbol is available for the cracker to view, open up your exe in notepad and do a text find for the string, variable name, class name, function name or whatever. If you cannot find the text in the executable, then nor can the cracker. I mean, how could they if it's not there ?

Just some pointers. I'm certainly not an expert, but i believe these points are good advice.

One more thing, have fun :)