As this is the newbies forum, can someone give me direction as to where I can find good simple tutorials? Essays are nice and plentiful, but without a little beforehand knowledge you won't get as much from them... I have a decent knowledge of softice, assembly, and some of the processes involved in cracking. But I'm usually on the programming side of the assembly, so this 'cmp eax [esp+08]' type stuff is a little bit confusing.

It's sucks that the sandmans site is down, but it was hard to find a bunch of the older programs anyways, making it that much more difficult to learn from for a newbie.

I'm downloading essays as I type! So please don't harass me, I'll take a look at them in the morning when I can think clearer.

Thanks, matt.

/I have a Win2k machine, Driver Studio 2.5, masm, & a bunch of cracking-related tools/

BTW, can you dump screens from softice into a text file? Something that you could look at later and comment on? (I AM reading the manual, but if I can't find anything you guys are my backup

Hi matthew,

>>BTW, can you dump screens from softice into a text file?

Yes, you can dump screens using IceDump (more at http)icedump.tsx.org).

(maybe I would recommend you to use Win98 OS, because lot of newbies have problems with using SoftICE under Win2000, especialy with hmemcpy/memcpy breakpoint .

For essays you can visit ID archive; the link is at the bottom of the main page of this forum ;

Regards,
sF

Hello everyone.
I'm a newie too but more newbie than matthew is as I don't know a lot of assembly, softIce, etc.
My question is: can i hope to learn cracking without being a programmer?
If not should I learn assembly (it looks pretty hard IMHO) or any other suggested language?

I've read the famous +ORC tuts and they are interesting, nut boy they are really outdated; does any similar material (organic and complete tutorials) up to date exist ?

Thanks a lot for your attention
S. Holmes

P.S. Any other italian guys here? Italian scene seems a bit sleepy!

Some programming background is helpful, if just to know the general flow process of how programs work. It is not absolutely necessary however. Get a softice command reference and an API guide and study them.

As for simple tutorials, I have a few at qferret.cjb.net. I specifically chose programs that were easy enough for newbies, and wrote the tuts with newbies in mind. The programs shouldn't be too hard to find either.

Good luck and have fun.

Matthew, S.Holmes:

Unless you are reviewing a program compiled from a system that the debuggers don't translate into assembly language you are going to need some basic understanding of assembly, simply because that is the language that you use to "read" the disassembly of the code from its "higher" programming language. With some exceptions, not necessary relevant, here you don't get "source" code to look at, only assembly.

Among the thing you have to have some general understanding about is the register system of the PC world and how information in moved into and out of these registers as it is processed by the operating system. Programming skill is useful when you want to patch or change code, but even if you don't do that, you still need a general understanding of what the assembly is telling you the program is doing as it works its way through the author's code.

As an example from Matthew's post, if you don't know what the ax register is, or even about 16 bit or 32 bit registers (and now maybe even 64 bit) or where it is shown in the softice output or what esp+8 means, and what it means to set a flag after a compare, you can't very well look at a data or other windows in softice with much understanding of what you're looking at or what might happen after the compare is made or the assembly opcode executes. Without some of this basic knowledge, you are more limited to attempting to follow, line by line only, somebody's tutorial without actually having much grasp of what the author was talking about and unable to use the information very well if the version number of a target has changed and the information you were looking for is now at a different address.

As ?ferret said, the softice reference has some basic information about the registers and how they work and these general concepts. Its available everywhere. Another great source for assembly information is, of course

http://spiff.tripnet.se/~iczelion/

and there are several other masters of this art whose works and sites are discussed in other posts. Iczelion's site has tutorials and source code also and is working.

There are also many articles, some mentioned here in other threads, found through the search button, discussing softice and breakpoints, and on the fravia site on the Links at the bottom of the forum.

It's like anything else you learned in school or anywhere. Certain basic concepts are necessary to understand the art, but they shouldn't be beyond the grasp of anyone who wants to make the effort and is willing to do some work. We don't just wake up one morning and start speaking and understanding assembly language. If you show that you have made an effort and are having trouble, someone here likely can and will help.

But there are still many things that can be learned from tutorials, that have little to do with "how do I crack program X v 123." Pay attention to how various programers provide for the registration of their program and where they hide the information after it is registered. Is it in the win register or a file on the HD? Do you know the tools that permit you to find out what is being registered and where? Do you know what files a program is writing to your HD and where? What are the tutorials telling you that this company is using as their methods, because maybe (and maybe not) the next version will use the same system or one you read about in a tutorial about another product.

If you really want to LEARN about RCE, keep notes and store things in an organized system on your HD or other media. You could keep tutorials on programs that use Asprotect, for example, in one place and then you can study the evolution of the protection and the methods of attack used by those with more experience and skill than your current level. In short, make it a LEARNING PROCESS, not just an attack on one program or another. Using your brain is, of cource, the best tool and the essential one in the process and you can approach this as an exercise in trying to out think the original programmer. Since a great many of the programs that are cracked are of little or not much vaule to most people, it is this intellectual challenge that the game is really all about. Lucky for us that it is generally a great deal easier, but not necessarily easy, to circumvent a protection system than it is to create a good program itself.

Regards.

Matthew, S.Holmes

From a Newbie, some advice, since it's free you may ignore it, or you may profit from it.

1. Using a disassembler (IDA preferred, or W32dasm fast, easy, not as powerfull as IDA) to create a DL (Dead Listing) most times is easire than using SICE at least for me!

2. Minimal programming experiece is required, ie do you know how a jump works ( go to statement ), do you know what hex is? ETC.

3. What is actually more important (my opinion only) is to know how the code works ie (a piece of software that you use day in and day out). You will understand the error messages when you screw up something, and if the data is mangled you will immediately know.

4. Tutorials,the simple advice, read as many as you can get your hands on. Unfortunately the ++Crackz++ site is history (I thought it was the best) you can try the fravia site.

5. Operating systems best one for cracking is 98SE, everything seems to work on it. (Yes I know it's not very stable but those are the breaks).

I would suggest for you to pick a first target, then search for tutorials on it (even old versions), FYI most authors/companies never update their protection schemes (except for the big ones ie Micro$oft, Autodesk etc). I actually find shareware significantly more difficult to manipulate than dongle software, so beware!

Good Luck
MTB

+Sandman has reported that his site closed a couple of days ago, but that doesn't mean that his tutorials are not available. A little quick searching with

sandman+crack*

led to this site

http://cgi.t35.com/digitalhack/textfiles.htm

which had a zip file of 55 +Sandman tutorials and numerous assembly language text files, including a primer and other basic documents. They're near the bottom. Check it out and keep searching. There's likely a +Sandman mirror out there with nearly everything from his site. Another example, Krobar's site has tutorials 1-74, and a whole bunch of other sites essays. There's some great assembly materials in the +Greythorne essays. It also has the Softice Manual, Reference, and quickstart guides,

Regards.

I really appreciate your help!
It's nice to see that in the web places where people is willing to help still exist. It's not always the same in real life .

JMI : I came here after learning a lot of things from Fravia's wonderful lore on searching the internet. Then I learned that Fravia had an old frozen site realting to the art of cracking and then i digged my way till here!
PC is my hobby and in my mind there is nothing worst than using something that appears to your mind as a black incomprehensible box. That's how I deal with my studies, with my life, etc.
So I will certainly follow your advice and I already began downloading tutorials, guides, howtos, etc. If I dont understand them now they will come handy in the future (I hope).
I will probably not have many hours to dedicate to RCE so I don't hope to become a good cracker, but i would like to learn as much as i can, relatively to the time real life graciously give me.
If I understood well my way should be:
1) Assembly and registers
2) How to use the "tools of the trade"
3) Then experimenting with as many tuts as i can.
This seems interesting; I hope I'll be able to do it


?ferret: thank you for the link to your site; many many interesting things there. I already have found all the tools and many tuts.

MTB : LOL I use WIN98SE and I wouldn't change it for WinXP neither if Bill would send it to me free of charge for Christmas. I don't know but it looks like a sort of trap for the mind to me. They really want you not to undestand how your puter works... sad ....

May I ask here a question about SoftIce or am I off topic? I saw a section for the tools so I think I should post there (Ok, I manipulated the dat file for entering the exact amount of RAM I have as told from Sandman in his tut Softice for beginners - 512M - and after restarting PC crashed : not enough memory to initialize Vcache on a ugly blue screen; booted again in ****mode (don't know in english, when it loads the minimum, provisory ?? :P) changed the amount to 32M and afterwards everything ok, why??)

Again thanks to everyone for your help.
S.Holmes

SoftIce inconvenient already solved with the SEARCH function.
Sorry
S. Holmes

S.Holmes:

Now you see what I mean when I advise people to try the search button before they post a question. Just wanted to reply to some of the points of your reply so that my previous post doesn't confuse the issue too much.

You don't actually need to have a detailed grasp on how to code in assembly to learn how to reverse the code that someone else has written. I'm not advocating that you don't learn some coding skills, but only saying that what you need for reversing is at least a basic understanding of the assembly operation codes so that you understand what the program is doing, even if you are not sure exactly why. By this I mean, as an example, that you understand when an instruction is fetching 2 bytes from a memory address, or adding what is in one of the registers to what is in another register or at some memory address, or whatever is happening. These are just examples of things that happen in the stepping through the code or in looking at a dead listing. The goal is understanding at least WHAT is happening, the WHY is a bonus.

For example, the code may compare a serial number you have entered in a dialogue box with some coded number in memory or one actually in the code without encryption. It may process what you entered and that routine which processes the entry might have to pass through a routine that give a mathamatical result that says it is a "good boy" or "bad boy." You need a general understanding of what the code is actually doing to what you entered if you want to try to actually get a valid registration code. Maybe you can find a simple "good boy vs. bad boy" jump and change the condition of the jump from a jump only if a certain condition is found to always jump, but these simple protections are not as often found, or not as obviously, in the more difficult programs.

You may learn how to change the text of a box to display that it is registered but you might not actually have converted it into a fully functional program, or the full code may not actually be there, and the program is "crippled" and can't be made into a full working copy.

Many programs are packed, either by the compiler or some protectionists product. You need to have a general understanding of how to manually unpack or you are at the mercy of those who make unpackers and protectors, and they are in a constant race to make small modifications to their stuff to get around the others latest trick. +SplAj and others with vast experience make it look easy, but part of that is based on knowing how the code and the packing/unpacking has to work.

Again, simply as an example, a win program generally uses some of the API to call various defined sections of code to do things like open windows and place buttons. Things that you don't have to re-invent each time. References to these things are generally found in what's called the import table and, by definition, they should be placed at a certain spot in the code of a PE. Many of the protectors try to hide, mangle or otherwise mess with this import table so that if you are able to look at or dump the code from memory it doesn't make sense or doesn't lead to where it appears it should go.

But I believe it to be true to say that the code can't actually run in an encrypted state and a re-directed, or re-re-directed import table has to eventually lead back to the correct spot in the API or the windows won't draw correctly or the buttons that are supposed to work, don't work. This is what programs like revirgin attempt to do for us, find the right address without the mess added by the protectionist.

The protectors try to keep you from looking at the code because they know that if you can look at the code and study it long enough, you can figure out their protection, if you understand WHAT you are looking at. That's why they try to detect and blow-up the debugger code and why programs have been constructed by people who really, really, really know how to code in assembly to try to hide softice from the people who want to make it crash. (Thanks Owl)

So if you learn how to unpack, or use an unpacker, the protection may include changes in the original code to make the program crash without the protection in memory or because of the protections changes. Again you need to understand what the debugger is showing you when the crash occurs and where, so you can go there and look at the code and try to figure out how to change it so it doesn't crash there anymore and then look for the next problem. All these things require you to know what the code is doing at the spot you are looking at, but again you don't necessarily have to know WHY the programmer or the compiler chose to put that code at that spot, just that it has to be fixed to run "correctly."

This is a very simple overview of some issues that get very complicated, but the bottom line is that if you don't begin to understand WHAT the code is trying to do at the spot you look at it, you are not likely to make much progress in reversing. These are the kinds of things you can learn from the tuts even without the program to try it on. What code did the author attack and what changes did the author make and what was the result to the code, not just the program. Sometimes it doesn't make a lot of sense as you first read it, but after you read more you will realize that you have seen alot of the same stuff before and begin to recognize patterns of attacks and techniques to try yourself. As I said, its a learning process and it should be ongoing.

Keep searching and keep studying and when you have specific questions, come ask someone here to help, but say what you have done and where you are stuck or confused and likely you will find the help you need. I'm still spending a great deal more time studying the art than practicing it, simply because I want to understand WHAT I'm doing, not just doing, step by step, what someone else layed out for me in a tutorial. I try to figure out the WHY of what worked, so the next version of the program, with code in different places or different methods is a challenge, but not impossible.

Regards.

For anyone just starting out you will find a good collection of information on the Krobar Tutorial Collection site. It has a good section titled "Begin" which has many, many tutorials and reference materials gathered from other sites for one to review. It has several good references on assembly language for the beginner. The entire beginners section, of 9.6 mb can also be downloaded as a single zip file or you can download the individual reference materials or tutorials.

There is also a section which has collected groups of tutorials from many places on the web, many of which have had their individual sites closed now. While it isn't the only such collection, it is extensive. I believe the entire collection is now over 100 MB.

There should be enough information there to give anyone a good start and lots of reading material. It's at:

http://www.krobar.cjb.net

Regards.

++ to Krobar collection from me too..
I have benefited a lot from those..



HAVE A NICE TIME CRACKING