CYBERS hackers were the good guys.

The hackers stayed true to the Hacker

ECURITY
Crackers were considered to be much less talented than the elite
hackers, simply making use of hacker-written tools and scripts without
understanding how they worked. Cracker was meant to be the catch-
all label for anyone doing anything unscrupulous with a computer —
pirating software, defacing websites, and worst of all, not understanding what they were doing. But very
few people use this term today. The term's lack of popularity might be due to a collision of definitions —
the term cracker was originally used to describe those who crack software copyrights and reverse
engineer copy protection schemes. Or it might simply be due to its new definition, which refers both to
a group of people that engage in illegal activity with computers and to people who are relatively
unskilled hackers. Few journalists feel compelled to write about an unskilled group using a term
(crackers) that most people are unfamiliar with. In contrast, most people are aware of the mystery and
skill associated with the term hackers. For a journalist, the decision to use the term crackers or hackers
seems easy. Similarly, the term script kiddie is sometimes used to refer to crackers, but it just doesn't
have the same sensational journalistic zing of the shadowy hacker. There are some who will still argue
that there is a distinct line between hackers and crackers, but I believe that anyone who has the hacker
spirit is a hacker, despite what laws he or she may break. This unclear hacker versus cracker line is even
further blurred by the modern laws restricting cryptography and cryptographic research. In 2001,
Professor Edward Felten and his research team from Princeton University were about to publish the
results of their research — a paper that discussed the weaknesses of various digital watermarking
schemes. This paper was in response to a challenge issued by the Secure Digital Music Initiative (SDMI)
in the SDMI Public Challenge, which encouraged the public to attempt to break these watermarking
schemes. Before they could publish the paper, though, they were threatened by both the SDMI
Foundation and the Recording Industry Association of America (RIAA). Apparently the Digital Millennium
Copyright Act (DMCA) of 1998 makes it illegal to discuss or provide technology that might be used to
bypass industry consumer controls. This same law was used against Dmitry Sklyarov, a Russian computer
programmer and hacker. He had written software to circumvent overly simplistic encryption in Adobe
software and presented his findings at a hacker convention in the United States. The FBI swooped in and
arrested him, leading to a lengthy legal battle. Under the law, the complexity of the industry consumer
controls don't matter — it would be technically illegal to reverse engineer or even discuss Pig Latin if it
were used as an industry consumer control. So who are the hackers and who are the crackers now?
When laws seem to interfere with free speech, do the good guys who speak their minds suddenly
become bad? I believe that the spirit of the hacker transcends governmental laws, as opposed to being
defined by them. And as in any knowledgeable group, there will always be some bad people who use
this knowledge to conduct bad acts. The sciences of nuclear physics and biochemistry can be used to kill,
yet they also provide us with significant scientific advancement and modern medicine. There's nothing
good or bad about the knowledge itself; the morality lies in the application of that knowledge. Even if
we wanted to, we couldn't suppress the knowledge of how to convert matter into energy or stop the
continual technological progress of society. In the same way, the hacker spirit can never be stopped, nor
can it be easily categorized or dissected. Hackers will constantly be pushing the limits, forcing us to
explore further and further. Unfortunately, there are many so-called hacker books that are nothing
more than compendiums of other people's hacks. They instruct the reader to use the tools on the
included CD without explaining the theory behind those tools, producing someone skilled in using other
people's tools, yet incapable of understanding those tools or creating tools of their own. Perhaps the
cracker and script kiddie terms aren't entirely outmoded. The real hackers are the pioneers, the ones
who devise the methods and create the tools that are packed on those aforementioned CDs. Putting
legality aside and thinking logically, every exploit that a person could possibly read about in a book has a
corresponding patch to defend against it. A properly patched system should be immune to this class of
attack. Attackers who only use these techniques without innovation are doomed to prey only on the
weak and the stupid. The real hackers can proactively find holes and weaknesses in software to create
their own exploits. If they choose not to disclose these vulnerabilities to a vendor, hackers can use those
exploits to wander unobstructed through fully patched and "secure" systems. So if there aren't any
patches, what can be done to prevent hackers from finding new holes in software and exploiting them?
This is why security research teams exist—to try to find these holes and notify vendors before they are
exploited. There is a beneficial co-evolution occurring between the hackers securing systems and those
breaking into them. This competition provides us with better and stronger security, as well as more
complex and sophisticated attack techniques. The introduction and progression of intrusion detection
systems (IDSs) is a prime example of this co-evolutionary process. The defending hackers create IDSs to
add to their arsenal, while the attacking hackers

0x210 What Is Programming? Programming is a very natural and intuitive concept. A program is nothing
more than a series of statements written in a specific language . Programs are everywhere , and even
the technophobes of the world use programs every day. Driving directions, cooking recipes, football
plays, and DNA are all programs that exist in the lives and even the cellular makeup of people
everywhere . A typical " program " for driving directions might look something like this: Start out down
Main Street headed east. Continue on Main until you see a church on your right. If the street is blocked
because of construction , turn right there at 15th street, turn left on Pine Street, and then turn right on
16th street . Otherwise , you can just continue and make a right on 16th street. Continue on 16th street
and turn left onto Destination Road. Drive straight down Destination Road for 5 miles and then the
house is on the right. The address is 743 Destination Road. Anyone who knows English can understand
and follow these driving directions ; they're written in English . Granted , they're not eloquent, but each
instruction is clear and easy to understand , at least for someone who reads English . But a computer
doesn't natively understand English; it only understands machine language. To instruct a computer to do
something , the instructions must be written in its language . However, machine language is arcane and
difficult to work with . Machine language consists of raw bits and bytes, and it differs from architecture
to architecture . So to write a program in machine language for an Intel x86 processor, one would have
to figure out the value associated with each instruction , how each instruction interacts , and a myriad of
other low-level details . Programming like this is painstaking and cumbersome, and it is certainly not
intuitive . What's needed to overcome the complication of writing machine language is a translator. An
assembler is one form of machine-language translator: It is a program that translates assembly language
into machine- readable code . Assembly language is less cryptic than machine language , because it uses
names for the different instructions and variables , instead of just using numbers. However assembly
language is still far from intuitive . The instruction names are very esoteric and the language is still
architecture-specific. This means that just as machine language for Intel x86 processors is different from
machine language for Sparc processors , x86 assembly language is different from Sparc assembly
language . Any program written using assembly language for one processor's architecture will not work
in another processor's architecture . If a program is written in x86 assembly language , it must be
rewritten to run on Sparc architecture . In addition , to write an effective program in assembly language,
one must still know many low- level details of that processor's architecture . These problems can be
mitigated by yet another form of translator called a compiler. A compiler converts a high -level language
into machine language. High- level languages are much more intuitive than assembly language and can
be converted into many different types of machine language for different processor architectures . This
means that if a program is written in a high - level language, the program only needs to be written once ,
and the same piece of program code can be compiled by a compiler into machine language for various
specific architectures . C , C++, and FORTRAN are all examples of high -level languages . A program
written in a high -level language is much more readable and English-like than assembly language or
machine language, but it still must follow very strict rules about how the instructions are worded or the
compiler won't be able to understand it . Programmers have yet another form of programming language
called pseudo-code. Pseudo-code is simply English arranged with a general structure similar to a high -
level language . It isn't understood by compilers, assemblers, or any computers, but it is a useful way for
a programmer to arrange instructions . Pseudo-code isn't well defined. In fact, many people write
pseudo-code slightly differently. It's sort of the nebulous missing link between natural languages , such
as English , and high -level programming languages, such as C. The driving directions from before,
converted