Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
Well, a dissasembler just take apart a program and shows it to you in hex values and the like. The source code is the actual programming such as C++ or ColdFusion, whatever it was written in. The probably couldn't have goten the algorithm from disassembleing it, but they probably could have found the key, depending on how encrypted the code was. But they're experts, I don't think they would have had a lot of trouble.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Disassemblers reduce an executable file to its individual machine-code instructions (i.e. assembly language). Those "hex values" represent "opcodes" (operation codes) that correspond to machine instructions at the most basic level, such as "JMP" to jump the execution flow to a specific memory address (for branching and looping), where the next machine instruction should be found, or "PUSH" and "POP" instructions to store/fetch data in memory registers.
These instructions are not as "readable" as higher-level programming languages like C, but a programmer can still use these instructions to recreate the algorithm (programmers today still read and write assembly language code for special purposes and reverse-engineering other people's algorithms). In effect, the machine instructions (like any form of source code) are just the implementation of an algorithm.
The key, on the other hand, would not have been discernable through a disassembly of the program. The key in a cryptographic system is usually used as input to the function, and would not be hard-coded anywhere in the program itself. (Otherwise it would be even more trivial to obtain and use.)
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
It wouold have to be, otherwise how would the program know what it was looking for. It's like a registration key, if the value you input is equal to AfhAgjFDSe256W46nS then set it to unlock, or decrypt. If it wasn't hardcoded anywhere then how would it know that AfhAgjFDSe256W46nS unlocks the program and FsdhwgStyhr534ASf3257 doesn't? An algorithm is a set of commands that execute based on the input. That way you can have multiple keys and not one certain key that could unlock any program with that encryption. It would almost HAVE to be in there somewhere. Perhaps extreemly hard to find, but it is still possible.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
No, that's not how modern encryption works. You don't embed the key in the program itself and match it against the user's input. The algorithm that the program implements is just a kind of translator (hence "TRANSLTR"). It takes as input the key and the text to be translated, and uses the algorithm to generate a result. If the key happens to be the *right* key, then the result is the encrypted or decrypted output we want; if you use the wrong key, you still get output, it's just that the output is gibberish because it was "mistranslated".
A simple example might help to clarify this. Suppose that the key were "BXDV", and we wanted to encrypt the phrase "HELLOTHERE". Having the just the key doesn't help us--we need to know what algorithm to use to do the encryption, i.e. how to *use* the key.
Suppose that our algorithm is a simple one: the ordinal value of the character in the key is added to the ordinal value of the character in the plaintext, in a modular way. In other words, we repeat the key over and over again until it matches the length of the plaintext, so if the plaintext were "HELLOTHERE" (10 characters), we'd repeat the 4-character key 2.5 times ("BXDVBXDVBX"). Then we'd add these letters to the plaintext, and any characters that end up larger than "Z" get wrapped around to the beginning of the alphabet. The first character of our encrypted output would be H+B = J, the second would be E+X = C, and so on:
HELLOTHERE
+BXDVBXDVBX
----------
JCPHQRLATC
The encrypted output would be "JCPHQRLATC".
Now, put yourself in the position of the person doing the decrypting. You can know the algorithm, and you can even know that the key is 4 characters long, but they key itself is still necessary to do the decryption. The key is not hard-coded in the algorithm anywhere (or in any implementation of the algorithm, compiled or otherwise)--the algorithm merely explains how to *use* the key. If you know that the key is "BXDV", and the ciphertext is "JCPHQRLATC", and you know the algorithm that was used to encrypt it, you can use that algorithm in reverse to obtain the plaintext:
JCPHQRLATC
-BXDVBXDVBX
----------
HELLOTHERE
Now, suppose you didn't know the key, and you decided to use brute force to figure it out. You know that the algorithm is expecting a 4-character key, so you decide to try "AAAA", "AAAB", "AAAC", and so on, until you find the correct key. When you try "AAAA", you get this:
JCPHQRLATC
-AAAAAAAAAA
----------
IBOGPQKZSB
When you try "AAAB" you get this:
JCPHQRLATC
-AAABAAABAA
----------
IBOFPQKYSB
The "right answer" is not hard-coded in the algorithm anywhere (or in any implementation of that algorithm, compiled or otherwise)--that's precisely why the algorithms were designed the way they are.
When you do your brute-force analysis and eventually get to testing "BXDV" as your key, you'll get "HELLOTHERE", but remember that to a computer this is just a translation task--it considers *all* of the output equally reasonable (or unreasonable). Of the 456,976 possible keys (26^4) for this algorithm, only one will produce "HELLOTHERE", but how does the computer know that "HELLOTHERE" is the "right answer"? It doesn't--it needs more information to do that.
To determine which of the 456,976 different outputs is most likely to be the "right answer", it has to make some assumptions about the language the document was written in, and look for dictionary words in the result. If we had assumed the original text was written in English, we'd be using an English dictionary, and spotting the pattern "HELLO" or "THERE" would cause that result to score more highly than the others. Through random chance, some of the other mistranslations may still contain accidental patterns (e.g. "DXGCATCHGW" contains "CATCH"), but we expect the most matches to occur in the properly translated version.
In short, the algorithm and the key are *always* independent of one another. The algorithm only specifies the parameters of the key--how long it needs to be (4 characters in our example), and what range of values it can contain (letters A-Z in our case).
There's no built-in, hard-coded key value to match against, and this makes the same algorithm usable by many different people--they can each have their own key, but use the same algorithm. That way if Alice wants to send an encrypted e-mail to Bob, she can use key "JWHS", and if Carol wants to send Dan an encrypted e-mail she can use key "OWLS". Both senders can use the same algorithm to do the encryption, but because they're using different keys they generate different ciphertext (even if their plaintext was identical). If the key were somehow hard-coded into the algorithm, everyone using that algorithm would have to use the same key 
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
::light clicks above head:: I get it now, I'm stupid ^_^ I was thinking more along the lines of registration keys, there has to be some list of those to work. Duh. Thanks for the explaination.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Registration keys are something different, yes, but there's still no requirement that there be any "list" of valid registration codes.
Many software packages that ask for a registration code ask you for some other piece of information--a "registration name", "serial number", or "registration ID". That value is used as input to a function that performs a one-way mapping to a registration code. When you enter the registration code, the software just compares what you typed to the result it got from the one-way mapping.
Again, a simple example might help. Suppose that the program prompts you for two values: (1) your name, and (2) your registration code. You enter "John Smith" for the name.
The program will use an algorithm that does something with "John Smith" to determine what the corresponding registration code should be. Perhaps the algorithm just adds up the ordinal values of each of the characters (A = 1, Z = 26, spaces and punctuation = 0, etc.) and sums them together:
J = 10
O = 15
H = 8
N = 14
S = 19
M = 13
I = 9
T = 20
H = 8
---------
116
The program essentially uses some piece of input (in this case your "registration name") to compute what the matching registration code should be. Here, with this simple algorithm, "John Smith" would need to use a registration code of "116" to match properly (it's called a "one-way function" or "hash" because the algorithm only works in one direction--there's no way (or too many ways) to get "John Smith" from "116").
Obviously real software protects itself with more complicated algorithms, sometimes using serial numbers from some of your hardware components, or the machine's network name/address or somesuch as keys to help obscure things. That said, there's still no "list" of valid codes stored in the program.
Encryption used this way just relies on the obscurity of the algorithm itself--as long as you don't know how to convert "John Smith" into the proper registration code, it's secure. The folks who crack software like this don't use brute-force decryption techniques (though they could, if they had some idea what the parameters of the valid registration codes were, e.g. length, alphabet, etc.). It's usually far quicker and easier to run the program through a disassembler and locate the instruction sequence that gets performed on the input. Once you know what gets done to the input, and in what order, you essentially have the algorithm, and can generate registration codes for any arbitrary input thereafter. That's why this kind of so-called "security through obscurity" is considered extremely weak in the computer security business.
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
Oh, ok, I see now. So much I didn't understand (some much I still don't understand), and just assumed. I guess that's what I will be going to college for, eh?
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
Now, in Brown's version, the "pass-key" that Tankado's program is asking for all but certainly *was* hard-coded into the program itself, since there was no other user input available to generate a matching code. The program only prompted for one thing--the pass-key. There was no "registration name" or "ID" or "serial number" or additional "access code" that could have been used to algorithmically create the matching pass-key.
Since in Brown's version the pass-key had to be encoded in the program itself, it's a bit silly that the NSA folks weren't able to determine it directly after disassembling the program. Remember the scene near the end with the coders rushing in with the disassembled code? Soshi runs in and says, "We isolated the worm's execute commands--have a look at the programming! Look what it's planning to do!" They had obviously just disassembled the program and reconstructed its algorithm. Having done that, the hard-coded pass-key should have been trivial to spot.
|
Skate
newbie
Reged: 05/23/04
Posts: 39
Loc: Ohio, U.S.
|
|
Yea, that is true, unless the pass key was somewhere on the web and the program accessed that site. It is possible that they might have overlooked that, although it is doubtful.
|
Arras
enthusiast
Reged: 05/24/04
Posts: 263
Loc: B.C., Canada
|
|
True, it could have been located elsewhere, but in that case they'd have seen that fact in the disassembled code, which would have to have the website or IP address/port number in it somewhere. One way or another, disassembly of the program would give everything away.
Of course this and other cryptography-related plot-holes throughout the book could be semi-intentional on Brown's part, for a variety of reasons:
(1) He's trying to take a very dense and complicated subject and reduce it to something simple enough for someone without a degree in mathematics or computer science to grasp. Inevitably when this happens some of the detail is lost, as things get oversimplified.
(2) He's writing with movie rights in mind. This book would be trivial to adapt for the screen, and there are some sections in particular that strongly suggest that Brown was thinking about this from the start. Consider the climactic scene in the control room, where the "vis-rep" provides a real-time animated display of hackers making their way past defenses and closer to the NSA databank.
(3) Brown may have been trying to intentionally keep things at a relatively abstract level so as not to give wrong-minded readers dangerous information. This is common in books that discuss things like how to build a nuclear weapon, etc. Keeping the technical details at an abstract level with just some 'teasers' of detail is often a conscious decision on the writer's part.
(4) It's possible he simply made mistakes. My sense is that he does not understand modern cryptography very well. He seems well-versed in classical cryptosystems, but his claim that it all started with Caesar is patently false, which makes me question the rest of his cryptological knowledge. The book's acknowledgements suggest that he consulted with a couple of ex-NSA cryptographers, and while I'm sure they provided some details to add realism to his story, the value of their information is proportional to the quality of the questions Brown asked of them (and what they felt they were able to divulge, even anonymously). Important facts could well have been left out, and Brown may not have known the subject well enough to recognize the holes in his story these omissions would leave.
In the end, the story remains enjoyable in spite of these holes, and most readers won't even notice them. It's only a tough read for those who know the subject matter well enough to spot the technical inaccuracies. But then, that's where the educational opportunities lie, right? Forums like this one let people ask the "is this really possible" question, and get answers from those who have them. Self-enrichment opportunities for the curious
|
|
Previous
Index
Next
Threaded
[Re: 
Edit
Reply
Quote
