Comments

Chris W • August 21, 2012 6:50 AM

As mentioned in the friday squidy blog this might be rather difficult to do.

It is obvious the Godel payload isn’t looking for any commonly used installed application. But rather an application rather specific for the target, whether it may be a banking system, industrial or government system. Without access to those systems it will be nearly impossible to find out. On the other hand, it is reasonably likely the targets already discovered their infected systems and will be able to decipher the payload. Unfortunately for us that will not be public.

I guess modern anti-virus will have to designate iterating through Program files as suspicious behavior.

From a cryptanalysis perspective it basically comes down to a md5 pre-image attack or an attack on RC4 stream cipher.
Neither seem feasible at this point. The best known pre-image attack on md5 has ~2^123 complexity, out of the 2^128 for bruteforce, so not practical.
In relation to the RC4. We only have the magic value of 0x20332137 at position 0 OR 7 of the plaintext to go with. Position 0 seems unlikely though, coz according to my assembler 0x20332137 is pretty much useless as first instruction.

AC2 • August 21, 2012 6:56 AM

Store the payload on tape and run an electromagnet over it which chanting ‘Bruce Schneier’…

Clive Robinson • August 21, 2012 8:32 AM

As also commented of Fiday Squid page there are some other oddities, like the fact it loads a narrow pitch font into the system (why is an open question though I can think of a number of reasons)

@ Chris W,

In relation to the RC4. We only have the magic value of 0x20332137 at position 0 OR 7 of the plaintext to go with. Position 0 seems unlikely plaintext to go with. Position 0 seems unlikely though, coz according to my assembler 0x20332137 is pretty much useless as first instruction.

I guess it depends on how the code is ment to be loaded and then jumped into for execution.

On the assumption it is “known plaintext” to check the decryption has worked correctly is 32bits sufficient to prevent a “false start in on garbage code”? at an ~1 in 4billion chance it might actually not be.

The “fastest hope” we have currently is from the potential “targets”. That is if somebody found that their machine had been identified “correctly” by some method, and posted either the resulting ARC4 key or actuall code up on an anonymous site somewhere.

gubmint • August 21, 2012 8:46 AM

Just put it in a virtual machine emulating nuclear SCADA devices and change the language to Farsi. Kind of obvious this is prob yet another Israeli/US made malware

Captain Obvious • August 21, 2012 8:56 AM

@Chris

If it’s looking for something specific, it shouldn’t be iterating through Program Files. It will make one check which will pass or fail.

Perhaps programs could be restricted from modifying anything outside their own directory without special approval.

Cerebus • August 21, 2012 9:34 AM

Very nice work. Basically this is a two-round variation of PBKDF#2; the first round finds the trigger application, and second round derives the key. The high iteration count is just paranoia at work; c=10K is overkill.

Very fragile work, though. Gauss is defeated by renaming the directory.

— C

Peter Maxwell • August 21, 2012 9:50 AM

The analysis given by @Chris W is pretty much correct.

There are really only three ways to attack the problem:

i. find the correct pairing for directory+filename;

ii. pre-image the validation hash digest; or,

iii. derive the internal state of an RC4 cipher that was initalised with a 128bit key using only 32bits of entropy.

So, handling these in reverse order, iii. is not likely to happen as even with RC4’s oddities, I doubt one would be lucky enough to find a key-partitioning property that would allow retrieval of a 128bit key from only 32bits of data… it’s essentially the old unicity distance question.

Now, turning to ii. – even though md5 is a bit mangled these days, it still is not possible to mount a pre-image attack in practical time (or even near that). So this option is out.

That leaves us with i. The process used to construct the key requires taking the cartesian product of the set that is the union of all path variables along with all files in %PROGRAM_FILES% that start with a character value if 7A (irrc), with itself; salting each of those values and hashing 10001 times to try find one digest that matches the validation; if you’ve found one that matches the validation then salt the original pair with a second value and hash 10001 times to get your key. Given the potential key-space of each pair is far more than 128bits, one really needs to know what they’re looking for (just think, even a microsoft GUID is 128bit).

The bottom line is that, unless one has a massive stroke of luck, you need to know what system is targeted. Fairly clever really.

James Sutherland • August 21, 2012 10:13 AM

“Just put it in a virtual machine emulating nuclear SCADA devices and change the language to Farsi. Kind of obvious this is prob yet another Israeli/US made malware ”

Setting language to Farsi won’t help you – from the p-code the Kaspersky guy posted online, it only tries hashing the first directory name in program files starting with { (or higher) – either the hash matches, or it gives up. Give it a bunch of non-ASCII-named programs, even if it does have the target installed you’ll never get a hit!

(In fact, NTFS uses a B*-tree, meaning the enumeration will be in ascending character order – so if the target name does start with {, neither higher nor lower characters will interfere. The bigger the distance between { and the actual first character, the more likely it is to trip over false positives.)

I also suspect the use of PATH is obfuscation, with the value used being C:\WINDOWS or C:\WINDOWS\system32 – effectively just an extra bit of salt, with the program file being the real goal. Still, without knowing what vulnerable application installs in a GUID-named ProgramFiles directory, it remains anybody’s guess!

Peter A. • August 21, 2012 11:15 AM

@captain obvious: if the code made only one check it would be obvious what it’s looking for. Now it is looking for some program out of huge number of software packages out there and nobody will know which one unless someone actually installs (or pretends to install) the right one. Tricky.

Clive Robinson • August 21, 2012 12:13 PM

@ Peter A., Captn Obvious,

Now it is looking for some program out of huge number of software packages out there and nobody will know which one unless someone actually installs (or pretends to install) the right one. Tricky

It might not be as tricky as we think.

First off the number of packages is very finite in number and way way way less than 128bit equivalent required for a brute force attack.

Due to “forensic investigation” there are already databases of package names directory structures and component file hashes. Admittedly most are for standard packages but they can be used to find/eliminate fairly quickly.

I suspect that the details of many other packages will quickly become known as well now there is a reason to search for them.

There is also another way to find out and that is by using a similar “attack vector” as used by the main body of Gauss….

That is write a piece of malware and instead of delivering the “Godel package” get it to report back with matching directory structures. The chances are within aa very short time it would deliver up a candidate (otherwise Gauss would not have got there in the first place).

The question becomes who the writers are hidding the code from and why. If it’s from the general masses then the plan might work against them but what about others?

I will make an assumption that Gauss/Godel left recognisable traces that might (or might not) still be valid by which it can be recognised.

I will further assume that those attacked will consist of “intended targets” and “collateral damage”.

Primary targets are potentialy going to keep quiet, but what of collateral damage sites? We know from how Gauss was discovered that “people reach out for help” in this case it was via the ITU.

Collateral damage sites don’t have any real reason to keep quiet, thus the question then becomes can Gausses prescence or previous precence be determined?

Even if Gauss/Godel had a self erase function it will nomatter how they do it leave recognisable traces behind.

That is if they uses a secure delete process the result will be significantly different from other areas of the hard disk. Likewise if legitimate data gets copied from another place on the hard drive to overwrite it it will still leave recognisable anomalies. Even if they muck about with the “free list” process the chances are that bits will be left behind depending on the size of files etc the host writes to the HD. But even if the blocks do get compleatly overwriten they will be “out of sequence” and thus still vaguely visable by “out of sequence” disk usage compared to known history.

If nothing else Gauss/Godel may be caught on backup / archive tapes… In effect that’s how it was found by Kaspersky in the first place. Remember it was such tapes that brough Ollie North down, so these things do happen.

Thus there is a small chance that a collateral damage site will know it’s had problems and the prescence of Gauss assumed and the site come forward with it’s directory structure to unlock the code.

The question then becomes will these people keep quiet or will they spill the beans. Further can / will Kaspersky keep quiet or will they publish an analysis at the very least.

Whilst an analysis may not be helpfull to most people, there are enough lateral thinkers who will read it and be able to re-create a good facsimile.

And at the end of the day it’s not the actuall Gauss/Godel code that needs to be kept secret but the ideass behind it… and I realy don’t think those can be kept quiet…

lolbot • August 21, 2012 12:28 PM

Make a directory called Seekrit Nuclear Filez or change user to Ahmadinajad, payload decryptz.

This is obviously state made spyware to find out Iranian govt bank accounts they can either fleece illegally or have shut down.

Joe Buck • August 21, 2012 12:53 PM

“I guess modern anti-virus will have to designate iterating through Program files as suspicious behavior.”

Hmm. What programs commonly iterate through program files? Anti-virus programs, of course; they are analyzing all programs looking for viruses. So anti-virus programs of the future will flag their competitors as suspect, and the best way to implement really sneaky malware could be to disguise it as an anti-virus program. A government might try to subvert anti-virus companies if they want to do a targeted attack (find a specific target or class of targets to sabotage or gather intelligence on).

jimrandomh • August 21, 2012 1:59 PM

People are assuming that this is looking for an installed program, but I don’t think that’s very likely. What seems more likely is that this malware likes to spread key material in hard-to-reach places, so that if a sample is captured it’s likely to be missing pieces of the decryption key. Under that interpretation, the directory name it’s looking for in Program Files would not correspond to an actual program, but to a key deposited by another piece of malware (or by a missing piece of this malware’s installer). Similarly, the font that it installs probably contains some sort of key, to be used by a different stage of the malware’s unpacker which we haven’t seen.

If this is true, then nothing short of a complete memory+disk image of the correct target machine will reveal anything interesting. (Or if really unlucky, it might also need firmware images). The interesting thing here is that this malware has gone to such great lengths to protect its payload from analysis; but it looks like we can only speculate as to what that might be.

Chris W • August 21, 2012 3:12 PM

@Joe Buck

Yes, and practically all anti-virus solutions explicitly tell you not to install them in conjunction with another to avoid conflicts. Or more likely, they tell you to remove the other anti-virus and then install theirs instead. 😉

@Clive

“That is write a piece of malware and instead of delivering the “Godel package” get it to report back with matching directory structures. The chances are within aa very short time it would deliver up a candidate (otherwise Gauss would not have got there in the first place).”

Albeit illegal I would consider it a very good idea, if the method of spreading wasn’t via USB. Using the same exploit is unlikely to succeed since both the exploit and the virus signatures are known for a while now. And finding another zero-day would require a significant financial investment.

It is true that the number of different packages existing is much lower than 2^128. But the pool from which those package names derive is bigger.
If you only consider {GUIDs} as directory name, the pool IS 2^128.
The only way to retrieve a list of likely candidates would be to cooperate with the likely targets. I would start with financial institutions in Lebanon.
Although this is conjecture and far from certain. At least we would be avoiding an attack on the crypto at its strongest point. (which, as we occasionally hear here at Schneier’s blog, is stupid.)
You basically mention the same thing, with collateral targets. But you’re expecting them to come forward. I think it requires a more active approach.

salty • August 21, 2012 6:36 PM

Gauss only needs two file/folder names from program files:

A. Make all possible pairs from the entries of the resulting list.
B. For each pair, append the first hard-coded 16-byte salt and calculate MD5 hash.

Peter Maxwell • August 21, 2012 6:48 PM

@Clive Robinson at August 21, 2012 12:13 PM

“It might not be as tricky as we think.

First off the number of packages is very finite in number and way way way less than 128bit equivalent required for a brute force attack.”

Presuming the malware is targetting a specific system or systems, it is quite likely that the required pair will not exist in the “wild”, i.e it could quite easily be proprietary software which is not used outside the target institution. The fact that Kaspersky has put it out to public scrutiny suggests that they do not have the required pair in their records and they will have a very large list of potential pars at their disposal.

There is a small chance you might get lucky but unless you happen to be the NSA or GCHQ, I wouldn’t waste the time on it.

The acid test here for anyone suggesting that it may not be that tricky would be decrypting the archive. If you cannot then any speculations of it being easier than it looks are really unfounded.

Sorry for being blunt but it is really that simple.

Clive Robinson • August 22, 2012 1:06 AM

@ AC2,

So I guess no one liked the joke about De-Gauss ing the payload..

Perhaps you should ask of your sense of humour,

Is mine magnetic or not?

Roger • August 22, 2012 3:57 AM

Reading the comments are Kaspersky, it is amazing how many commenters have either not read the description, or have misunderstood it.

SO to quickly recap, what actually happens is:

  1. The PATH variable is split on “;” (its normal delimiter);
  2. A Windows system call is used to deliver a wide-character list of all entries directly in the Program Files folder (both files and directories), filtered by those where the first character is above 0x7A (“z”);
  3. The Cartesian product of these two lists is created. I’ll call these the list of candidate passphrases;
  4. Each candidate passphrase is then concatenated with a first salt, and repeatedly hashed 10,000 times;
  5. 32 bits of this are compared to a “magic value”;
  6. If any passphrases give the correct magic value, they will be processed into a key;
  7. To process into a key, a passphrase is concatenated with a different, second salt, and then repeatedly hashed 10,000 times;
  8. The result of this is used as the 128 bit key for RC4

So, a few comments about widespread misconceptions about this process.

  • The items in PATH are unrelated to the Program Files entries. In fact, they don’t even need to be real directories. Actually, they don’t even need to be constructed like a directory name. I have tried appending random junk to the end of the PATH, and Windows doesn’t mind. So if the target machine is already infected by something (which seems likely), the relevant part of the the PATH could potentially be anything.
  • The item from the Program Files does not need to be the installation directory of an installed application. Again, if the machine is already infected, it could be anything. The restriction to characters above 0x7A does indeed include non-Latin alphabets but it also includes some punctuation marks, including some that Windows uses to name special directories. For example, some special directories have a GUID as name, wrapped in curly braces. There’s quite a bit of entropy there.
  • The key has a lot more than 32 bits of entropy. The key is derived down a completely different processing path to the magic value check. The whole 32 bit check thing is to eliminate incorrect choices without giving too many clues to cryptanalysts. It will slightly speed up a brute-force cryptanalysis, but not by much.
  • The people who designed this knew what they are doing. It is a very smart system. Any “candidate passphrases” that have a reasonable chance of being guessed in a simple dictionary attack are almost certainly wrong. On the other hand, the 10,000 times slow-down is there for a reason. Maybe it’s just “belt and braces”, but I suspect it’s because the actual entropy of their passphrase was about 13 bits below their comfort level. I also suspect that their comfort level is “total roadblock even for national intelligence agencies.”
  • I suspect that the only practical way to attack this is to identify a target machine.

Chris W • August 22, 2012 7:17 AM

@Roger

Aren’t you making a mistake at Step 5?
There is no mention of the magic number in the ‘Validation’ section. Only in the ‘Decryption’ section, that section specifies that the magic number of compared to portions of the RC4 decrypted buffer.

“6. Decrypt the section (RC4), treating its first DWORD as the length of the buffer to decrypt and encrypted buffer starting at offset 4 of the section.
7. Compare DWORDs in the decrypted buffer at positions 0 or 7 with magic value “0x20332137”. Proceed only if any of the DWORDs match.”

Roger • August 22, 2012 8:00 AM

@ChrisW:
“Aren’t you making a mistake at Step 5?”

Ah, you’re right, I did — but it doesn’t make much difference. The check value in the validation phase is 128 bits, not 32.

jacob • August 22, 2012 9:50 AM

It might be looking for specific programs and maybe use updates or patches to hide start point. I was wondering if maybe it used a either/or on harddrive then feed that into encryption. 128 bits?It could be bigger using module principles. We really have no idea yet how close to true random this thing is using to hide what it’s doing. That could make it tricky. A lot of steps to try to find forensically if done correctly.

Why hide? The Israelis and NSA, etc. probably has some mathematic or engineering tricks they don’t want in the wild. Flame is already being looked at as a new way to engineer malware. I still maintain this is a breakout similiar to encryption..

I want to see this thing dissected. I suspect we are going to find some really clever work on this..and there are probably some even higher classified stuff that looks like it was found written on the ship in roswell. 😉

Clive Robinson • August 22, 2012 12:06 PM

@ Roger,

Aside from the minor glitch your last point,

I suspect that the only practical way to attack this is to identify a target machine

Is as I’ve indicated above is probably the easiest way to go to solving this. Because attacking the crypto is probably pointless unless a new break against ARC4 comes up, and a simplistic brut force search is going to take longer than the code will be valid for.

However two questions arise from this,

1, How do you identify a suceptable machine.

2, How do you detect if a machine has been infected.

With in effect the second question giving rise to the only legal way of answering the fisrt (though I have sugested a less than legal way above).

To answer the second question is actually quite complicated because it’s probably time dependent when looking for side effects.

However I suscpect the developers missed a trick, as you describe it there is no need for the full payload to be provided for the initial detector to work (your numbered point 7).

Thus a sugestion is how about including a detector in the next update of AV software that runs upto stage 7? There is a reasonable probability it will be detected (if the target machines run AV software).

That is we look for the “known signiture” rather than the “unknown effects” of the payload.

However if a match is found do we get to know about it?…

We are back to my point about the primary target and the collateral damage sites. Will one of either group come forward witth the key [we don’t actually need to know the director structure to decode the payload just the resulting key].

If not then we will have to go back to the other options.

As I mentioned a simplistic brut force attack against a 128bit unknown text is pointless as it will take a lot longer time than I have.

But does the search have to be simplistic?

If you think about it most program names suffer from the same failing as passwords in that they usually have to be “human interpretable” to be memorable thus usable. Human memorable passwords usually make a very very tiny fraction of all the available random password space, which is why the likes of rainbow tables and password lists work.

Thus I suspect that due to this the actuall “real world” search space on program names is going to be much less than 2^32 and could be down below 2^20. Hence my comments above about forensic databases.

More importantly unlike passwords the program developers were unlikely to be trying to obsficate the human memorable name as they would not consider it to be a secure more probably “public knowledge”.

Now as others have sugested the information may be currently unknown as the program name etc may be in a non English language and be semi or fully custom in nature.

I don’t think that this is such a hurdle as others are making out.

Unless this attack was designed very specifficaly for a single target for which a high degree of intel is known then the information is out there and deducable as the Guass writers or their sponsors did.

As an example, let us assume it’s looking for a banking application program. The bank it’s self is unlikely to make the name of the program or it’s derived files secret. Thus if you know who the likely targets are you may well be able to find out which banks they use.

However the downside of this for the Guass writers is the number of targets it would attack would be effectivly the same as the number of bank customers at that level, which is likely to be in the thousands.

But I also think that the mechanism could not be highly targeted simply because the implication of this is an “insider” who has actuall access to the machine. In which case why go to all the trouble of developing and testing Gauss knowing full well it has a high probability of being found.

Thus I suspect that the actual number of targets that Guass could potentially attack is probably in the low thousands

Which makes the odds of somebody coming forward much much greater than might at first be thought.

Further what would probably help identify the potential targets is effectivly “Traffic Analysis” on where Gauss came from and where it was going because this would help identify the targets Gauss was aimed at.

Thus we need to think less like a Crypto Guru and more like a “forensic accountant” who can see the trails of money in myriads of financial transactions

llacer latot • August 22, 2012 8:58 PM

Do ‘Soft TEMPEST’ fonts exist? If not,
what is the closest font selection(s) you can get to them? It’s not like I can verify this myself in my own party van.

outsourced fetus • August 22, 2012 9:01 PM

“I suspect that the only practical way to attack this is to identify a target machine”

I’ve heard whispers of remote wireless attacks against PC serial and usb ports without devices attached to them other than the motherboard.

Roger • August 23, 2012 8:40 AM

Hello @Clive,
…a simplistic brut force search is going to take longer than the code will be valid for.

You may not realise, but the payload is probably already not valid. Kaspersky says that the C&C network was taken off-line 2 months ago.

Thus a sugestion is how about including a detector in the next update of AV software that runs upto stage 7? There is a reasonable probability it will be detected (if the target machines run AV software)…. However if a match is found do we get to know about it?…

Yes indeed. I think this is a good idea, and has a reasonable chance of success. It’s probably also permissible within some AV vendors’ terms of service to simply “phone home” with the key.

…much less than 2^32 and could be down below 2^20. …

As a point of reference, Kaspersky say they have already trialled more candidates than that. That probably isn’t enough to exhaust “ordinary” combinations of PATH and Program Files. However it does cast considerable doubt on that approach, and is the reason Kaspersky has asked for other approaches.

… the program developers were unlikely to be trying to obsficate the human memorable name …

This assumes that the object within Program Files is a normal application. Since it is considered likely that the machines have previously been infected with something else, there is no reason for that to be the case.

It is even easier for malware to append something to PATH. On many systems, appending to the local profile version of PATH doesn’t even require privileged access.

Unless this attack was designed very specifficaly for a single target for which a high degree of intel is known then the information is out there and deducable as the Guass writers or their sponsors did.

That is the thing, though. Firstly, whoever wrote Gauss obviously intended it (the special payload) to run on only a limited subset of machines. They went to a lot of trouble with that, and the mechanism they chose is intended to be difficult to reverse engineer. It simply doesn’t make sense if it is keyed off an application name that is readily guessed. Secondly, they must have some intel on the target machines, in order to know passphrase elements of PATH and Program Files. Just guessing has too high a probability of failure, unless they picked something really common — and Kaspersky has already verified that they didn’t pick something common.

As an example, let us assume it’s looking for a banking application program.

Just by the way, Kaspersky has already been examining it on Lebanese bank systems, and so presumably has a list of any special in-house applications.

Further what would probably help identify the potential targets is effectivly “Traffic Analysis” on where Gauss came from and where it was going because this would help identify the targets Gauss was aimed at.

Kaspersky says they have been unable to determine how it propagated. So far, it seems not to have a built-in propagation mechanism. (Some people are speculating that it was “dropped” by one of the other members of its family, Duqu or Flame.) It had a C&C network but that was dismantled months ago.

Peter Maxwell • August 28, 2012 11:27 PM

@Roger at August 22, 2012 3:57 AM

“3. The Cartesian product of these two lists is created. I’ll call these the list of candidate passphrases;”

Close but that is not what was described. What is described is the Cartesian product of the union of the two sets, i.e. if A is the set of the path variables and B is the set returned form the function call then the final set is ( A U B ) x ( A U B) what you describe is A x B, which if A and B are non-empty is strictly smaller.

@Clive Robinson at August 22, 2012 12:06 PM

“I don’t think that this is such a hurdle as others are making out.”

Shall we hold our breath while you decrypt the archive? 😉

Seriously though, if one wants to support an argument in favour of the problem being easy, decrypt the darn archive otherwise it is just hot air.

Clive Robinson • August 29, 2012 8:28 AM

@ Peter Maxwell,

Shall we hold our breath while you decrypt the archive?

If you wish to then by all means do so, but I personaly would not do it because the expectation in normal circumstances is, in around 15mins max death will have occured, and we already know that various AV companies have spent more time than that on Gauss/Godel.

The argument I’ve put forward is one bassed on practicalities, that is a brut force attack on the Crypto (at ~2^1700 states for ARC4) is not going to work nor are brut force attacks on other parts of the detection and key formation process (~2^128 states). What is in effect needed is a good old fashioned “pinch”.

I’ve outlined a couple of methods by which a pinch could be obtained, and it would appear that others think likewise as they have already written software to test to see if your computer is the one in a few million or so selected for the Gauss/Godel treatment.

As I’ve also indicated that the result of such methods is probablistic in nature you need to consider the probabilities, for a start just how many computers are there running in the world that Gauss will run on? would it be as high as 2^30?

I take it from your view point you consider the probability as close to zero as makes no effective difference and I don’t and you take exception to that.

Some of the reassons I’ve given above already but I’ll make it a little clearer for you as to why I’ve adopted my view point.

That is there is also another asspect to consider which is important.

If Gauss/Godel is to specific then it is a “red flag” that the computer concerned is “known” to a level that could only have been done by an “insider” either by direct eyeball inspection or via a software agent. Which would inform the target organisation that they have either a witting or unwitting spy with direct access to the computer.

Now I know the US is happy to “burn” their and other peoples agents for political publicity (Scooter Libby & the latest “underpants” bomb). But it is a policy that will in short order cost them and their allies Humint resources. The golden rule has previously been you don’t betray your agents even if you know they are doubled, because it’s bad publicity, which makes getting future agents difficult or impossible (which is a point the US keep banging on about with regards the likes of Bradly Manning).

Usually you either use the suspect or doubled agents in other ways or arrange a suitable misfortune to befall them if they cannot be used (it’s one of the reasons why tripple agents are so highly prized and also very carefully watched).

So unless the writers of Gauss/Godel were not cognizant of this and neither were their supperiors which is doubtfull I would expect that the Gauss mechanism is not to specific. Otherwise even if a human agent was not known to be involved the risk of accidentaly starting a witch hunt for one would be considered to great. Historicaly you go to great lengths not to give your target cause to change their activites in any way lest they take action that hurts you or your allies.

And so it would be sensible to make it not to specific, that is there is a trade off in “harms”. To specific you potential get “burned” badly, insufficiently specific and potentialy your code get known and used against you or your allies. If it was down to me I would err on the side of not being to specific, as there are other advantages to this.

If it’s not to specific, then there is a probablity that those who are either the target or collateral damage will find this out.

The question then becomes “what do they do”, and there are several options which depend on them. And again I’ve highlighted some of this.

But there is also the question of if those effected try to make the information known will those receiving the information make it public?

One possibility is that somebody will “sell the key” to an exploit broker or criminal organisation because the estimated value of the payload is high. If they chose this option then we may never get to hear about it. And this amongst other possabilities effectivly negates your argument.

Now when comparing this to “Brut Force” methods it has a much much greater probability of success hence my various comments. And as I’ve said other people who have written software to perform the checks must likewise think it has a reasonable chance of success otherwise why would they write the software?

As I’ve already said,

“Whilst an analysis may not be helpfull to most people, there are enough lateral thinkers who will read it and be able to re-create a good facsimile. And at the end of the day it’s not the actual Gauss/Godel code that needs to be kept secret but the ideass behind it… and I realy don’t think those can be kept quiet…”

The simple fact that this and other blogs are discussing this in an open way is already making “food for thought” for those who are lateral thinkers.

On a non technical issue whilst I respect your right to a different view point I don’t have to respect an unwarented personal attack which is what your childish comment can be viewed as. Can I therefore suggest if you do disagree with me you stick to valid reasoning and comment, oh and perhaps come up with your own suggestions of how to go about resolving the issue at hand, otherwise people may start to suspect you are developing unsocial habits applicable to those legandary Old Norse / Scandinavian, less than attractive cave dwelling mythical beasts…

RobertT • August 29, 2012 10:53 PM

I’m actually surprised that no one has mentioned the possibility that Gauss/Godel has no payload at all, it’s just the ultimate in FUD.

From my reading of the released information we know that no standard windows PC’s have the programs that are being searched for, SO we suspect that the target PC’s must run a very unusual program (Maybe associated with some sort of military systems)

Sometimes causing an enemy unnecessary Fear is the only purpose of an exercise. They spin their wheels trying to defeat a threat that does not even exist….

Welcome to the 21st century wilderness of mirrors.

Peter Maxwell • September 4, 2012 8:47 PM

@Clive Robinson at August 29, 2012 8:28 AM

“On a non technical issue whilst I respect your right to a different view point I don’t have to respect an unwarented personal attack which is what your childish comment can be viewed as. Can I therefore suggest if you do disagree with me you stick to valid reasoning and comment, oh and perhaps come up with your own suggestions of how to go about resolving the issue at hand, otherwise people may start to suspect you are developing unsocial habits applicable to those legandary Old Norse / Scandinavian, less than attractive cave dwelling mythical beasts…”

What I said was not a personal attack, it was fair comment. If you cannot decrypt the archive, there is absolutely no way to discern any further information: it’s merely guess work and speculation. In Scotland, we call that type of talk “hot air”; there is another word for it but I suspect that would be moderated.

Anyway, I cannot decrypt it; Kaspersky seemingly cannot; nobody here can, so it’s looking pretty much like there is nowhere else to go – there is no resolving this one.

“Develop”, jeez-oh, by this point in life I suspect I’m decidedly unsociable. Perhaps it’s the Scandinavian genes in me 🙂 Thankfully, if “people” have a problem with me they can always say. Hope your week is going in well.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.