how to write a virus (basic)

Due to numerous requests for this type of information, I will delve myself into the dark side and release that information by which people can be arrested. Please note that this file contains no source code and no information about destructive code, but simply gives the basic ideas and principles behind writing a reproducing code resource and how it can be used to better society.

Chapter 1: Basic Principles

A computer virus, by definition, is a piece of processor-executable code that can reproduce itself within it's environment. In the Macintosh system, an object called a resource can contain executable code. Most common executable resources are of type 'CODE', along with others such as 'DRVR', 'CDEF', 'WDEF', 'INIT', and so on. These resources are loaded into memory and 'jmp'ed to to be executed (an assembly language term for jump). Note that not only these types listed above can contain code. The trick is to get the virus code loaded and called by 'accident'.

There are many places where code resources are loaded and executed. For one example, at the launch of an application, the CODE resource with ID=0 is loaded (the jump table), and then jumps to the first listing in it's table. As another example, a 'CDEF' resource is called to draw certain controls (ID=0 for buttons, checkboxes, and radio buttons; ID=16 for scroll bars, etc.). Another example: an 'INIT' resource is called at startup time if the file which contains it is in one of the special system folders. There are numerous other places within applications, and even within system software itself, where code is loaded and called. Each virus uses a trick with one of these methods to get itself called. Some of these methods are described in more detail below.

Once the virus code is executed, it's main responsibility is to duplicate itself. This in itself is a fairly easy process. Since your executable code resource is already loaded into memory, you can use a few popular toolbox calls to place it into any other file or application that would suit your needs (where it would also have the chance of being executed). After the duplication is complete, the virus may do any other task it deems necessary. One of the reasons why viruses crash is that their reproduction or startup code is not compatible with other systems and/or machines, not that their damage system actually did any damage. If you write code following the Inside Macintosh rules and code defensively, you should be able to write a clean piece of code that travels without problems. Always code defensively: it's your work out there you want to be proud of it. Read below to find some tips on doing just that.

Virus testing is a very difficult process, in that your own system is constantly infected, possibly numerous times with older versions of the virus. There are methods to the madness, so again, read on.

A few of the catches to writing a virus is being aware of the methods used by virus-protection software. If simply written, a virus could be caught very quickly and not have much effect beyond your own system. If the methods are thought out and the patches made by the protection software are understood, then a virus could at least require software companies to update their existing detection methods. Every virus to date has been able to be detected and destroyed, so don't feel bad.

Is everybody happy? Then let's go!

Chapter 2: Writing Executable Code

An executable code resource is easy to create with a good software-development application such as THINK C (or C++) or THINK Pascal or MPW. There are slight differences between the environments, but nothing major. I will be giving examples for code written in THINK C, for that is the system I use.

An executable code resource usually starts with a

 void main(void)

and within such, your executable code exists. Note, as always, that executable code cannot handle global variables (variables defined above the definition of the main code, accessible by the whole file/project). THINK C handles ways around this, and MPW uses the methods in Tech Note #256, but in most cases, you won't really need global variables, unless the code is complex enough to require separate procedures and/or object-oriented code. In any case, you can usually define your variables inside the main procedure itself. There aren't too many rules as far as writing code resources, so long as you know under which circumstances your code will be called. If you are patching a Toolbox trap, for example, you must take the same form as the patch you are trapping:

 void ModalDialogPatch(ProcPtr procFilter,int *itemHit)

If you are patching an operating system trap, you need to do some register playing, but you need to take an empty procedure form:

 void OpenPatch(void)

even though the FSOpen, PBOpen, etc. take paramBlocks. Note: they are stored in registers A0, D0, and A1 usually. Check the trap for specifics. You need to save these before you execute your code, and then restore them upon return.

If you are executing code that is to be run as a VBL or Time Manager task, always remember that you cannot use code that even thinks about using the Memory Manager (i.e. moves or purges memory). Make sure all the toolbox calls you use are not in the 'dreaded list' in the appendix of each volume of Inside Macintosh.

The type of the code resource is very dependent upon which method you wish to use to get your code executed. Read the next section for details on such execution theories.

After you're done writing the code, check it over for simple things you might have forgotten (original Quickdraw compatibility, system versions, etc.), and compile the sucker. For right now, you can throw the code resource into some sort of test file (or stagnant file, where the code will not be executed and/or reproduce). Note that you should NOT have any external resource files to compile along with it. Code resources such as this should preferably be self-contained, and not have to 'carry around the extra luggage', so to speak. There are methods to carry along bitmaps (as 'unknown data') and use them as graphics. But you should never rely on things like GetNewDialog, because that requires the existence of a DITL resource. Instead, use calls like NewDialog, where the code builds the relevant information in. It might make things harder to read and a bit harder to edit, but it's what you have to do in order to make everything self-contained.

Most of the compilers create some sort of header at the beginning of each executable code resource. This header could give away some vital information about the resource which would make it easy for a virus-detector to find. Double check it after compilation to make sure it's clean and doesn't look suspicious.

Chapter 3: Getting Your Code Executed

This technique you use here defines how your virus spreads. Some earlier viruses were more virulent than others; nVir needed an infected application to boot for it to execute; WDEF required only that a disk be inserted. There are lots of places for code to be "patched" so that your code can be executed. The trick is finding them and recovering from them gracefully. Not every method can be discussed in this note, but I will give some general examples and how to find your own 'hooks'.

One of the most popular methods amongst virii is infecting applications, since they, by definition, have executable code built right into it. If you can get your code executed along with the many other little segments in the application, the code could recover undetected. When an application starts up, the resource CODE with ID=0 is loaded into memory, and it's popularly known as the jump table. It keeps track of all of the procedures or segments in an application. If part of an application needs to call another procedure inside the application, it checks with the jump table for it's location. If it sees that the procedure is not in memory, it will load it first, then execute it. This is all taken care of by the compiler and the system software, so it's invisible to the programmer (in most cases). The system loads the jump table and immediately executes the first entry in the list when an application begins.

You can patch yourself into this list of procedures by modifying the jump table itself. You can modify the first entry of the jump table to be your code, but save the original entry so that you can call the actual application when you're done (destroying the first entry in any CODE 0 resource renders the application totally useless). So, instead of the system executing what it thinks is the application, it will run your code first, and then run the application.

Another method by which virii get executed is by utilizing a wonderful feature of the Resource Manager. As given in Inside Macintosh volume 1, the Resource Manager will look for resources in the top-most resource file that is open (the one most recently opened in most cases, unless UseResFile has been used). These searches also include searches for basic system code resources, such as window definitions, control definitions, and even international transliteration code. If you have a resource with the same type and ID as one in the system, and this resource file is open, the system will execute your resource instead of the system's. The catch again with this is that you should call the original resource as well to make your code invisible to the naked eye. This, apparently, is how the WDEF virus worked. When a disk was inserted, the desktop file was automatically opened and put in the list of resource files. Within this time that the file was open, the WDEF file which existed within was executed (the system needed to draw the window itself using the standard WDEF resource). This method requires no patching of other code and makes it very elegant. The thing that makes them easy to detect is that you find code resources in very odd places. A WDEF resource is not usually found in the desktop file.

To find other hooks for code execution, look at all the executable code inside the system. These pieces are executed at one time or another for certain calls. Things that might not seem obvious right away may make good places for patching. Lots of applications use (maybe indirectly) the International Utilities Package, for it has many good string manipulation routines. A patch there might be possible. 'ptch' resources in the system are loaded automatically at startup time to patch bits of ROM. A system could be infected there and be loaded before all other extensions. Poke around the resources and find out which ones are executable, and then find out when they are executed. You might be able to find a great patch to live off of.

Chapter 4: Reproduction

Reproduction of any code resource requires the help of the File Manager and/or the Resource Manager. The concept is not very simple, but the execution is very easy. Since the virus itself is simply one code resource (preferably not more than one), then it can be loaded, added, modified, changed, and saved just like any other resource. And the fun part of it is, you can do all this to the code you are currently executing. This is apparently dangerous (Apple warns us about self-modifying code), but we're not modifying anything about our code; simply our placement. With a few simple calls we can duplicate ourselves anywhere we wish.

When an executable code resource is called, the pointer to the resource is placed in register A0. You can use this pointer to reference yourself. A simple line of assembly can place A0 in any variable you choose. Once you have this variable, you must translate it into a handle with the RecoverHandle call. Now you have a handle to your own loaded resource, but you still cannot duplicate it. As a handle to a resource, you cannot use it to be copied into other files. You 'belong' to your owning file, and are not expected to go elsewhere. Use the DetachResource call to remove your reference to the file you came from. After this call, you are simply an executable block of memory floating around with a handle on yourself (phallic, isn't it?). All you need to have to have total freedom with a block of memory is a handle to it. You've got this free handle now. Now comes the time to find the file you have to duplicate yourself to.

The file you find depends on how your virus is designed to work. You can copy yourself into applications, into desktop files, or into the system. Again, dependent on how your executing mechanism requires it. Once you have found your file (usually with use of the File Manager), open up it's resource fork with OpenResFile or any other similar procreation of it (FSpOpenResFile, etc.). Call AddResource with the required parameters, then call WriteResource to forcefully write the resource to the file or simply close the file itself (it will automatically be saved). Your code has now copied itself into another file. Reproduction! Now just let it sit and wait for it to be called!

Chapter 5: Defensive, Clean Coding

As always, if you want your code to be run cleanly on all systems, you have to be prepared for any type of situation. Apple warns us of this all the time, so I don't have to go into too much detail, but there are a few things I would like to stress so that your code doesn't simply crash when it gets executed. You goal is then not found. Here are some tips and things to watch out for.

1. ResError. Who knows? Maybe you've been purged. Check it after every Resource Manager call you can, taking efficiency into account, of course.
2. Nil pointers. Who knows? Maybe a virus detector caught part of your set of resources (if you're using a set, which I highly discourage) and deleted them. Find an alternate route, or exit gracefully.
3. Patch well. If you are going to modify something like a jump table, be sure you keep the originals somewhere for your own use so you can call the code (pass-through coding). If you don't, and you just destroy it and call the next code resource down the line, who knows what you might be calling. A bezier-curve calculation routine does nothing if the caller knows not what he's doing.
4. File Manager. Don't depend on each hard drive being called "Macintosh HD". Don't depend on an "Applications" folder. Don't depend on anything. Read the directory and see what you find interesting. System 7's File Manager is great, but watch out for:
5. System 6 or before. You wouldn't want your code to execute only on one system version now, would you? By known figures, only 50% of Mac users use System 7. Sad, eh? But why exclude them from the pleasures of your code?
6. Error Check, Error Check, Error Check. The thought police are on you again. Never forget that nothing is permanent.

Chapter 6A: Virus Protection Software: How It Works

Virus protection software was a good idea. It worked for a while. Then it became a commercial product. Virex, SAM, etc. The best one out in the world today is freeware: Disinfectant. A beautifully-written piece by John Norstad. I personally am against commercially-written virus protection. However, I am not here to give praise to independent software authors. I am here to tell you how some of their mechanisms work.

Patching toolbox traps is a popular method of modifying the system's own code. Before it calls the real thing, it calls the patch (your code). Virus detectors use this method to keep an eye out for parameters passed through certain toolbox calls to check to see if they are virus-related.

One popular patch is AddResource. If a virus detector sees that the type of resource that is being added is of type 'nVir', then it'll catch you. If it sees 'WDEF' with ID=0 and the open resource file is the desktop, then it'll catch you. Since AddResource is a very dependent call used for replications, it's almost certain to work every time. Other less-popular but more efficient patches are those at the base level of the operating system, not even documented by Apple. Traps such as _vBasicIO, _VInstall, _NewHandle, _vMRdAddr, and even _ADBReInit get trapped by the Disinfectant extension. Because these are very basic calls (used by nearly anything that does input and output, in the case of _vBasicIO), it can catch nearly anything coming toward it. It's nearly foolproof. After knowing what type of virus it is, the software can delete the virus quickly and easily.

Good applications also use their own version of virus protection. At the startup of their application, the number of resources in the file is counted, and the more important executable resources in the file are checked for their size. This way, if an application has had a resource added, it will be able to alert the user and stop execution.

Chapter 6B: Virus Protection Software: How To Bypass It

Though virus protection is great in most cases, there are still 'back doors' which haven't been explored at the time of this writing. Here are some ideas for getting around the checks that most virus protection software uses.

A trap is still a trap. It is not the real code; it is a dispatcher. It stops you on the way there, but it doesn't stop you from doing what those basic calls do on your own. This does require a fair amount of assembly language and ROM copying, but it gets you around the catch of using operating system traps at all. Simply copy the code that is contained in the trap itself and use that code. To never get caught, never use traps. But we know how nearly impossible that is. However, things are gained and lost in good code writing.

A drawback of virus protection in general is that the software has to be continually updated for each new virus and identified by name in most cases. One ingenious idea (mine? I don't know) is to make the name and/or type of the virus variable. It doesn't always have to be called 'nVir' or 'WDEF' (unless the mechanism depends on the name or type). Make the type change from permutation to permutation. This makes it much more difficult to catch.

One feature of the File Manager is it's automatic updating of the modification dates. Every time a file is updated or modified in any way, the modification date is changed. You can find and modify the date with a fairly simple low-level File Manager call. This is really a frivolous precaution, but it makes it easy to find the source of a virus attack. Changing the dates to something fairly feasible (NOT Jan. 1, 1904) may bypass such checks.

The application checks can be overridden with good code-writing as well. If the virus is to add a resource to a file (as it usually has to), why not delete one in it's place? You've got to be sure that the type is the same as another type (this is where the variable types come in handy), and you may even want to vary the size of it to make it match the one it replaced (hopefully a larger size). Simply modifying a resource (like CODE 0) with the same amount of bytes will usually not be detectable. This way, the applications still counts and finds nothing unusual. However, in the process, the application is permanently damaged in some way.

Chapter 7: Testing

In testing a virus on your own system, you subject it to many continuous attacks - maybe even ones that are unintended. There are some rules to follow to be sure that you can keep track of it's location and make sure it doesn't destroy your work in the process.

1. SysBeep debugging. I'm sure most of us a pretty familiar with this technique. It's compatible on all systems, and it's an aural identification. No visuals to set up, no extra resources. Simple SysBeep(0); is sometimes enough to know that everything's all right. When testing your duplication code to find out when it actually happens, use SysBeep after each one and then check to see where it went.
2. Modification dates and times. If you use random selection of files to infect, it becomes rather difficult to find which one got infected. If you know when an infection happened, you can immediately check the modification dates of all files - simply by using the Find command in System 7's Finder.
3. Text Files. This could be known as a common-file technique. For testing purposes, use a mechanism that whenever an infection takes place, the virus writes the process and the file names and such into a common file in a common folder somewhere. This way, you can check the text file afterwards and know exactly what your code has done. You need not make the mechanism too elaborate, as it will only be for use in testing.
4. Backup, Backup, Backup. The thought police are at it again. In these cases, it's all too familiar. A trashed project is no fun.

Chapter 8: Conclusion

In short, the devices behind writing a virus are not all that complicated. There are many checks to counterattack, and part of the puzzle itself is no find new ways to get around them. Find back doors. Give the code a personality. Make it try to find the best way around a counterattack if it is able to detect one. Size is no longer a constraint in today's memory-hog world. A virus of near 50k would probably go undetected in modern-day storage, so don't feel constrained in that way. Time should be a consideration, however.

Make code that is efficient, so that users don't notice a slowdown when it is executed. All in all, your code is your work. Don't let it out of the bag until it works well and clean, and don't forget to leave no trace.

SUNSET AND A CONCLUSION

We arrived at the beach at about 6.30 in the evening. My cousin parked the car under a tree and we got out.

The smell of the sea was unmistakable. A gentle breeze blew. I step out my sandals onto the soft sand, like i was in heaven.

My cousin, two of my friends and i had come to the seaside just to watch the sun set. My cousin assured us that we would not be disappointed for he had seen it setting before and he said it was beautiful. We just had to see for our own.

We sat on the sand and gazed at the western horizon. White and grey clouds began to change colour.

First they took on orange hues. Then the shades of red and yellow could be seen. In the short time the whole western sky seem to be ablaze with splash of gold, red ,orange and yellow. I gazed at the spectacle in wonder. What a magnificent sight it was! I tired to focus on a particular part of the colourful scene but I found that the colours were constantly changing. They changed very slowly and subtly although the scene appeared very still. A streak of gold here turned yellow and a splash of red there dissolved into hues of orange. It was quite impossible to describe really this great wonder of nature in action.

Shortly the hues became darker and hits of black were visible. The sun slowly sink into the sea. However the sky remained reddish even though the sun could no longer be seen.

Suddenly, everything was dark. The sun had set and night took over. I became aware of mosquitoes attacking me. My cousin said it was time to go home.

We got into car. Indeed the sunset had been a wonderful experience. At that day, I had a conclusion that is --wonderful time is just a second, so we must appreciate it. Don't let it pass away in a meaningness way~~~~~

JUST ONCE...

I did my best

But I guess my best wasn't good enough

'Cause here we are back where we were before

Seems nothing ever changes

We're back to being strangers

Wondering if we oughta stay

Or head on out the doorJust once can't we figure out what we keep doing wrong

Why we never last for very long

What are we doing wrong

Just once can't we find a way to finally make it right

Make the magic last for more than just one night

If we could just get to it

I know we could break through itI gave my all

But I think my all may have been too much

'Cause Lord knows we're not getting anywhere

Seems we're always blowing whatever we got going

And seems at times with all we've got

We haven't got a prayer

Just once can't we figure out what we keep doing wrong

Why the goodtimes never last for very longSeems we're always blowing

Whatever we got goingJust once can't we find a way to finally make it right

Make the magic last for more than just one night
If we could just get to itI know we could break through it
Just once I want to understandW
hy it always come back to good-bye
Why can't we get ourselves in hand
And admit to one another
That we're no good with out the other
Take the best and make it better
Find a way to stay together
Just once can't we find a way to finally make it right
Make the magic last for more than just one night
I know we can break through it
If we could just get to it
Just once
If we could get to it
Just Once...

Student Study Just To Pass Examinations. Do You Agree?

I agree fully with the above statement. I am a student and I study just to pass the examinations. It seems the same with my schoolmates. We are all only concerned with the examinations. We do not study other things that do not require us to sit for examinations.
The reason that we do not study other things is because we have no time for them. School subjects take up all our time in school and much of our time in school and much of our time of school. Everyday we have to learn so many things whether we like it or not. Lesson continues one after the other with hardly a break. Our brains switch from history to geography to mathematics to science with a speed of light. We manage most of the time, but sometimes it get so tiring to study, and many of us think to put off our study. For me, any initial interest I have in any subject is quickly killed off by the sheer amount of information I have to absorb. No one is allowed to learn his or her own pace. Everyone is force-fed a diet of information regardless whether he or she can cope with it or not (haiz…so pity the one’s who study…).
Then there is always the next examination around the corner. Since very young we have been taught this: passing with flying colors an examination is the best, just passing it is just a normal statement, but failing is very bad indeed. We are expected to pass. Our parents, teachers and all grown-ups applaud us when we pass with flying colors. If we pass they say nothing, but when we failed we are made to fell worthless. I myself have been caned by my mother because I got red marks in my report card (but in secondary I have improved better!).
No one wants to be considered worthless or be punished for failure, but that is what the world is. So we become obsessed with examinations. We study because we do not want to fail. I have heard some teachers’ say that we should study to acquire in my years in school is that if I fail I am finished. I have to pass with flying colors to prove that I am not worthless.
That is how I feel. For some of my classmates who cannot cope well with the workload, they simply give up studying in some subjects. They are already marked as failures by the teachers so they see no point in studying anymore ,but some teacher always teaches them, help them on their homework, support them but the hard work seems have no effect on them, maybe they are meant to failed. Lucky I do not fall in that category. I still study and do my homework as diligently as I can, but I do these things with only one thing in mind and that is: I have to pass my examinations with flying colors.
So the students study very hard indeed. Passing means success in the world. Failure is unspeakable. The fact remains that they study not for the sake of knowledge but only so that they can pass the next examinations. I am no different from them.

Should Homework Be Abolished?

It is very easy to answer ‘yes’ to the above question, especially when one is loaded with homework up to the neck. However I will not say that homework should be abolished. It is useful in many ways, I will say that homework should be given discreetly.
Every teacher ought to realize that other teachers are also giving homework. So if five different teachers come into the class and all of them give us homework, then we will have five different sets of homework to do!
It is already a full-time job concentrating on what each teacher tells us in class. So by the time we reach home, all we want to do is to flop into bed and take a nice nap. The nap normally is filled with dreams about unfinished homework and question. After lunch it is usually back to work trying to finish the assignments or folio projects before evening comes and we go out to play or rest for a while.
However, the homework cannot be done in one sitting. This is especially so when we get stuck in mathematics problem and can see no way through. So after homework and try to do work once again to complete the homework and try to do some studying as well. Sometimes the going gets so overwhelming that the only sane thing left to do is to quit and do some-thing else, like watching television or playing computer games(example from me ,hacking, cracking, surfing the internet.)
This year, “fortunately”, most of our teachers are very “understanding”. They realize that we are sitting for the PMR examinations. So they give us homework. Our geography teacher is the best, his name was Mr. Ooi Chong Oui. He seldom give us homework and he always ask us the time (example: “what time is it now?” say Mr. Ooi. Then a student reply: “it is only left 5 minutes Sir” then he continue: “ok you all can rest now”. What a “wonderful” teacher we thought. ) Bless him for his kindness.
Science is an entirely different matter. Our teacher believes us in grinding us with as many problems as possible. I “appreciate” the fact that practice make perfect in science. However I wish that she could take it easy a little bit so that we do not feel so tense and overworked. It is necessary to do homework in science but it is unnecessary to do excessive amounts of it. This is where the discretion of the teacher is most important. But who am I to comment on what is considered discreet or not? It is totally up to the teacher. Many of my classmates hate science because all the homework that the teacher gave. Thus many of them failed at the test (but not included me because I pro at science. Hehe….). They simply not bothered anymore with it. They just sit quietly every time they are chastised and punished by the fuming teacher for not doing her homework (example of her punishment: “do you have heart attack or asthma?” as her. “No” the student reply. “ok now pumping 10 times” continue by her. ). They show no concern at all for the result.
Doing homework is never a pleasant affair. If the volume of homework is manageable then they can be done efficiently and quickly. In this way we do learn from our labour. If the homework is overwhelming then we learn nothing expect that we are simply fed up. I believe then that we should not abolished homework completely. The best thing to do is for the teacher to seriously consider the student’s welfare before any homework is given. Homework should be aid the student to learn not do the opposite. Homework look like food, if taken in moderate quantities, it nourishes, but if taken in excessive amount, it might kill person.(but I hope there will be no homework given by the teachers again, and all the exam also should be abolished. Hahaha…)

ENCRYPTE

In cryptography, encryption is the process of transforming information (referred to as plaintext) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key. The result of the process is encrypted information (in cryptography, referred to as ciphertext). In many contexts, the word encryption also implicitly refers to the reverse process, decryption (e.g. "software for encryption" can typically also perform decryption), to make the encrypted information readable again (i.e. to make it unencrypted).
Encryption has long been used by militaries and governments to facilitate secret communication. Encryption is now used in protecting information within many kinds of civilian systems, such as computers, networks (e.g. the Internet e-commerce), mobile telephones, and bank automatic teller machines. Encryption is also used in digital rights management to restrict the use of copyrighted material and in software copy protection to protect against reverse engineering and software piracy.
Encryption, by itself, can protect the confidentiality of messages, but other techniques are still needed to verify the integrity and authenticity of a message; for example, a message authentication code (MAC) or digital signatures. Standards and cryptographic software and hardware to perform encryption are widely available, but successfully using encryption to ensure security is a challenging problem. A single slip-up in system design or execution can allow successful attacks. Sometimes an adversary can obtain unencrypted information without directly undoing the encryption. See traffic analysis, TEMPEST.

History
Encryption has been used to protect communications since ancient times, but only organizations and individuals with extraordinary need for confidentiality had bothered to exert the effort required to implement it. Encryption, and successful attacks on it, played a vital role in World War II. Many of the encryption techniques developed then were closely guarded secrets. (Kahn) In the mid-1970s, with the introduction of the U.S. Data Encryption Standard and public key cryptography, strong encryption emerged from the preserve of secretive government agencies into the public domain.

Ciphers
In cryptography, a cipher (or cypher) is an algorithm for performing encryption and decryption — a series of well-defined steps that can be followed as a procedure. An alternative term is encipherment. In most cases, that process is varied depending on a key which changes the detailed operation of the algorithm. In non-technical usage, a "cipher" is the same thing as a "code"; however, the concepts are distinct in cryptography. In classical cryptography, ciphers were distinguished from codes. Codes operated by substituting according to a large codebook which linked a random string of characters or numbers to a word or phrase. For example, UQJHSE could be the code for "Proceed to the following coordinates".
The original information is known as plaintext, and the encrypted form as ciphertext. The ciphertext message contains all the information of the plaintext message, but is not in a format readable by a human or computer without the proper mechanism to decrypt it; it should resemble random gibberish to those not intended to read it.
The operation of a cipher usually depends on a piece of auxiliary information, called a key or, in traditional NSA parlance, a cryptovariable. The encrypting procedure is varied depending on the key, which changes the detailed operation of the algorithm. A key must be selected before using a cipher to encrypt a message. Without knowledge of the key, it should be difficult, if not impossible, to decrypt the resulting cipher into readable plaintext.
Most modern ciphers can be categorized in several ways:
By whether they work on blocks of symbols usually of a fixed size (block ciphers), or on a continuous stream of symbols (stream ciphers).
By whether the same key is used for both encryption and decryption (symmetric key algorithms), or if a different key is used for each (asymmetric key algorithms). If the algorithm is symmetric, the key must be known to the recipient and to no one else. If the algorithm is an asymmetric one, the encyphering key is different from, but closely related to, the decyphering key. If one key cannot be deduced from the other, the asymmetric key algorithm has the public/private key property and one of the keys may be made public without loss of confidentiality. The Feistel cipher uses a combination of substitution and transposition techniques. Most (block ciphers) algorithms are based on this structure.

Etymology of "cipher"
"Cipher" is alternatively spelled "cypher"; similarly "ciphertext" and "cyphertext", and so forth. It also got into Middle French as cifre and Medieval Latin as cifra, from the Arabic sifr (zero).
The word "cipher" in former times meant "zero" and had the same origin (see Zero - Etymology), and later was used for any decimal digit, even any number. There are these theories about how the word "cipher" may have come to mean encoding:
Encoding often involved numbers.
Conservative Catholic opponents of the Arabic numerals equated it with any "dark secret".[citation needed]
The Roman system was very cumbersome because there was no concept of zero or (empty space). The concept of zero (which was also called "cipher"), which we all now think of as natural, was very alien in medieval Europe, so confusing and ambiguous to common Europeans that in arguments people would say "talk clearly and not so far fetched as a cipher". Cipher came to mean concealment of clear messages or encryption.
The French formed the word "chiffre" and adopted the Italian word "zero".
The English used "zero" for "0", and "cipher" from the word "ciphering" as a means of computing.
The Germans used the words "ziffer" and "chiffer".
Dr. Al-Kadi (ref-3) concluded that the Arabic word sifr, for the digit zero, developed into the European technical term for encryption.

Ciphers versus codes
In non-technical usage, a "(secret) code" is the same thing as a cipher. Within technical discussions, however, code and cipher are distinguished as two concepts. Codes work at the level of meaning — that is, words or phrases are converted into something else and this chunking generally shortens the message. Ciphers, on the other hand, work at a lower level: the level of individual letters, small groups of letters, or, in modern schemes, individual bits. Some systems used both codes and ciphers in one system, using superencipherment to increase the security.
Historically, cryptography was split into a dichotomy of codes and ciphers, and coding had its own terminology, analogous to that for ciphers: "encoding, codetext, decoding" and so on. However, codes have a variety of drawbacks, including susceptibility to cryptanalysis and the difficulty of managing a cumbersome codebook. Because of this, codes have fallen into disuse in modern cryptography, and ciphers are the dominant technique.

Types of cipher
There are a variety of different types of encryption. Algorithms used earlier in the history of cryptography are substantially different from modern methods, and modern ciphers can be classified according to how they operate and whether they use one or two keys.
Historical pen and paper ciphers used in the past are sometimes known as classical ciphers. They include simple substitution ciphers and transposition ciphers. For example GOOD DOG can be encrypted as PLLX XLP where L substitutes for O, P for G, and X for D in the message. Transposition of the letters GOOD DOG can result in DGOGDOO. These simple ciphers are easy to crack, even without plaintext-ciphertext pairs.
Simple ciphers were replaced by polyalphabetic substitution ciphers which changed the substitution alphabet for every letter. For example GOOD DOG can be encrypted as PLSX TWF where L, S, and W substitute for O. With even a small amount of known plaintext, polyalphabetic substitution ciphers and letter transposition ciphers designed for pen and paper encryption are easy to crack.
During the early twentieth century, electro-mechanical machines were invented to do encryption and decryption using a combination of transposition, polyalphabetic substitution, and "additive" substitution. In rotor machines, several rotor disks provided polyalphabetic substitution, while plug boards provided transposition. Keys were easily changed by changing the rotor disks and the plugboard wires. Although these encryption methods were more complex than previous schemes and required machines to encrypt and decrypt, other machines such as the British Bombe were invented to crack these encryption methods.
Modern encryption methods can be divided into symmetric key algorithms (Private-key cryptography) and asymmetric key algorithms (Public-key cryptography). In a symmetric key algorithm (e.g., DES and AES), the sender and receiver must have a shared key set up in advance and kept secret from all other parties; the sender uses this key for encryption, and the receiver uses the same key for decryption. In an asymmetric key algorithm (e.g., RSA), there are two separate keys: a public key is published and enables any sender to perform encryption, while a private key is kept secret by the receiver and enables only him to perform decryption.
Symmetric key ciphers can be distinguished into two types, depending on whether they work on blocks of symbols of fixed size (block ciphers), or on a continuous stream of symbols (stream ciphers).


Key size and vulnerability
In a pure mathematical attack (i.e., lacking any other information to help break a cypher), three factors above all, count:
Mathematical advances, that allow new attacks or weaknesses to be discovered and exploited.
Computational power available, i.e. the computer power which can be brought to bear on the problem.
Key size, i.e., the size of key used to encrypt a message. As the key size increases, so does the complexity of brute search to the point where it becomes infeasible to crack encryption directly.
Since the desired effect is computational difficulty, in theory one would choose an algorithm and desired difficulty level, thus decide the key length accordingly.
An example of this process can be found at keylength.com which uses multiple reports to suggest that a symmetric cypher with 128 bits, an asymmetric cypher with 3072 bit keys, and an elliptic curve cypher with 512 bits, all have similar difficulty at present.
Claude Shannon proved, using information theory considerations, that any theoretically unbreakable cipher must have keys which are at least as long as the plaintext, and used only once: one-time pad.

poem out of a colour words

Once bitten, twice SHY.

Twice bitten, never TRY.

Thrice bitten, go and DIE!

by wei ping