I probably do NOT fit in there yet..and certainly don't need to get banned or flamed for asking the wrong questions...LOL.. but is there any place for a beginner to start reverse engineering? Such as how to use SoftIce / Driver Studio? Tutorials..etc..etc..but mainly a place that friendly to REAL newbies..and can help them get started? Or maybe a "nice" IRC channel? (oxy moron?) Basically a place that can handle the DUMB question us newbies will ask? the question answer part is what Im concerned with getting. I am at ground 0 on this (dont even have or know how to truly install SoftIce even yet)...just been reading and collecting files and what not.

Sorry to bother you all and thanks for any replies/help.

Thanks for your time.

Your question must be a smart question even you are the beginer in cracking/reverse enginerring!

You ask a lousy question,you will get a lousy anwser.

Hi thanks. Well I guess Im looking for place that is more forgiving with newbies. Most are NOT..and I dont wanna "step" on anyones toes..and disrespect anyones "house" (so to speak).

Like I stated..I dont even have SoftIce installed. Can I ask what is the difference between SoftIce and Driver Studio? Why would you use/have one over the other?

I see there is anew rlease for Driver Studio.... does this one work with XP? I have read that most can NOT install SoftIce using XP..or if they do..the OS freezes up..
I guess we'll start there. (or are these not good enough?? just trying to learn..have to start somewhere I suppose)

Thanks

> I dont wanna "step" on anyones toes..and disrespect anyones "house" (so to speak).

>Like I stated..I dont even have SoftIce installed. Can I ask what is the >difference between SoftIce and Driver Studio? Why would you use/have >one over the other?

You ask a lousy question and you will get a lousy anwser!
Driverstudio is a updated softice with more features!

>I see there is anew rlease for Driver Studio.... does this one work with XP? I >have read that most can NOT install SoftIce using XP..or if they do..the OS >freezes up..
>I guess we'll start there

Driverstudio 3.1 WORKS perfect in winxp sp1!

And REMEMBER TO READ THE FAQ!!!!
YOU DIDN'T DO THAT!!!!!!

We are not all quite as insane as esther, however, your question does suggest that you have not followed the rules which require one to TRY to help themselves before asking a question.

To illustrate this point, Softice and DriverStudio are made by a company called Compuware. They have a website and product descriptions which would have provided you with ample information to understand that Softice is a debugger and is part of DriverStudio and may also be acquired as a standalone product. It even comes in a Lite version.

If you had done some research either here and/or on the net, you would have discovered that most of the problems reported with softice and XP relate to XP with SP2. You would also have discovered that some people report problems with SP2 and some report few problems. It stands to reason, that the latest version of the software is the "most likely" to operately properly with the "latest" operating system.

But all this simply begs the question. Why do you want to start with Softice and do you have any idea of the differences between using Softice and another debugger, such as Ollydbg and/or the debugger which comes with the later versions of IDA. These are all things which general reading on the subject of reversing should provided you with some working knowledge.

In short there is a qualitative difference between a "dumb" question, asked because you tried to find an answer to your own question and didn't find the answer, or really didn't understand what you found, and a question that is "dumb" simply because it demonstrates the person who asked the question didn't bother to try to help themselves to acquire basic knowledge that is readily available to people who make an effort to help themselves.

There is a whole lot to try to learn BEFORE you should start reversing. That includes attempting to acquire a working knowledge of Assembly language instructions. Why you ask, well, it's because what you generally see in the output of a debugger is Assembly Language. If you don't recognize what you are seeing there, what is the point of starting off worrying about which debugger to use???

You have to learn to crawl before you can try to fly and there really is no effective shortcut to taking the time to try to learn some of the fundimentals. Too many "newbies" want to jump right into the deep water, hoping they can learn to swim after they are up to their necks in a whirlpool and going down for the last time. Impatience with wanting to "crack" something often gets in the way of learning how to reverse software.

You get to chose which path you will take, but you have to take the consequences of demonstrating the you really haven't thought through what you ought to be doing. For example, there are several good collections of knowledge linked at the bottom of these Forums, where you may begin your journey through the Dark Codewoods. If you really want to help yourself, you have a whole lot of more reading and studying before you should be trying to work the magic.

Regards,

Thanks for the replies. I understand I have a long road ahead of me.... I didnt install SoftIce or Driver Studio....nor have I even tried. I am trying to understand the "lingo"..and the basic logic behind "cracking" a program. As for ASM...I have had exposure to it in satellite card form...breaking down and running through DSW/SW routines/executions.....branches..jumps..etc..etc....and Im ot all that unfamliar with it...but by no means a GURU..or even average.
I was just using SoftIce as the example..as it is the most popular..and the name most thrown around when referring to RE, but I dont know the difference between them. I dont even know what questions to ask to tell the differences anyways.

I was wanting to try and get a print out of some ASM source form some app...and try to look for simple jumps..and follow where they go...etc..etc. I see there are soem tutorials...and "crackmes" that are for newbs to learn how to walk through or test ways of "cracking" programs...but those are still above me.

You say Im nto ready......and I have alot of things to learn ahead of me...so where would one start? You say google..searching for what? is there a path?

Noone is looking for a shortcut...just looking for some basic "learnin' the ropes" type talk..and some friendly advice. Everyone has to start somewhere. Is ther a .doc I should read first. I skimmed the "FAQ"....and took in what made sense to me.

Thanks for your time.

Take your time and learn asm.And search the forum.There are lots of infos in here.And remeber don't restrict the tools when learning

Welcome aboard

My advice would be to start here: http://www.woodmann.com/fravia/index.htm ("http://www.woodmann.com/fravia/index.htm")
Read as many essays as you can that are rated as "Beginner"
If you see something that you don't understand in one of those essays, search for answers on this board.

I would also point to hxyp://tutorials.accessroot.com there are several tutorials specifically thought for beginners..

Thanks for the replies..and the welcome. =)

Another quick question..before I go on a reading binge at those links you posted.

In my former exposue to ASM.. there was what was known as an "instruction set"....basically each "card"...had its very own....each had different "OP" codes it responded to.....usually based of some sort of large public released "micro-controller"

Is there a specific instruction set with a break down of what OP codes work for RE stuff?...or does that NOT apply here?

Thanks..I will try to read over the "noobie" tuts..and search on the text I dont understand...

Concentrate on the intel i86 assembly dialect. Look for "the art of assembly".
While the more assembler you know, the better, you do not need to be an assembler wizard to start to crack. For starters, you only need a working understannding of a handful of instructions. As you go along, you will search for more and learn more instructions, structures, calling conventions blah blah. At least in my case, Cracking was an excellent introduction to learn assembler!

Naides-

thanks for the tip..as well as the comment of encouragement. That is basically how I learned about Smart Card ASM...tirla and error...learn a few instructions/op-codes...and from there...I just tore down other people's "code" to see how they were doing the checks/cloaks & defeats. Im glad you dont need to be a ASM Wizard..because I surely am NOT...LOL.

I guess the "logic" behind things are what i need to learn first.

Like you "unpack" an .exe........decompile/debug the app.....look at the source code and run through the ASm to see what is goin on INSIDE.. from there I can tackle reading up on each part..and interpreting it as I see fit...(ie: translate to idiot....LOL)

Not sure when you know your ready to "crack" your first app. I would think a crackme is always the first step...to get familar with different kinds of protections/defeats.....correct? For my first REAL WORL app..I was thinking something like WinZip?? So the i86 instruction set is what I shall focus on. What was YOUR first step at "cracking"...readmes.....creackmes....tuts....everything..

Thanks

Hello,



From my point of view, the most part of the actual crackmes/keygenmes are not intended to learn how to defeat actual protections.

Crackmes are programmed by crackers for other crackers, but I like to see it like a game, or maybe a way to give to crackers some automatisms (for the simplier ones). The more you train on crackme, the more you'll see some common points, but you'll not gain training on actual protection (except on some packers / protectors).

If i take all crackmes submitted to crackmes.de, I don't think you can see many protection schemes that are in actual sharewares. For a summary I was just trying to say, that you'll get "a way to think" not a "way to defeat".

From my point a view, that's trully better. It remind me a part of the Book : "if you want to feed someone, give him a fish. If you teach him how to fish, he'll get food for his entire life" (sorry i don't know how to translate it, but the idea is there).

Regards, Neitsa.

Indeed. There is even a "translation" to "real world" use...

+ORC
hxxp://www.woodmann.com/fravia/howto82.htm

(look at the end of tutorial)

I also recommend you gain a good understanding of the win32api. Good enough that writing your own apps in C/C++ is second nature (for the api, rather than the language). Many times I've overcome a lack of asm knowledge with good api knowledge, and been able to fill-in-the-gaps. When you can look at an app, see the part of the app you want to find in the deadlisting and immediately come up with a bunch of likely api calls that you can look for, you're on the right road.

What is Win32API? The instruction setused to communicate with hardware through the OS? (I know..I'll look it up) ....

But I am by NO means a programmer in any language. I have some exposure to it..being a little Java, .NET (C#/ASP)...and ActionScript (if that quailfies)..LOL...
(what is an api call?)

So should I focus on learning more of ASM or a prgrammign language such as C++ or C#?)

thanks

You are in a maze of twisty little passages, all alike.

I feel your pain. It's not that you want people to teach you how to crack, it's that you need someone to teach you how to teach yourself how to crack It's kind of a "meta" problem or bootstrap problem; I'm not sure what you'd call it.

Don't get me wrong, the "help yourself before you get smacked around" principle exists for a good reason, but sometimes you've got to know when to bend the rules just a bit to help save someone's sanity. The "dark codewoods" as JMI is fond of saying are just so vast that it's an impressively large hurdle just to know how to start. A beginner who truly wants to read and figure things out on his/her own can spend days and weeks just spinning their wheels - they're putting out tons of effort reading, etc., but it's not very effective if you're spending your time on the wrong things.

I'm trying to work on being concise, so there's not a lot of explanation given here for why I would do things in this particular order:

1) Learn IA-32 assembly. 64-bit stuff can wait. Don't fret over x87 (FPU) or MMX opcodes for now. If you need more detail later, you can always dive into it. Intel's IA-32 Architecture Software Developer's Manual is the prime source for this. Volume I is worth reading cover-to-cover, IMHO. I don't recommend that for volume II, but it is an essential reference of every opcode. Volume III is ring-0 stuff. Save it until you need it.

2) Learn the PE/COFF format. For now, you just need to know the PE header, the section table, and to understand the process of loading an executable into memory. Before long, you'll want to understand the IAT, too. MS maintains the official specification, but various other sources are probably more "friendly", and may cover things that MS doesn't document.

3) Learn how stack frames work, and learn the most common calling conventions. It's not totally essential to know this, but it helps a lot. There's not really a good source for this; info is scattered all over the place.

4) Get a general feel for how windows programs are structured. Iczelion's tutorials a good source for this. Reading them all isn't necessary, but I'd read at least the first few.

5) Grab a good decompiler and debugger and get cracking. W32DASM is only useful for quick deadlistings since it can't intelligently follow code. IDA is highly recommended. Dede is specifically for delphi programs - I haven't messed with it yet, but it's supposed to much better than a general decompiler for delphi apps. Debuggers are a matter of personal preference. SICE is highly venerated by many, and it's probably your only viable choice for ring-0 debugging. It's also a b#&%* to get working on modern systems, often times. Ollydbg is ring-3 only, but it's a very nice tool for beginners. It has some bugs in its tracing functions, but it's still pretty early in its life cycle.

At this point, it's all pretty much hands-on and lots of tutorial reading for specific protection schemes. Nearly all programs these days are wrapped by some kind of a crypter/packer. They range from the easy, like UPX, to the insanely hard, like Starforce. I'd start by doing some simple reversing of unprotected apps like Winzip. Do some serial fishing just for fun and then move on to the protected targets. Start with simple packers like UPX and ASPack, then move on to medium level stuff like ASProtect. After that are the advanced schemes like Armadillo.

Most importantly, stay organized. I actually have a "Reverser" directory on my computer. Inside this are 3 directories: tools, reference, and "shit to be cracked" If you don't keep your tutorials, references, notes, etc. divided up into some kind of logical order, you'll go insane.

Thank you for the reply... you have helped IMMENSLY...you have done the BEST thing possible..given me direction! LOL

I will start doing the following:

1.) Read up on: IA-32 assembly & Intel's IA-32 Architecture

2.) Learn the PE/COFF format (and even what each of those acronyms mean...and even the differnce between each..as of now I dont even knwo what type of format that applies to) Specifically these areas: PE header, the section table, and the process of loading an executable into memory

3.) Learn how stack frames work, and learn common calling conventions (IS this the same as the "stack" in most ASM code? (Like a register or temp holding place?)

Does this foloow the first in last out procedure?

4.) GO to : Iczelion's tutorials to get a general idea on how Windows Programs are structured.


5.) Learn the differences between debuggers, decompilers..and find one what that best suits me and my needs.

Sidenote: find out what the h*ll ring-0 & ring-3 mean....LOL

Then install one and start doing osme hands on?

Sound about right?..

Sounds good to me. Just keep in mind that I am newbie, so I'm not the most qualified person (by far) to give you advice . This was just an order I found helpful for myself, as someone who likes to order things in a simple-to-complex order.

In order to understand how a protection scheme works, you first need to understand how windows programs work.

In order to understand how windows programs work, you need to understand the win32 APIs, the PE/COFF format, and how programs in general work.

In order to understand general programing, you need to understand how the stack is utilized, how calls and returns work, how parameters are passed (calling conventions), and assembly language itself.

I tend to learn things best from the bottom up, so the list I gave you is basically the reverse order of this. I understand that for some people, this is a total bass-ackwards way of doing things. So YMMV.

Really, 2)-4) could be done in any order. It's all just foundational knowledge that lets you understand the context in which a program you want to work on operates. You could just jump right in with nothing more than a working knowledge of asm, but it would be really hard to understand what you're seeing. Program flow by itself is horribly convoluted if you don't abstract things. And to do that, you have understand the whole of the Windows-on-x86 environment.

Edit: I forgot to mention, ring-0 and ring-3 are just "slang" for privelege levels 0 (kernel mode) and 3 (app mode) on x86 processors. They can also refer to the subset of opcodes and registers which are accessible from those privelege levels. Ring-1 and ring-2 aren't used at all on POSIX-compatible operating systems. Or at least, they aren't supposed to be. IIRC, Windows actually does use ring-1 for certain driver-level code. Don't quote me on that, though.

This may not help much as you're not a C/C++ coder, but I'll throw it in there anyway. The vast majority of apps you're likely to crack will be C/C++. I'll ignore VB for now, as that requires a different process, and Delphi apps have DeDe which is a massive help. There are only a negligible number of apps written in asm that you'll want to crack. The goal is not so much to learn asm and how to code an app in asm, it's to learn what the asm produced by a compiler from C/C++ code looks like. There is a real huge difference between a basic Windows app written in C/C++ and compiled, and one written in asm. One way I found to quickly understand the structure and format of the deadlisting of a C program was to leave the disassembly window open in my IDE (Visual C++). I didn't use it for debugging, but I made a point of looking at it and trying to correlate the asm I saw to the C I wrote.

I will pm you the name of a commercial app that is a very simple, 2 byte crack. The code logic is easy to follow, and once you get to the point where you want to try to crack something on your own, it's a good start. It'll also give you a sense of achievement knowing you figured out the crack on your own, without any tutorials.