Hi all,

I am currently a student (actually just finished highschool ) and I was wondering how you guys managed to become 'pro's' at reverse engineering.
I too want to be able to reverse engineer programs.I have managed to successfully reverse engineer programs that require simple dongle checks or registration checks, but I feel as if I do not understand fully what is actually going on.

So my question(s) are.....

When did you start cracking?
Did you have previous knowledge in other programming languages ( if so, what were they? And did it help?)
Did you start off with simple programs or the advanced stuff?
How did you guys get good at reading assembly?
Finally, are there any resources or tips that you would recommend to a beginner? If so what would they be?

Many thanks!

Alright!

Here goes...

1. When did you start cracking? - (When I opened my eyes. My first words were not Mama or Papa. They were IDA PRO and ICE) -- just kidding. I began when I was around 26.

2. Did you have previous knowledge in other programming languages ( if so, what were they? And did it help?) - C and FORTRAN. Helped, well, not really. Or didn't you hear - "writing" a program and "reading" a program are two different skills.

3. Did you start off with simple programs or the advanced stuff? - Started with ORC's tuts, Win95, SoftICE, W32dasm and worked the way up.

4. How did you guys get good at reading assembly? - Habit.

5. Finally, are there any resources or tips that you would recommend to a beginner? If so what would they be? - Two pro tips: a) Start with the historically "older" stuff, work up to "newer" stuff as you get experience and b) Understand how to work your "tools" blindfolded, and ensure you cover their entire "surface area of capabilities" "before" you begin even "thinking" of hitting the apps.

Finally, a tip that will help you break impossibles at higher levels in the far future... "Just because something is, doesn't mean it should be."

Have Phun

Howdy,

When did you start cracking. Shit, 97/98 for programs. I think I was born a reality cracka.
Did you have previous knowledge in other programming languages ( if so, what were they? And did it help?)I had none at all. My biggest mistake was not keeping up with all the changes. The languages evolved and I did not.
Did you start off with simple programs or the advanced stuff? Simple, simple, simple. Always remember KISS, Keep It Simple Stupid. Once you have somewhat mastered what you are currently on, then move to the next. A great tip above, learn one tool inside and out before you start with others. Same for languages.
How did you guys get good at reading assembly? You have to keep current with the latest stuff to STAY good. You cant get good without the basics. Read all you can and see it in the code. Once you have seen enough it will become almost second nature. Until they change it.
Finally, are there any resources or tips that you would recommend to a beginner? If so what would they be? Master the tools while you work with tuts. Dont just follow the tut, understand what the programmer was trying to do when it was written. Once you start to see code schemes and stunts to obfuscate, and see them with very little effort, perhaps you will be ready.

It is always great to hear from the professionals.
I am currently writing programs in c++ and then viewing the assembly. However I just struggle to wrap my head around assembly code.

Also bypassing the the anti-debugging techniques are a pain!

Did the programs during the 90s just use simple checks for authentication or where they quite sophisticated.e.g encryption,anti-debugging?

Also Woodmann how did you manage to get pass anti-debugging techniques without writing code?

Currently I have no idea how to get past a certain programs anti-debugging techniques even though I can see they are being called for e.g DbgBreakPoinUI and may more.
Is there any good TestMe programs that have anti-debugging techniques you need to bypass?

anti debugging is twin of debugging both were born at the same time live their life opposing each other and will never die
to write code you don't need to reverse engineer (all the bloatware belong to this category)
to reverse engineer you don't have to write code they are mutually exclusive skills
(all the cracks and keygens in kilobyte footprint for a terabyte software belong to this category)

look for peter ferries anti_debugging_tricks in that pdf he collated and published a concise explanation for
a lot of the tricks employed by whitehat / grayhat / blackhat players in the field

as to programs there are a lot and lot of them point your browser / wget to crackmes.de for a start and look at level 1 easy crackmes
also nowadays a lot of ctf (capture the flag are written and some very good analysis of the contest are published by the organizers get them and read them
most of the time anti-debugging tricks tend to be camouflaging a tree in the jungle

and last but not least if you know how to reverse engineer you tend to write better code
and if you understand how to code better you tend to write software that is harder to reverse engineer

as to your original questions
circumstances /anger /frusturation at under performance of high priced bloatware induces cracking the shit out of it
i was dragged into cracking a statistical software that took 10 minutes to take input and print a process capability index graph ( cp / cpk > 1.33)
the software costed a huge amount during circa late 90's the firm had one legitimate purchase and the shit printed about 20 30 graphs at the most the audit was just around the corner the ENGINEER the CREW the SELLER all were clueless and were lying i could calculate better with lotus 123 and print better in dot-matrix printer it had a small matchbox sized container with several needles struck in the back of the pc and thus i inherited the legacy of cracking and in two straight day night session hundreds probably thousands of graphs were printed with fake/ doctored inputs that all said all our pathetic processes had a capability index > 1.33 and the rest as they say is history

prior to this skirmish i hadn't written a single line of code unless you think writing a few lotus 123 macros means programming

as to reading assembly it is a byproduct of staring over debuggers / disassemblers / hexeditors / notepad / wordpad / display of gibberish worms squiggling around after viewing them for so long you tend to separate centipedes from millipedes unconsciously

destinations never change their places ways do change

learn to navigate equally well in debug.com or windbg , sourcer or ida , trw or ollydbg , hiew or hxd , perl or powershell
they all lead you to destination though each travels through different paths

Thanks to you, I discovered his site - unfortunately not updated anymore:
http://pferrie.host22.com ("http://pferrie.host22.com")

A lot of serious info from a Microsoft researcher...

Best regards
bilbo

P.S: just a little advice to qd0097: do not ask too much to people, you should be like a pioneer, who discovers himself the road; you should be unconventional, without following the well-thinking or experienced people; you should be crazy, and trust that the impossible can happen...
IMHO, your method ("I am currently writing programs in c++ and then viewing the assembly" is the best.

Thanks Blabberer, appreciate the detailed advice, and thanks for the links!

Also thanks for the advice bilbo! I'll take it on board.

Most importantly...softice...in XP.

Thanks for link to the Ferrie pdf Blabs.

Good advice Bilbo.

I realize this thread is getting old but I haven't been around for a bit and thought I'd throw in my two-bits worth.

Speaking of crazy, I enjoyed breaking at the entry point of an app and single-stepping right through to the Windows entry point and beyond, taking notes as I traced. When you do it a couple of times you get used to the functions you can jump over and which functions do what. Before the Windows entry point there is a lot of initialization going on.

Many people would find single-stepping overly tedious but if you persist, and take notes with addresses, you learn how to extract yourself from nested calls by using the stack. If you get lost, you can terminate the app and start again, this time setting a breakpoint where you got lost and jumping straight to it from the entry point.

After the Windows entry point, which leads into a big loop, you can watch the windows being formed into structures then later they appear on the screen behind a debugger like softice. Many apps used to put up a small screen before the main window that was helpful in finding serials.

When you get used to what should be there, when protection code shows up, it is often really obvious. An instruction seems out of place and you get suspicious. Some protections use assembly instructions that look totally out of place. You can see which ones by ready through the Ferrie pdf that Blabberer mention.