Slashdot Mirror
Researchers Seek Help Cracking Gauss Mystery Payload
An anonymous reader writes "Researchers at Kaspersky Lab are asking the public for help in cracking an encrypted warhead that gets delivered to infected machines by the recently discovered Gauss malware toolkit. They're publishing encrypted sections and hashes in the hope that cryptographers will be able to help them out."
Adds reader DavidGilbert99: "The so-called Godel module is targeting a specific machine with specific system configurations, and Kaspersky believes the victim is likely a high-profile target. The decryption key, Kaspersky believes, will be derived from these specific system configurations, and so far it has been unable to find out what they are."
What did you guys put in it, again?
What political party do you join when you don't like Bible-thumpers *or* hippies?
It's Cthulhu, he's in our Internet, eating our code!
Beware!
why these things are hard to decrypt? They're computer programs. The computer has to be able to decrypt them to run them. So either the computer has the key, doesn't need the key, or the key is going to be delivered to it later.
So I'm assuming the authors sent the payload and will be activating it later when they send the decryption key? Otherwise, this shouldn't be such a big deal to figure out. There's no reason to need to break the encryption if the key is IN the payload or in the malware shell.
The only time where this sort of thing works is in places like the sat boxes, where they've hardcoded the key in a chip that uses its hardware engine to decrypt data. In that case you have to physically get the key from the chip itself with a purpose-built microscope. But that sort of defense isn't possible with a purely-software thing like this. (I read today that's also what the iphone is doing, and I assume other smart-devices like crackberries)
I work for the Department of Redundancy Department.
If the DOJ and NSA can't get into an Apple iPhone, what chance is there of cracking this?
Sorry, but gray text on gray background is making my eyes bleed.
Clever of the tech world, to obsolete CRT monitors. Perhaps shaking one's head rapidly from side to side would help solve this mystery.
I just ran the code and something about my system is causing it to decrypt, and it appears be tr***CARRIER LOST***
Place nail here >+
It looks like validation of one of my first creation irc bot (war bot, for taking over channels, not for spamming people and stealing their CCs).
It was also doing validation, to verify it binary has not been altered using MD5 and some kind of computation of the binary itself.
And then it was loading a userfile (payload), which was ecnypted using system specific key. In my case it was a physical location of a file on a disk (i-node, blocks, etc.. all you could get from file info syscall), nicely md5 hased to get good blowfish key.
The userfile contained list of people (ident@host.com) with their rights, and passwords for their accounts + information about how to link to the botnet...
I am pretty sure here you have the same thing, so. do I get candy as a reward?
"Be sure to drink your Ovaltine."
The reason the payload exists is so that it can be decrypted and used. Both the algorithm and the key are in there somewhere. The problem is discovering under what conditions it is exercised and halt the process after the decryption but before the key is removed from memory. Timing is the key to success.
Load the code in a hardware virtualization monitoring environement with an emulated CPU clock and let it run. Analyse the code execution and discover the branches not taken and then force it to take each branch the next time around, and watch/trace what it does. If you find ant-debugging protections along that path then you are probably on the right track to recover the key. There is no singular trick in their little-black-bag-of-tricks that can't be worked around. Be persistant and the key will be recovered, and a lot sooner than trying to brute-force decrypt the payload without the key.
Never overlook the obvious. Want to piss off a small security team? Put a small sample of /dev/urandom into a binary blob and release it. They'll spend all their time trying to decrypt that white noise source and never notice the Really Interesting thing nearby it.
Researchers at Kaspersky Lab ... publishing encrypted sections and hashes
Ha ha they fell for it. The interesting stuff is going to be around or nearby the distractor, not the distractor itself.
This part makes no sense:
They're publishing encrypted sections and hashes in the hope that cryptographers will be able to help them out.
If that happens it'll be a first in the serious crypto field. How do they expect that to happen? This being from a worm or whatever doesn't make it special.
Look I'll give you a baby example.
"13cbffe03010f846f46f123675bfc3c3"
I'll even make it more baby by telling you its a md5 hash and the plaintext is 11 chars of letters and spaces. The ultimate in baby examples and its still utterly hopeless.
P.S. its not a rickroll URL although that would be funnier than hell. The only thing funnier than the worm designers using /dev/random would be embedding a rickroll or a goatse instead of real worm payload.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
According to Kaspersky, the way it works is:
1) Enumerate all directories in the computers PATH variable
2) Enumerate all files in the %PROGRAMFILES% directory whose file name starts with a non-latin-alphabet unicode character (i.e. arabic)
3) Hash every pair from the previous two lists with MD5 and check against a known hash
If the hashes match, then it has found the correct configuration. This means it is looking for a computer with a specific directory or file in the %PROGRAMFILES% directory, in combination with a specific directory in its path variable. This hash is salted and stretched so they obviously knew what they were doing.
Once it knows it has the correct configuration, it rehashes that pair with a different salt to get an RC4 encryption key which unlocks the payload. Different salts are used in the validation and decryption stages so that the validation hash (which is stored in the binary and known to everybody) does not give any information about the target configuration or the encryption key. Given the number of possible combinations of known files that could be in %PROGRAMFILES% and directories that could be in %PATH%, combined with the fact that the target configuration is likely one that is not publicly known, it will be very difficult to break this unless the targeted party comes forth.
No, the key isn't in there. The algorithm to generate the key from specific information on the host system is in there, but the key can only be correctly generated from the host system having the right information for which the algorithm can properly derive the correct key.
Read the FA :) The key isn't in the package, but is generated by characteristics of the intended target machine, you either need to brute-force it or find out what the target was.
This is not at all how it works. Nobody has the key, the key is derived from local configuration values using a cryptographic hash function. Just as your hard drive may be encrypted with a key that is generated from your password, this payload is encrypted with a key that is generated from a very long password which is a combination of specific settings on the machine. If you run it on a machine with the settings exactly right, it will unlock. If you run it on any other machine, it will not and you will get no information about what they key is. Since there are so many possible combinations of settings (particularly it is looking at all the programs in your program files folder in combination with all the directories in your path variable) it is unlikely that people will just stumble across the correct one.
If the malware is looking for a specific MD5 hash why not look for the possible variations on that instead of the source of the hash? Once that's identified then the research can go both ways - looking for the source and looking for the next hash.
I freely admit I've never done any cryptography but from a process perspective this seems like a reasonable way to approach the problem.
I look forward to hearing why this can't work. Honestly I do. It will help my understanding of how these things are picked apart by the experts.
The key is not in there. It's generated dynamically, based on information pulled from local computer's configuration. The key generating algorithm isn't obfuscated, but it will only generate the correct key on the target computer (or one very similar).
The only way this will be cracked will be by finding a computer with a sufficiently similar configuration (unlikely), or by a herculean feat of cryptanalysis (incredibly unlikely).
You didn't read carefully. The key is on the target machine and is not part of the attack software.
Dumb old way to do this:
1) Check for certain system configurations.
2) Use some key in the malware to decrypt and run the payload.
New hot way to do this:
1) Use some combination of system configuration to decrypt the payload
2) If that worked, run it.
See that? it hides both the decryption key AND the definition of the system it's meant to attack. Unless you have the target configuration (or can guess it) you can't decrypt the payload or figure out what it's meant to attack. Brilliant.
Since when did we start calling a payload a warhead, especially when it hasn't been decrypted?
Load the code in a hardware virtualization monitoring environement with an emulated CPU clock and let it run. Analyse the code execution and discover the branches not taken and then force it to take each branch the next time around, and watch/trace what it does. If you find ant-debugging protections along that path then you are probably on the right track to recover the key. There is no singular trick in their little-black-bag-of-tricks that can't be worked around. Be persistant and the key will be recovered, and a lot sooner than trying to brute-force decrypt the payload without the key.
Its guys like you being involved insecurity that makes people like the NSA get all warm and fuzzy.
Do you really think you're smarter than people at Kapersky? Or whatever shadowy group created the payload? I'm sure on the offence or defence side of things, no one has ever thought about debuggers.
Really?
Yes, as I said, you exercise the algorithm to produce the key. The key is just 'in the algorithm' that derives the key. The software is quite capable of deriving its own key given the proper host parameters. The examiners can and will know what system the code was taken from, and can collect any parameters from that system that are needed. In a harware virtual environemnt you can inject any host attribute you like, at any time you like, and the code running in it will never know the difference if you take certain steps, like making the CPU clock instruction cycle correct for the given hardware. The malware code will only know what you tell it, so the trick is figuring out what parameters you need to tell it, and that comes from excercising the code as well to see what it tries to access. Locically everything it needs to defeat itself is already in there, except the host parameters, and we just need to be smart enough and persistant enough to figure it out.
Could we get past the hyperbolic exaggerations when referring to computer code; please?
cracking an encrypted warhead
Really?
Of course it doesn't make sense, but you're looking at this from a perspective of sanity and rationality, and not that of a mouthbreathing waste of oxygen with the IQ of a braindead petunia.
Remember: no one is as smart as the Conspiracy Theorist. The Conspiracy Theorist alone has the insight to discern signal from noise, and even if what they see is completely harebrained, nonsensical and discredited by others. In fact, being discredited is proof that the Conspiracy Theorist is on to something, because facts and that sort of jargon is Them trying to Cover Things Up. And the more harebrained the better---how else would They hide things from the ignorant masses?
So, yes, the Conspiracy Theorist has determined that the "encrypted" stuff is merely noise to distract from the unencrypted code. Encryption after all can be broken with a few keystrokes (and possibly a blowjob); if it was encrypted it wouldn't actually be all that secure, would it? So, it's the unencrypted stuff to be wary of. Innocuous code that does nothing is the worst: it fools the so-called "experts" and is actually a devious plan for Them to accomplish their true goals.
If all this doesn't make sense, or sounds like a bad movie plot, you're not a Conspiracy Theorist ... or a complete moron.
Yes, that's obvious to every programmer everywhere. But after you know the parameters you still need to bruteforce them, just as if the key generation input was a password. Do you know anything at all about cryptography?
This would be trivial to defend against. Simply add an empty directory (starting with a non-latin-alphabet character) to Program Files, or to the PATH variable. However, if this targets the control computers of industrial machines (as it most certainly does) then all of that is probably static and locked down.
I'm slightly surprised that the signature involves non-latin directory names for programs. Stuxnet targeted Siemens equipment, and it is very, very likely that the directory names their control software resides in are in English, even if the software is localized for some other language. So this seems to be targeting home grown software / hardware this time around.
The next question is how did the author know *exactly* what the PATH and program files folders are configured on the target machine. That's the work of spies and moles. Someone probably stuck a USB drive into a target machine, which did a quick scan to grab the necessary info. That could be done in just a few seconds.
This configuration this software targets could be so extremely specific that there may only be a handful of computers in the world running the specific industrial control software the payload is designed to destroy.
Better known as 318230.
The examiners can and will know what system the code was taken from, and can collect any parameters from that system that are needed.
No, they can't. They don't know what machines the payload code runs on, and if the target (as is very very likely) was a government system somewhere in the Arab world, they probably never will. In other words, they have no clue what the parameters are for decrypting the payload: if they did, they wouldn't need to issue this challenge, which BTW isn't a brute-force, it's more like a distributed dictionary attack (testing various parameters that might be the target). They found the malware with encrypted payload in the wild, but never in it's decrypted state.
"None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
Does somebody know whether there is that font ("Palida Narrow") available?
Looks like they have narrowed the possible keys quite a bit.
Simulating the target in a virtual platform and running the combinations might be easier than attempting to decrypt the key.
Intercept the system calls looking for parameters and loop them over and over again.
The goal isn't necessarily to decipher the key as it is to get the payload.
If it were to get the key, I guess that would be more about finding the target. that would scare me.
Who ever it is intended for, even if its a test flight should reflect the system that created it and you would be able to use the key to track down the source.
I don't think I would want to have that information. or tell anyone that i had it.
Hey, don't be so vicious on him. If it had been a simple logical mistake regarding any other programming problem he'd not get so much flak - so why get worked up about it? Not to mention that reverse engineering isn't something most people think about or specialize in.
They know the system they took it from was not the target, because the parameters don't match. With all due respect, your suggestions have been unhelpful.
Change is certain; progress is not obligatory.
Of course confirmed world class cryptographers might think twice before showing what they can do, especially if they are hired by national labs to do precisely this.
Kaspersky Lab's request might also be an easy cover to discover new
talents in the field.
you're seeing it wrong
they are asking for help in reversing a hash, as if that's gonna happen.
and even if there's a reversed hash, its just as likely to be a 'random' collision as anything that can serve as a decrytion key.
what you have there is an idea for bounds on the key, a means of validating possible keys and a lock to try the key on.
can you see it now?
Notice how in the article it says that the code wants to find a program name with the first letter being over 0x007A (Unicode ‘z’). What possibilities could there be?
The problem as I see it is to figure out how to exercise the code that unlocks the key used to decrypt the payload. Brute force to crack the payload is going about it the hard way. When dealing with criminals, never play by their rules.
The reason the payload exists is so that it can be decrypted and used. Both the algorithm and the key are in there somewhere. The problem is discovering under what conditions it is exercised and halt the process after the decryption but before the key is removed from memory. Timing is the key to success.
Load the code in a hardware virtualization monitoring environement with an emulated CPU clock and let it run. Analyse the code execution and discover the branches not taken and then force it to take each branch the next time around, and watch/trace what it does. If you find ant-debugging protections along that path then you are probably on the right track to recover the key. There is no singular trick in their little-black-bag-of-tricks that can't be worked around. Be persistant and the key will be recovered, and a lot sooner than trying to brute-force decrypt the payload without the key.
The algorithm can be know and still does not make it easier to decrypt, the key does not have to be know by the program rather is it used to decrypt the actual code. There are two parts to the code the encrypted and the unencrypted, the unencrypted will use certain settings on the target computer that are unique as the key. The program then decrypts the encrypted part of program, verifies that the decryption was successful using a hash function and comparing it to a different section of the encrypted data, then executes the formerly encrypted payload. At no point does the program verify the key, the hash can be used to verify a successful brute force decryption but the hash will not lead you to a complete decryption. At no time does the program need a copy of the true key to work is simply runs the code through a hash function and compares it.
Knowledge = Power
P= W/t
t=Money
Money = Work/Knowledge so the less you know the more you make
Do you always rave about completely unrelated crap? That doesn't apply to this case as not just the article but the summary explain.
Couldn't Kaspersky Labs just post a Gauss detection tool or instructions to determine if your computer has been compromised, then just ask people/companies with infected machines to come forward and contact them? I'm sure the people who Gauss is targeting are probably paranoid of CIA and Mossad plots against them, but if they're infected with Gauss, they probably are already a victim of a CIA or Mossad plot to get them. They're already screwed, so it certainly couldn't hurt much more to trust Kaspersky.
hunter2
I'm assuming that the set of programs names have to match; it's not sufficient for the system to contain a single program of interest. So then you have to look at all the possible subsets of the programs available...a much larger space.
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
You can recover the key under certain circumstances given a few gigabytes of keystream, with the 32bytes they give it's not gonna work. Even if you had the entire encrypted payload and its plaintext (to get the keystream) it wouldn't be enough.
An encryption method must be very crappy if you can recover the key from 256 bits of output (32 bytes), not even knowing the plaintext to those 32 bytes. I think I read in another slashdot post about gauss that it uses RC4 with 512 bit keys, so it would be more of a compression algorithm than an encryption system...
The code that extracts the machine parameters that make up the key has to be non-encrypted, right? Wouldn't that be where to start? I.e. if you know the key is a combination of a path and a MAC address, and you know how they are combined to form the key, then you could reduce the key space by looking at plausible paths/macs?
I work in a nuclear plant. Shall I try it?
Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
But too bad for them-- their posted email address just bounces.
Emailing them multiple times is too risky. I guess the world will just never know what the payload does.
Don't forget that the installation of a single application could ruin the key. So we are probably searching for a computer that will NOT be regularly updated. I remember that ATMs run Windows. So I expect the target to be some "embedded" device. OR a device in a company where every update is tested for two years before it is allowed be proven ancient.
Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
The trick is to get the code to run. Then do a dump of the RAM where the code will be unencrypted.
Perhaps they can PAY George Hotz and Jon Lech Johansen to work on the problem:
http://en.wikipedia.org/wiki/Jon_Lech_Johansen
http://en.wikipedia.org/wiki/George_Hotz
Everyone is assuming that the payload is a warhead and that it will destroy a specific target.
But what if it isn't? What if it is an encrypted message only for the eyes of a mole/spy in the middle east? Maybe I've been reading too much spy novels and watching 007 movies, but I think a payload with such strict restrictions to decrypt might not be what everyone is thinking of.
If it's a warhead, the attacker must know what is the exact configuration of the directories of the victim (hey! I would like to wipe your hard drive, would you show me you files please? Thx!). Almost impossible to pull off.
What if you are a mole that does not want to receive an encrypted mail or download an encrypted file directly from a link because someone will notice it? Let's do it via a virus! You only need to get "infected" as millions of other users and then configure your files to decrypt the message.
Like I said, maybe I'm reading too much John le Carre novels...
I found an elegant solution to the problem, but it doesn't fit in the slashdot comment box.
The password is: 1 2 3 4 5 Same as my luggage!
Even if the program generates a key from context information on the target system, there must be a boot strap which is not encrypted to get the process started. Just run that under a debugger and step through it to find how it is generating the key.
If the authors were good, this could be a laborious process, but it is doable and there is nothing that they can do to prevent this approach. They can make it painful, but they cannot make it impossible.
If Kaspersky doesn't know what the "warhead" does, it's going to be very difficult to write a tool (or instructions) to detect it!
0 1 - just my two bits
Not to mention that reverse engineering isn't something most people think about or specialize in.
Nope, not something people think about... not so much. Except Kapersky. Yeah, Kapersky labs - that's pretty much what they think about and specialize in. Reverse engineering malware and viruses, that is. That's pretty much exactly what their core expertise involves. So maybe suggesting that they use reverse engineering is a little silly. Particularly when the accompanying article states that they reverse engineered the program and gives details as to exactly what it is doing based on this reverse engineering.
Let's see, who are we talking about anyway? Hmm... Eugene Kapersky is the top guy over there. It seems he was involved with building AVP back in the early 90's before founding Kapersky labs in the late 90's. He also "graduated from the Institute of Cryptography, Telecommunications and Computer Science, where he studied mathematics, cryptography and computer technology, majoring in mathematical engineering." - so he's got the training. Yup, I'd say advising this guy that executing the code in a virtualized environment might solve his problem just might be enough to make you look a tiny bit ridiculous.
instead of said known programs run an algorithm to string out(not use) all the possibilities of programs NOT known.... ...much later....and thanks for all the fish
have fun cya later
Some of the difficult to detect malware that Kaspersky (Russian) has found, has been going after Iranian computers used in Uranium enrichment. If one wants to hinder Iran's Uranium enrichment program, one should not help Kaspersky crack the sophisticated malwares.
seems like the payload is not only for a specific machine, but it has a limited window of time in order to work. unless it knows it is some locked up industry or government box used by someone who will never install programs, i guess
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
The same can be said about US and its weapons.
No because it loops over all path/program pairs so adding things will not break it. Only removing or renaming the target program will work.
thanks, i thought it was hashing all programs together
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
also posted this on one of the topics on securelist but figured it might get more discussion here...has anyone else noticed that if you move the N in the font name, it becomes "Palidan Arrow"? Does that name mean anything to anyone?
I realize that Palidan should be spelled Paladin, but since "Pali" is a normal shorthand for Paladin, it's not a completely unbelievable mistake. Also Palida sounds more believable for a font name than Paladi.
Anyway, it could be nothing, but it also could be an intentional play on words by the authors...
Caveat I once purchased Kaspersky for my PC. Unfortunately it did not catch a virus caught by Virus Buster and therefore had a very embarassing situation a few years ago, so I stopped using them.
So anyway reading the posts here it sounds like Kaspersky is trying to defeat a NSA/Mossad attack on a target of interest in the Arab or maybe Chinese world with extremely valuable, sensitive information on a networked PC.
Why?
Is it because only a Russian company has the balls to do it?
Personally I have no faith in Windows antivirus after reading over 10% of viruses are not being caught by antivirus software (sorry this is just anecdotal). So I use a mac with firewall, once in a while a sandbox, a free antivirus (sophos, meh), some backups, and crossed fingers. Just wondered if this is the most interesting thing Kaspersky sees to spend resources on, I guess it is. Just the distributed cracking net they supposedly had is not being used for the general public, just high profile cyberwar things like this.
Obviously it's looking for the DAYZmod files. Because, as I learned from watching Johnny Mnemonic, defeating military grade encryption is very much like winning a death match in a third-person shooter.
The insanely slow login times? That's your connection being tunneled through a secret proxy server in Qatar.
Every time you kill a bandit, somewhere in Iran a centrifuge explodes.
Zombie AI amazingly stupid? Turns out the Iranian Revolutionary Guards suck at video games, but you have to admire their persistence. . .
/Puts on my black crypto-anarchy hat
My understanding is the first thing LEO does when it encounters encryption or drive analysis, is pull the drive & make a copy. Then take the drive and analyzes it on a separate machine or using forensic hardware.
Would something like this be useful in reverse, because without the original computer that contains the correct configurations, the key could be given out but the since the hash needs internal qualifications to match it would not jive because they wouldn't plug the drive back into the old computer.
of course there is always rubber hose crypt, and permanent lockup, NOT obligatory xkcd, blah blah blah yeah I know all that & doesn't add to this conversation. /black Hat
"(I) have this unfortunate condition that causes me not to believe a single thing any politician says when a mic's on.
Yea, because we're totally like to attack a peaceful, human-rights-respecting nation.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Bruce doesn't need to decrypt anything - any encrypted item becomes clear text immediately on viewing by him!
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
..then you would understand that the key is (essentially) something like c:\ProgramFiles\MullahSuperCrypto. Except that we don't know the real value of $MullahSuperCrypto.
..that you should not get closer than 10 meters to computers. Surely you will contract a Linux virus by surfing porn as UID 0. Seriously, go to the next construction site and get hired as the brick carrier. But please don't kill yourself in the process and never ever try to use cement. It is above your IQ.
..and you should get yourself a proper education and a copy of Schneier's book. Not sure this will help, as some basic rationality must be in place before. And some rigorous ways of *own* thinking, which many people lack. Start with not looking shitty videos every night; that will be the first step.
This isn't just a check that compares values against other values; it's an actual encryption. The algorithm doesn't know and cannot derive the correct key.
The algorithm can only read certain attributes from the environment (eg. serial numbers), calculate a hash sum, and then attempt to use that as a key. If the attributes match the target system, the hash will be the correct key, and the decryption will succeed. Otherwise, the decryption will fail. There is no way to crack this without either trying all possible hashes or all possible attribute values (whichever is easier). Serial numbers, MAC and a few other attributes could together be hundreds of bits long, making brute force infeasible.
..to calculate 2^128. That is about 1000000000000000000000000000000000000. Which is a fscking large number. So large that if all the atoms of earth were converted into transistors, ONLY THEN you would stand a chance to break it. Understand ?
Yes you are. Whenever need arises justifications are soon to follow.
I don't think you get exactly what I'm getting at here. Whenever someone n00bs out over, say, not understanding OO properly people don't attack him like goddamn vultures. But when it comes to computer security every goddamn geek with some insight wants to bash his skull in. Why is someone being wrong on the internet about security so much more important? I get that being into computer security might require one to have a less that shiny personality, I've got that "problem" myself, but I still think it leads to a lot of hot air and miscommunication.
Funnily enough I don't see much of this behaviour over at the security mailing lists.
Which, for me, is the scariest bit. Having such a precise knowledge of a target system, yet still bothering to target it with a release-in-the-wild trojan does imply a few things...
And it wouldn't be likely the target computers would be running it.
Sorry, folks, my fault.
I was writing a Pascal program on my TRS-80 and things got out of hand.
It turned out to be a strong AI program, which is busy taking over the world.
I advise you all to stock up on supplies.
Well, you could sorta-kinda argue that the key **is** the local configuration values, and that all the system-inspecting code is part of the overall decryption algorithm. It all depends on where you want to draw the boundary lines.
Godel numbers are the product of a sequence of prime powers of specific numbers encoding a message's letters and numbers. To decode them, you need to have a really good (fast) prime factoring algorithm, and a infinite (almost) digit math package. I played with them about 27 years ago, but only with numbers up to about 15 digits using 80-bit numbers programmed directly into an Intel 8087 math chip. I could pretty much encrypt my name... :-) The point is, that any text can be so encrypted into a single sequence of digits, and they aren't difficult to generate, but they are HARD to decode.
Anyway, I don't know if this is what they are referring to as the "Godel module", but if so, then I would have to say that only the NSA or someone like that has the capabilities to do this effectively, due to the costs involved.
I considered this method a few years ago to try to find a stolen wireless router. I would have just needed to develop amazing malware that spread like wildfire, but undetectably, and queried ARP tables until it found the MAC address of the router. Encrypting the payload (a rootkit or other tracking software) would disguise what the true intent was, and the trial keys would be derived from the MAC addresses visible in the ARP cache. Of course there wasn't really enough entropy to truly protect a payload with a MAC (so heavily iterated hashing was my tentative solution) and then Google decided to make semi-open location-finding APIs based on visible wifi MAC addresses without the need to violate the computer abuse laws, so that solved the original problem. Now I realize that I don't care so much about a $50 router that probably got pawned off a few times already (it's still in the same city as me unless Linksys decided to re-issue MAC addresses).
Care to cite any proof?
Doubtful. Just pushing shame on the US to make themselves feel better.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Oh gosh...I hope it's not me.
The Gauss malware includes a built in config tester, which is how it works. It parses the config, feeds it into a key generating algorithm with a test Initial Value; if the output of the key generating algorithm matches the included hash, then it reruns the algorithm with a different IV and generates the real key. The real key is used to decrypt the payload and do the as-yet-unknown damage.
All Kaspersky really has to do is include the first part of the test with the test IV in their next anti-virus update and have any potential victims phone home with the winning ticket.
John
What if they examined the computers of known or captured Hezbollah operatives, and found that several had the same "c:\program files\SuperSecretHezbollahDecoder" program installed? The encrypted payload might be a combination of things, like "grab the SuperSecretHezbollahDecoder key," and "Use the WiFi card and Bluetooth dongle to identify every phone and device in the room" and it reports all data back to the mothership. The RF stuff could be triangulated by a system like Apple's WiFi location API, or via wigle.net, or even the WiFi data that the Google StreetView cars were scraping. Phones could be traced back to a specific IMEI and tracked.
Airport and other public WiFi installations could be constantly scanning for devices on the hot list. If the Israeli government offered local businesses free "terrorist detectors" (picture some reprogrammed access points that passively scan and report WiFi and Bluetooth MACs back to the IDF), about 80% of businesses would quickly install them in their lobbies.
That would actually turn out to be very disruptive to terrorist organizations. By making every member of the organization suspicious of every electronic component, they would completely deny them the ability to communicate wirelessly. Without those communications, they have to go back to hand-passed notes, dead drops, brush passes, and other old school spy tradecraft. And the Israelis are very good at tracking those kinds of people.
John