Its done by witches.. because all the info's say "A witch says"

 

How do plugins and software get cracked?

Usually through a cycle of bad life decisions

 

I reckon you don't have to know at all but it requires real skill, dedication and of course intelligence...and among them one is missing in you thus you asked that question, okay...

If i were you, i'd have asked "What is reverse engineering, do i have to reverse everything myself or it's already done in strings-arguments-integers itself as i'm going to learn assembly language... ???"

Make people show interest in your question not doubt or humor in answer

 

R2R

 

Nice try, FBI

[Strap in, hold on, shut the windows, take the phone off the hook, hold on to your hats, and buckle up for a good old rant from an old timer who never was... You have been warned.]


There are three essential things you need to be a cracker, as opposed to a hacker which is another discrete skill set although they sometimes overlap: 1: Aptitude 2: Knowledge 3: Sixth Sense

Aptitude and temperament can't be learned. You either have the kind of 'autistic' personality needed for this or you don't. You will have to spend many hours studying even if you have the aptitude. Which leads on to point 2 - you need the knowledge, many hours studying a few different skill sets that need to be combined for maximum efficiency. And the sixth sense might be debatable, but the best and most successful crackers know when to use certain tools, where to look in certain places; know when they are being led down a garden path, or when to delve deeper in to particular areas of code where the 'crack' might be hiding. Remember...

There's a crack, a crack in everything, that's where the light gets in!

There are many sites out there dedicated to the art of reverse engineering (cracking). You need to become a member and to be mentored. To get access you need to show aptitude, but you also need to be trusted and vouched for a lot of the time. Mallatia+ had several levels of conundrums and puzzles to get through. Some sites you will never find unless you know the right people. But they are there and they contain masses of knowledge about tools and about technique. You could invent the wheel without them, but your life will be much easier and you will save time by gaining their insights. Crackers love to teach the hungry but they hate to waste time on those who just want a quick fix. Cracking is a long game. There have been people out there that woke up after many years and realised they had not gone outside for 10 years. Cracking is addictive.

There are sites out there that you can still go to like searchlores who I believe +forseti still maintains on some of his servers. There are other mirrors of it. The info is old now but much of it is still good. Many techniques have not changed even if some of the tools have.

To be a cracker you don't need to be a programmer necessarily but you do need knowledge of assembly language. Even a modicum. It can not be done without this bare essential. Assembler is difficult. It is laborious and terse. See Randall P. Hyde's Art of Assembly Language for a primer.

Most crackers can program a bit, but when you are cracking you are dealing with much more lower level languages (like assembly) as compared to higher level languages like C++ or Java or Perl. Having said that, Perl is quite terse as is 'C', which many people say has all the advantages of Assembly programming, and with all of the drawbacks. Little joke. C is a very bare metal language. It would be a good 'high level' language to learn first to get an idea before you delve in to Assembly itself. Perl, people joke, is WORN - Write once read never, because going back and trying to understand what you did six months ago is difficult, also because of its terseness.

For example, most drivers and Ring 0 programming is done in C, as is most of the lower levels of the Microsoft Windows OS.

So, that is the very first thing you will need if you have the temperament: knowledge of assembly programming. In this you will understand how a CPU works. How memory is allocated and deallocated and also how registers work. You will learn about conditional jumps and interrupts such as INT 13h - a real red flag to a cracker.

You will also need knowledge of the windows x32 API, which is famously undocumented, though there are files out there of its undocumented features such as Win32API. txt or wtf. You need to know what all that disassembled code means after you have disassembled it. You will be wading through the wheat and the chaff and you need to know what's what.

There are certain things that are essential to read before you start. One of them is Cristina Cifuentes' Doctoral research paper on Reverse Compilation Techniques.

[PDF]
https://yurichev.com/mirrors/DCC_decompilation_thesis.pdf

If you can't read this and understand what is going on, then cracking is probably not for you. It's written in a very understandable manner and doesn't try to show off. It will give you many insights to the game ahead. It's a very enjoyable read for even those who just want to understand how a computer or CPU works.

Decompilation is only one of a few techniques when reverse engineering, and I would say it's not as much used as Disassembly. Many languages don't like to be decompiled or don't take well to it even if they can be. You might get a decompilation of the code, but you might only have generic names for objects and methods used. Java decompiles a lot better than C++ for example. Still, it's essential to understand the theory behind decompiling even if you are disassembling.

All higher level languages can be disassembled down to their component parts as I understand it. They are the bits that give information to the CPU for allocating memory and assigning registers, for raw values that the OS and CPU can understand and for telling a program when it needs to start or quit or jump to another section of the higher level code. So, again, knowledge of assembly language is absolutely essential, if only at a rudimentary level. A fundamental understanding will take you further, quicker.

It looks a bit like this (think of it as a pyramid) -

1: Higher level language that program was created in (C++, C, Java)
2: Lower level language that gives instructions to OS via its API (Assembly language)
3: Machine code, or binary, 0's and 1's that translate all that in to electric impulses.

When you disassemble a 2MB program in your Disassembler of choice, it spits out a file that is 10 times that size, depending. CPU's these days have hard coded instructions such as AVX and whatnot that these programs can make calls to. Just like back in the day the very first instructions to be hard coded were multiplication and division and subtraction etc.

So you need a good disassembler. A very popular tool is W32DASM . https://www.filehorse.com/download-w32dasm/

You might also want to look at assemblers like MASM or TASM or NASM to gain a higher understanding.

http://masm32.com/board/index.php?topic=8118.0

https://alt.lang.asm.narkive.com/IuMarut3/iczelion-s-tutorials-revisited

I have loads of Iczelion's tutorials, as I do +Mammon's. I have full dumps of their sites. +Mammon's tales to Jeff's Grandson still sticks in my memory. I even know who 'Jeff' is and have talked to him several times. Sorry, +Jeff. + denotes those that took part in the HCU (higher cracking university). But I digress.

https://stackoverflow.com/questions/9944160/nasm-is-pure-assembly-but-masm-is-high-level-assembly

Spoiler: A good run down of what you need to start

My recommendation purely from a "reverse engineering" perspective is to understand how a compiler translates high-level concepts into assembly language instructions in the first place. The understanding of how register allocation is done in various compilers and how various optimizations will obscure the high-level representation of nested loops (et.al.) is more important than being able to write one particular dialect of assembly input.

Your best bet is to start with the assembly language intermediate files from source code that you write (see this question for more information). Then you can change the source and see how it affects the intermediate files. The other place to start is by using an interactive disassembler like IDA Pro.

Actually writing assembly language programs and learning the syntax of NASM, MASM, gas, of as is the easiest part and it does not really matter which one you learn. They are very similar because the syntax of the source language is very basic. If you are planning to learn how to disassemble and understand what a program is doing, then I would completely ignore macro assemblers since the macros completely disappear during translation and you will not see them when looking at disassembler output.

Diatribe on Learning Assembly

Learning an assembly language is different than learning a higher level programming language. There are fewer syntactical constructs if you ignore macro assemblers. The problem is that every compiler chain has a slightly different representation so you have to concentrate on the concepts such as supported address modes, register restrictions, etc. These aren't part of the language per se as they are dictated by the hardware.

The approach that I took (partially because the university forced me to), is to explore and understand the hardware itself (e.g., # of registers, size of registers, type of branch instructions supported, etc.) and slightly more academic concepts such as interrupts and using bitwise manipulation for integer match before you start to write assembly language programs. This is a much longer route but results in a rich understanding of assembly and how to write high performance programs.

The interesting thing is that in the time that I spent learning assembly and compiler construction (which is intrinsically related), I actually wrote very few assembly programs. More often, I am required to write little snippets of inline assembly here and there (e.g. setting up index registers when the runtime loader didn't). I have spent an enormous amount of time dissecting crash dumps from a memory location, loader map file, and assembler output listings. I can honestly say that the syntax of each assembler is dramatically different as well as what various compilers will do to muddle the intent into fast or small code.

Learning how to write assembly programs was the least worthwhile part of the education process. It was necessary to understand how source is translated into the bits and bytes that the computer executes, but it really was not what I really needed to reverse engineer from a raw binary (disassembler -> assembly listing -> best guess of high level intent) or a memory dump. I do more of the latter, but the requirements of the job are the same.

I do more of the latter, but the requirements of the job are the same.

1. You really have to understand what the constraints of the architecture are.
2. You have to know the very basic syntax of the assembler in question - how are address modes indicated, how are registers indicated, what is the order of arguments for a move
3. What transformations a compiler does to go from if (a > 0) to mov.b r0,d0 ... bnz $L

Start by learning about computer architecture (e.g., read something from Andrew Tanenbaum), then how an OS actually loads and runs a program (Levine's Linkers & Loaders), then compile simple programs in C/C++ and look at the assembly language listings.

OllyDbg is a freeware debugger/disassembler that is also used a lot I believe.

And when you have found those interesting interrupts and other red flags that a cracker is looking for, you will want to use a debugger to set breakpoints and trace through the code methodically to see where that leads.

Two of the most popular debuggers apart from OllyDbg, are Softice and IDA.

It's been said that Softice is the the fighter jet of Debugging, while IDA is the Stealth Bomber!

To see IDA in action have a look for the Plogue video where David shows it while he disassembled the code from the Yamaha DX7 chips to create OPS7. https://www.plogue.com/products/chipsynth-ops7.html

Ok, so that is decompilers and debuggers. But you need more tools again.

An essential tool for a cracker to have in his/her box is a Hex Editor. There are many many examples of these and there are even very old ones that just do the job better than anything. Your cracking mentor will advise you.

A hex editor is used to patch a program sometimes if a simple XOR is involved or perhaps a certain String. Very few programs these days use such basic methods of protection, but you'd be surprised. You just flip the bits in the hex editor and save, et voila.

Also, remember when you have disassembled a program you might have hundreds of thousands of LOC (lines of code). Cubase contains millions! That's a lot of searching. So another tool that is handy is something like WinHex which allows you to search for Strings of greater length than 1, or 2, or 3, or 4. Really, it's no good searching for a String of 'ONE', it wouldn't make sense, neither would 'TWO', but setting it at 'FOUR' or greater can yield some very interesting insights. WinHex is a very good Forensic program that contains many features. I recommend it.

It helps if you have a fairly fast computer with a fairly large HDD size to aid you in all of this chicanery and shenanigans. It saves time and is less frustrating.

---

Reverse Engineering is used by every single major corporation in the world. How else do you think they all copied those closed designs as soon as they appeared on the market? It's a dirty secret, but a well known one and even if it is a very grey area, nobody really points the finger too much at anyone else because they know everyone else is doing it and people in glass houses had better not throw stones. There's a code of conduct and an unofficial gentleman's agreement of course where a line in the sand is drawn, but as long as that is not overstepped you can get away with, okay, maybe not murder, but the next best thing: Theft.

Crackers might be aiding and abetting theft and us end users might very well be thieves. But all the same, it's the big corporations that do this every day and make millions from it. I'm not trying to justify anything, that's another argument for another day. Just saying.

---

So, a cracker that knows what he is doing might spend less than an hour on a program to crack it. He might spend days or weeks or months or even years sometimes. Packers make code harder to penetrate and code obfuscation and timebombs make it more frustrating again. U-he is one of the biggest culprits here and he has even made his code obfuscation and timebomb tricks available to other developers (hi Urs!). The irony of this is the fact that you don't even need to reverse or crack his code. You just need a few people to club together to buy a single copy for a tenner and then share the code. Fully regged! But this is why I like U-he and am happy to buy their plugins. They trust the end consumer to do the right thing. Give respect, get respect.

It's very hard to protect a program from cracking. You can use the mathematical approach like Steinberg and use encrypted dongle and HASP and whatnot, but that has its own drawbacks as well as benefits. Most developers use lazy protection these days by sniffing around in your dirty laundry drawer and phoning home. The ethical and moral questions this raises are soon quashed on most forums where AD revenue from said companies is a Thing. Many feel violated and this gives a reverse ethical and moral imperative to those people to use cracks from said developers. I count myself in this bracket, right or wrong. Distrustful and unethical developers like Tone 2 or Melda or whoever don't get any more of my money. In fact, it's my duty to crack them. Two can play that game. Those that give me respect, get my respect. Those that treat me like a thief when I payed for their software, I steal from, if I can. This debate is for another thread...

---

Today we are blessed with the most holiest of cracking teams: R2R. We are even blessed with such prolific and proficient 'teams' such as VR. In days of old we had Radium and H20 and Air and many many others. Each added to the knowledge. Each stood on the shoulders of the giants that went before. And now we have the biggest giant of all: R2R.

What they have achieved is simply astounding. Here is a 'team' (I don't know how many people are in it), with at least one, if not two or more, really really serious heads that can do the maths. They have the temperament but they also have the knowledge. But most of all they have that sixth-sense I alluded to earlier. These aren't chumps that are going to waste six months or six years of their life going down a blind alley. But they are champions that would spend those six months or those six years to get the greatest prize crack. As I understand it, Cubase is the one. It's never been properly cracked and any extenders out there are only out there because Steinberg want them to be. They know. I know personally that they don't take a bad view of cracks themselves, even back in the day when they could still be cracked. They are still around. The premier platform for PC music production.

I was reading on AN that someone said that there is an internal crack of the latest Pro Tools floating around for select members and testing. They didn't seem to get shouted down. Who knows.

Anyway, look at me rambling like an old lady (no offence to old ladies). Let's give the TL;DR:

How do plugins and software get cracked?

Let's use the example of Steinberg Cubase as it's fresh in my mind.

1: Cracker gets out of bed in morning. Has coffee. Latest version of Cubase has been got to him.
2: Loads it up in his Disassembler/Debugger of choice in his very fast state of the art computer.
3: Waits a long time for it to disassemble. File size is massive.
4: Uses sixth sense to step through the code and see what's what, what's interesting.
5: Finds red flags or interesting avenues to go down and look further.
6: Does searches for certain Strings, perhaps those he has found in the disassembled code, even.
7: Bingo! Finds those Strings. Finds that functionality has not been ripped out, but commented out.
8: Replaces the code so that the functionality is put back in.
9: Puts the code back together again via his assembler to create a new .exe file.
10: Tests that it all works as expected, as best he can on one machine, as one man, or a team.

This is an iterative process that takes days at least, probably weeks, perhaps even months, to get right.

Pretty obviously the Steinberg team left all that code in their Elements program so it could be extended. Perhaps they were just lazy. But Steinberg is very much one company that does not underestimate the ability of crackers and their sheer determination and wit and guile *. They wanted that code to be found. Remember, it still wasn't the full Cubase Pro code though. Mere breadcrumbs. They know how to play this game better than anyone.

* ["Wit and guile" was the very thing noted as being needed to make a successful cracker, from another successful cracker.]

Of course the crack will not be perfect. Many other factors involved. But it gives enough of a teaser for most people that those who are most determined can get 'something for nothing' or a 'better version'. Of course this just leads to deeper frustration and people end up buying the 'real thing' after a while.

Kudos to VR for doing this. These are experimental cracks. But still they put them out for testing to gain deeper knowledge and for the end users to be testers to see better where it can be cracked more. Team R2R are a more 'all or nothing' team, and for them, nothing but full emulation will do. But that's ok. The world needs both approaches. There is more than one way to skin your rabbit. Team VR is yin to the yang of team R2R. And we are all but students to our Zen masters waiting for the Shippei to come down on our backs, as we foolishly wait for the big Gong.

Spoiler: Teaching

There is no Gong you fools, we already have perfection of wisdom.

And talking of rabbits, I've rabbited on long enough. Forgive me. Don't take anything I've said seriously because I'm probably wrong, and besides, it's best not to listen to strange men on the internet. Just remember...

There's a crack, a crack in everything, that's where the light gets in.


[RIP +Fravia]

 

It's comes down to two things, 1) experience, and 2) aptitude (natural ability). From there, it then depends on if the people who do it care about what happens after they release it to the world. If they care too much, they will always lose motivation. But for the people who have the most fun in doing the reverse engineering itself, and wanting that to be shared with the world as a higher priority, they will stick around I think!

I personally think work crackers / reverse engineers do is very important for computer science and civilization as a whole, because I'm very concerned that the world seems to be headed towards "just letting the machines do the work for you" without caring how they work. Then, only a small number of people will be able to actually control the machines that the masses use, and don't understand, and don't care to understand.

 

lol.

(Don't go to the site, it has nothing to do with anything)

 

"gefährliche worte wie bombe und terrorismus im internet verbieten" (uwe schünemann, so eine art innenminister)

 

#Respect

 

Ghidra & IDA are the most common tools for reversing, each better at certain tasks depending on the scenario

 

For all the German speakers. Pretty good podcast of reverse engineering for beginners/starters by Chaosradio:

https://chaosradio.de/cr247-reverse-engineering

Interesting stuff starts at about 23 minutes in.

 

ah, that timebomb that only triggers on April Fools day

 

pretty good? its bullshit. eg topic debugging, 60 secs: 30 secs "debugging is related to reverse engineering", 30 secs host's "ive got no clue".
spare your time, watch a pretty movie with your spouse, make some beats, play with the children, or play with ida, but dont listen to that crap!

 

They call this fucker

 

Last edited by a moderator: Dec 28, 2021

my guess is they get thrown on the floor VERY hard.

 

Well, if it doesn't work, at times you can try:
"Dadada"