???

I have downloaded and viewed many tutorials on cracking/reverse code engineering.

Unfortunately, I found that MOST of the tutorials were difficult to follow ??? because the authors did not provide DETAILS as to WHY they chose to do this or that!

An example of a common "mistake" by the authors is that they say you should set a 'breakpoint' (using SoftIce or similar debugger) using "whatever"; but how did they know which "whatever" to use as the breakpoint (there are MANY breakpoints to select from)!?
The authors should have explained WHY they chose "whatever" as their breakpoint.

Another common "mistake" is that the authors say you display the contents of a register at this location in the program to give you the serial number. How did they know WHERE in the program the serial number is??
Again the authors should have explained WHY and HOW they were able to determine the correct location in the program to get the serial number!

I would estimate at least 80% (yes, eighty percent) of tutorials make the above or similar "mistakes". These tutorials are then nothing more than brief notes on what the author did, and NO ONE can really learn from these so called "tutorials" except how NOT to write tutorials.

The point I am making is that tutorial writers should make the effort to explain clearly WHY they did things the way they did. THEN the 'notes' become a proper tutorial on cracking.

I pity the Newbies out there trying to learn from such tutorials, it would probably be a nightmare for them to understand what is going on.
Actually I believe it would also be difficult for experienced crackers to understand as well!!

Bottom line:-

PEOPLE WRITING TUTORIALS MAKE THE EFFORT TO EXPLAIN YOUR DECISIONS SO THAT ALL CAN UNDERSTAND WHAT IS GOING ON!!

Well, some ASM knowledge is essential to understand what's going on in the code. There are certain API's that are almost assuredly used for certain things. If there is something out of the "norm" going on, it usually gets explained.

For say example, serial protections.....GetWindowText, GetWindowTextA, GetDlgItemText, or GetDlgItemTextA will almost assuredly be used, unless the author codes his own routine (or uses VB,Delphi, etc.). This gives you only 2 options to choose from (with the "A" at the end for 32 bit apps, w/o the "A" for 16 bit). Why write this over and over in every tutorial ever written?

If there is a line like CMP ESI, EDI after a string reference to "Thank you for registering..." in the disassembly, of course you're gonna chyeck those registers when you step through.

You say you've gone through many tutorials....look for patterns, I'll bet if you think about it you'll find that you actually HAVE learned a few things by repetition....if the proggy does this, I could try this/with this style of scheme, I should try this approach, etc..

I guess one option would be to hire quality assurance staff and begin charging $15 per tutorial to offset the cost of their wages ;-)

hmm... what about ebliss.cjb.net
I try writing my tuts just enough to learn how to do it but complex enough to make you think at the same time. Also, there is a zip file there called resource.zip which contains the tuts and info that I needed when I first started.

Hi Pusspuss,

For the most part, tut authors do good work. Most of them are advanced reversers that take time to write tuts that help us newbies get a grip on reversing. Nice of them. Since they don't write tuts for a living and many are new to the English language, I am happy to gleen what I can from the tut and thank them for their efforts.

As for details...yes, there are many breakpoints to choose from in SoftIce. Only six or seven of them are used by reversers. How to know which one to set? I try every one that I know. Sometimes the magic works and sometimes not. Other reversers make educated guesses, even the big boys. In the tut they don't tell you all of the sets that didn't work. (And, some just know which set works?) Same with displaying contents of a register. Display forty of them until the secret number appears. Guessing what the programmer has done is not real efficient, but interesting. Efficient is... go to a warez page.

We are lucky here on the RCE message board. If you are realy having problems with a tut. Write to the board, in detail, what you have done to reverse the program and where you need help. You will always find someone to give you direction. Sometimes even the tut author will help you with direction and modify the tut to clear up unclear sections.

Anyway, hang in there and have fun with reversing.

Regards, Kugi

Dont take it personally
But nowadays people want to crack even they dont know how to program... If you knew how to program (especially at the API level)
You would not say those things....

I have even seen people who DID crack some CD-checks but asking questions like "Heyy what the hell does this <rep movsd> instruction do ?"

1st step to be a good cracker/hacker:
learn how to write good programs

I have learned a lot of things from Fravia's site...
But that was after i have written a bunch of programs in assembly under DOS...

Thanks to people who have responded so far! 8)

I am reluctant to say which are good and bad tutorials; however, since people have asked and to give people the idea of what are good and bad tutorials I list the following tuts -

Tutorials by The Sandman are generally quite good because details of WHY this was done are usually included.

The tKc compilation tutorials are a mixture of good and bad tutorials, with the majority of them being bad (because they don't explain why they chose to do this or why they chose not to do that).

ArthaXerXes , I had a quick look at your 'mastering the art' tutorials and found them to be quite good and reasonably clear and detailed; certainly better than most other tutorials!

Eternal Bliss , I had a quick look at a few of your tutorials (I hadn't downloaded them previously) and found them to be better than most tutorials; although in some tuts (#25 for example) the reason for selecting SI breakpoints wasn't explained.

?ferret . I disagree with your post. Tutorials are, or are supposed to be, written to teach! In order to teach, the tutorial has to supply sufficient information to the reader to enable that reader to understand what is going on. And to help the reader understand, the reasoning or logic behind the tutorial author's chosen cracking method should be clearly explained, regardless of whether the program/protection is standard or complex.
That means that the choice of breakpoints for debuggers should be explained for ALL programs (because you cannot use same breakpoint on all programs due to variations in program codes and protections). And an explanation as to WHY the author's think that a certain piece of code (or memory location) has the answer (serial number or code) to enable the program to be cracked; (a lot of tutorials do NOT explain HOW the author has determined a piece of code/memory location has the "crack"!!).
Holding back on some details such as the reasoning behind doing a certain cracking technique will, and does, make it difficult for others to understand what is going on.

It only takes about a minute or so for the tutorial author's to state something like - "I chose to use this breakpoint because ...blah blah blah.."; and - "the serial number is in register EAX here because ..blah blah blah..".

I am aware that you have to have a "feeling" when cracking programs, but you must also have a solid foundation in understanding the logic in making decisions on how to crack a particular program.

I do agree that people with programming experience, especially in ASM, will have considerable advantage over those who don't have such experience in cracking programs.

Malkocoglu . I disagree with your post also. I have some programming and ASM knowledge, but that still does NOT enable me to understand the process/logical thought the tutorial author's have followed in their cracking procedure and in their choice of breakpoints, memory locations etc.

That's it for now! ???

Greetings to all.

It really saddens me when I read posts such as this, since it strikes at the heart of any of us who have ever attempted to write tutorials or pass on something in the hope someone will find it useful.

I wonder actually if the problem isn't just one of over supply, so many tutorials, so much information, so many sites to swim, so many forums, and then I examine my e-mails over the last 6 months and I wonder what proportion of people actually ever take in the basics or even come prepared to learn.....

Its a 2 way process, between tutorial user and author.....

and so, 5 years down the line and somewhat wiser, dare I say now that I believe most tutorials to be something of a redundant resource, there is enough on the web now for anyone new to learn and the only information that really stays is that which you acquire yourself.

There is little point in my opinion having web sites publishing trite repetitions on the core protection themes for which there are hundreds (if not thousands) of existing tutorials, I think many others before me have made this point. The only new resources should be target unspecific and discuss new protections, in my mind if you write a tutorial where the target has to be known, its probably not worth much ;-).

My 2c and some.

Regards to all tutorial authors and readers alike ;-).

CrackZ.

The issue is about the QUALITY or CONTENT of tutorials, not the quantity.

I do appreciate and congratulate the tutorial author's that have made some effort to write the tutorials in the first place. Without tutorials it would be extremely difficult to learn cracking techniques.

However, many authors should have, perhaps, put themselves in the position of the people reading their tutorials. And then ask themselves, is the information within the tutorial sufficient to be understood?

Fortunately, some authors appear to have done just that, and consequently there are some QUALITY tutorials out there. Unfortunately, those tutorials are sometimes hard to find.

I have read on various forums that beginners/newbies were complaining that they couldn't understand some tutorials. Sure, it could be that the newbies are just unable to understand the tutorials because of just the way the readers are as a person. Then again, it could perhaps be due to poorly written tutorials (lack of, and/or incomprehensible information)?

I believe there is still a place for QUALITY tutorials.

That's my 3cents worth! ???

Feel the difference between "How to crack in common" and "How to crack this program/protection". If author writes tutor to cracking some hard protection like ASPack/ASProtect, don't ask him "Why you use bpm 12345 instead of bpx GetDlgItemText". Some of this "easy", but not understandable things are results of many-hours tracing in SIce, daily reading of disassembler listings and so forth.
But, IMHO, if you are to crack easy protection, there is no need to read CRACKING tuts, it's enough to read win32 api docs. If you wanna crack some really protected programms, you must be smart enough to write tutors WITHOUT reading any of them.
learn to think, not to crack.
WBR, //Nike

Strongly disagree!

ALL tutorials should be written in some detail REGARDLESS of how simple or complex a programs protection is!

A tutorial is a tutorial!! It is meant to be a teaching tool!

The tutorial author could be the the smartest/cleverest cracker in the world; BUT, the author when writing the tutorial MUST allow for people who are not as smart as him/her reading the tutorials.
That means the author should make an effort to explain their choices/reasoning. All they have to do is add, perhaps, one sentence explaining their choices.
That is not asking much is it?

If authors deliberately leave out some detail or explanation of their cracking procedure, then that tutorial becomes unnecessarily difficult for (some) readers to understand.

It is all very well reading the Win32API doc's, but that does not explain how you CHOOSE and APPLY the appropriate cracking tools to the program being cracked!

This is where the tutorials can be of considerable help to people learning to use the cracking tools. With (detailed) tutorials, the time spent learning the cracking tools and cracking procedures will be short for most people.

I dunno,

pusspuss... actually I'm not an tutorial writer but I read quite a lot... I just drop my 2cts in here because you seem to be angry that no one explains you the use of "our" cracking tools...
Would you really want to read over and over again how to use FileInfo on your packed exe? Wouldn't it be easier for every user to "rtfm" of every tool?

For the explications of the bpx's:
Would it be really necessary to explain why someone would bpx on GetDlgItemTextA? Isn't it normal to expect a little bit of common sense as it's really not that hard to read between the lines : GetDlgItemTextA -> maybe to get some text out of an Item in a Dialog?

Do not forget that these people are offering their wisdom for free!
& that Tutorial writing is actually damn hard...

JimmyClif
High Five To all Tut. Writers.

Hi pusspuss...

I'm reading this and i must say i agree a little bit with you.
I've seen also quite some tuts and most of them (but absolutely not all) are very short and quick explained.
Some of those tuts just go straight to the solution and you won't learn much from it but...

You must also realize that most authors of these tuts don't have much time or don't want to put too much time in it, because they want to do other stuff...

I'm also writing tuts and i try to explain it very detailed, if you want to read some contact me and tell me if they really are helpfull.

Now i don't think i have more to say except keep reading tutorials, you will learn a lot of them even if they are small and bad explained.
You'll learn something from them, its just they keep repeating the same kind of stuff and that stuff will get into your head without knowing it...

Anyway im off now so good luck with everything and keep on reading...

Cya...

CoDe_InSiDe

JimmyClif .

rtfm = Read The F*****g Manual ?

Reading manuals or doc's are one of the first things I do pal!! Sure the manuals/doc's may explain the functions of the cracking tool in question, but is unlikely to explain HOW to APPLY those functions in practical cracking situations!

Breakpoint descriptions such as "GetDlgItemTextA" are reasonably obvious. The problem is that a SPECIFIC breakpoint (such as GetDlgItemTextA) may not work on a particular program, due to the programs coding. The breakpoint selection based on it's description may be obvious, but MAY NOT necessarily work!

The only thing I agree with your post is that tutorial writers are doing it for free, and that writing (good) tutorials is difficult.

What is clear to the tutorial authors may not be clear to readers!

OK pal!?

CoDe_InSiDe

Basically I agree with what you have said.

One will usually learn SOMETHING from all tutorials, even bad ones.

However, it would be nice if author's made just a bit more effort to clarify their thoughts and selections. This will make it easier and quicker for readers to understand their tutorials.

In some cases tutorials are NOT understandable when authors do not include sufficient detail! This is the issue!

Cheers.

LOL... hehehe... I don't read every manual... I still have the original "How to use MS-DOS" book lying somewhere around here - unread... (I guess it's too late for that one anyways now )



Yep, this happens! A good example I know of is an email client called 'TheBat' - I was getting nuts searching for a good breakpoint until someone pointed me to http://beam.to/blackb 's page where he found the backdoor called SendMessageA (If I remember right) ... Anyway, what I want to say is that if you check the imported functions you always find one to compensate another.



Well, a good tip I can give is to try cracking it yourself first, and peeking sometimes in the tut when you're really stuck... & that way things clear up way faster compared to any step by step followed essai.

ok ?!dude?! ;D

JimmyClif "the lean, mean patching machine"

Hi pusspuss,

I can't say I haven't felt the frustration you describe at one time or another ;-)

Though this may sound kinda funny, I've found that its sometimes necessary to "reverse" the reversing tut. Poorly written or no, there are always clues within which you may reverse and research to gain a deeper understanding... Not to get too philosophical here, but IMHO reversing occurs on more than one level...LOL

Likewise, cracking and reversing take a *lot* of effort and dedication especially if you aren't coming from a programming background. From personal experience, I've found that researching the *why* is at least as important as knowing *how* it was done. Though quite tedious at times, it will pay off exponentially in time saved in the future.

...A couple of things that have increased my understanding of cracking / reversing in general.

1) When I began reversing, I had a *little* dos asm experience, but no asm experience with windows. After a time I realized, how can I attack a window's program if I don't even know how a window is created? ...how can I enable a disabled menu function if I don't know how a menu is created? Sure, I could memorize a couple of common breakpoints and cross my fingers hoping they would work...but my reversing skills were basically at a stand still until I realized the necessity of learning at least the rudiments of win32asm programming. After working through

Hi pusspuss,

I can't say I haven't felt the frustration you describe at one time or another ;-)

Though this may sound kinda funny, I've found that its sometimes necessary to "reverse" the reversing tut. Poorly written or no, there are always clues within which you may reverse and research to gain a deeper understanding... Not to get too philosophical here, but IMHO reversing occurs on more than one level...LOL

Likewise, cracking and reversing take a *lot* of effort and dedication especially if you aren't coming from a programming background. From personal experience, I've found that researching the *why* is at least as important as knowing *how* it was done. Though quite tedious at times, it will pay off exponentially in time saved in the future.

...A couple of things that have increased my understanding of cracking / reversing in general.

1) When I began reversing, I had a *little* dos asm experience, but no asm experience with windows. After a time I realized, how can I attack a windows program if I don't even know how a window is created? ...how can I enable a disabled menu function if I don't know how a menu is created? Sure, I could memorize a couple of common breakpoints and cross my fingers hoping they would work...but my reversing skills were basically at a stand still until I realized the necessity of learning at least the rudiments of win32asm programming. After working through a good number of Iczelion's excellent tuts (win32asm.cjb.net) I found things starting to make a lot more sense. I'm still no guru at win32asm programming, but my research has at least enabled me to get a general idea of how windows API's work together in a program for windows creation / text input / menu definitions / mouse input....ect. IMO, this helped a *lot* in figuring out where to attack programs.

2) Like I think Jimmy Clif already mentioned, setting breakpoints is not a lucky shot in the dark. Once again there are clues ...and even a sort of procedure to it. First, check all of the imports in Wdasm. This will tell you which API's the program uses for a process like text retrieval (ie. you can clearly see whether it is going to be GetDlgItemTextA or GetWindowTextA ) before you ever fire up Sice. Secondly, consult an API monitor...(Kayaker sold me on this one a while ago) This will not only show you which functions are called, but the order in which they are called (take the imported functions you're interested in from Wdasm and plop them right into the moniter). This helps to build up a picure of the code flow and can help you determine if for example a back trace range will be useful to you.

3) Of course, getting a win32 API reference is a *must*. If you're like me, you'll have to look up some of the imported functions to determine if they'll be useful.

Well, there's my 2 cents (and some more)

Cheers,
Clandestiny

sorry about that...somehow I got trigger happy and hit post before I had finished...

--Clandestiny

Clandestiny

Thanks for your comments; they are noted.

Just for your information -
I usually do check the API calls made, by using W32Dasm (program code permitting).

And I have the Win32API reference as well.

The use of an API monitor is a GOOD idea; I haven't got that yet!! I will chase that one up!

Cheers!

When reading a tutorial are you really willing to work/learn something on your own or are you just a lazy bastard who only wants to 'consume' ready made information?

Luke

Real constructive post LUKE !!!

WTF kind of a post is that, you p***k!

Of course I am willing to learn! And I can pick things up fairly quickly.

How the F**K can I learn something if the information is NOT there to begin with!!??

Maybe you can, but I can't read minds!!??

Please, the both of you, I just want this messageboard to be a place
of positive and constructive conversations around here.
So don't use such words, stay polite and everything will be ok.
People coming here are looking/giving knowledge, not personal opinions
or attacks at someone. So stay polite, please.

I'll just write a few words, my essays were not criticized here, but had a lot of critics during the past, especially for the most complicated ones.
Some essays can take a lot of time to write for the author, who is deeply involved with the target, making him sometimes hard to understand.

I have an easy way to correct this for future ones, you just start a
thread an upload you first essay, asking for people for critics,
then you correct it and upload again,etc...

When it's ready, you send it to be published, just like the beta versions.

regards,

+Tsehp

+Tsehp

My apologies for my outburst, but that "Luke" guy should be careful about what he posts.

I agree that CONSTRUCTIVE posts (without swearing) should be the way to go!

In the future I will try to be more tolerant of similar "non-constructive" posts.

Cheers.

OK - I have to get my licks in here also. I generally agree with pusspuss. I feel the problem is that a good RCE'r is not necessarily a good author. Writing *anything* is a talent. Writing a tutorial is even more difficult. Add that many of the tuts are written by people whose prime language is NOT english and you add to the difficulty. To answer the poster who asked if one would want to see an explanation on the use of filemon in ebery tut - if necessary, yes or at least a link to the relevant docs. If I'm familiar with the program, I can skip it but if I'm not and there's no help there, I'm stuck.
If I understand pusspuss' complpaint, it's not about simple "how to crack x program" tuts but more about learning generalized methods of attacking any target.
I DO wish to thank ANYBODY that takes the time to write a tut, good OR bad - at least you cared enough to share. If you see enough positive criticism, such as pusspuss, you will learn to express your knowledge in a manner easier for beginners to follow.

BTW, some tuts are clearly marked ()advanced. Those should be given a little slack. If a beginner reads an advanced tut and understand it either it isn't advanced or he IS.

Anyhow, that's my take on the issue.

vgb

vgb

Excellent post!!

Basically you have stated what I have been trying to say all along!

I hope that tutorial writers take note of your post!

Cheers. :-)

pusspuss

Yes, exactly, if this get to attack someone personnaly, just ignore it
and move to another topic. thanks to understand,
best regards pusspuss

hrmm...anyone else getting sick of the bold :P

pusspuss have you ever written a tutorial? i say this because if you havent then you dont know how hard it is to 'forget' everything you have learnt, and pretend you are a newbie again. cracking knowledge is usually hard-won, its a mixture of practise, reading(books tutorials), practise and time, therefore not many advanced crackers can easily put themselves in the readers shoes. it is a skill not all can master and frankly not many have time for.

you should be happy that at this point in time, there seems to be an enourmous ammount of information on crackign and reverse engineering related subjects all over the net, newsgroups and IRC.

i think your problem may be that you dont know how to search or 'sift' through the virtual data. i think that is one of the key hardship that crackers (young or old) find themselves with...

i started reading about cracking at approx 93/94 and since then i have acomplished much. i never had any qualms about any tutorials at that time (the quality has increased a hundred fold) and still dont.

read, study, and do *your* part as the reader in actually putting the knowledge learnt from tutorials in the real world. most of all practise.

each tutorial is a potential gem, but you wont see its worth until you read between the lines. understand dont just blindly follow like a coding sheep...

ehem, i seem to have said pretty all the money i have atm

NchantA