Code dumped online came from “Omnipotent” NSA-tied hacking group

Kaspersky Lab analysis means Monday's leak almost certainly came from Equation Group.

Read the whole story

 

[pjlahaie]

beebee[/url]":335xhu0i]Mind you my mind is still confused how using a negative constant saves time. But I assume there is some nuance someone will explain eventually in the comments.

One explanation could be that the CPU can perform an addition faster than a subtraction.

 

[pjlahaie]

orome[/url]":1ebl4pfg]subtraction and addition are usually the same operation in the ALU, with subtraction adding two's complement transformation before feeding the data to the adder (so you basically do a + ~b + 1). my theory is that you save the time to do the two's complement transformation.

And you save the energy to do that transform. I'm not saying that's why they did it but it could be. CPUs have always had strange instruction performance characteristics. I (very) vaguely remember of a somewhat common C statement that was best encoded using instruction X on a 486, using Y on a Pentium and back to using X on the Pentium Pro.

Parts of me want to say "* 2" using shift vs the multiply instruction but it was so long ago I forget the details.

 

[pjlahaie]

beebee[/url]":2k82fmcd]

pjlahaie[/url]":2k82fmcd]

beebee[/url]":2k82fmcd]Mind you my mind is still confused how using a negative constant saves time. But I assume there is some nuance someone will explain eventually in the comments.

One explanation could be that the CPU can perform an addition faster than a subtraction.

In twos compliment, the operation is the same.

Except performing the ~ operation might add a cycle to the the execution time. It can also require extra energy to perform.

One thing to keep in mind is these crypto guys don't always run compilers at the highest level of optimization, so maybe with optimization turned off or at a low setting, using the negative constant is more efficient.

Also if there is a performance/power advantage to using the addition, a good optimizing compiler will automatically convert the - <constant> operation into a + (~<constant>+1) operation which would negate doing it in the code.

Another reason (as was somewhat pointed to earlier) is that the well known constant won't show up while disassembling the code. Chances are if you see subtract 0x9E3779B9 in the instruction stream you're looking at code implementing RC6.

 

[pjlahaie]

orome[/url]":92zkn2i5]it'd be strange to see hackers concerned about energy use of their victim computers , monitoring energy use would be a novel way of detecting malware.

Hacking tools aren't malware and they often run on the hacker's computer not the victims. Malware is what you would inject after the hacking tools do their jobs.

I've seen crude versions of that detection method being used. We had a machine with a variable rate CPU fan that started to run at full speed 100% of the time. Looking at the system, we saw almost no load on the CPU. We powered down, unplugged the disks, booted off optical media and the CPU fan was running normally. Reboot to the disks in single user mode, CPU fan hits full speed within a few seconds of the kernel finishing booting. Shutdown server, remove drives, install new drives, re-install, restore data from backup. Going through the old disks on another system (reading the FS with command line utilities) revealed the presence of a pretty persistent rootkit. Luckily they left the file timestamps intact which made tracking down the point of intrusion rather easy.

 

[pjlahaie]

Rene Gollent[/url]":3nj2973k]

Parts of me want to say "* 2" using shift vs the multiply instruction but it was so long ago I forget the details.

This one isn't so much CPU specific as that it was a generally commonplace optimization before compilers became smart enough to recognize it automatically, since mul and div (particularly the latter) are by far the most expensive math instructions on pretty much every general purpose arch out there, while shift is among the cheapest.

Yeah, it was the multiply vs shift. But not 486 -> Pentium -> PPro but Pentium 3 -> Pentium 4 -> Core. Which makes sense since the Core processor is essentially a tweaked Pentium 3 core. The Pentium 4 dropped the high speed barrel shifter (present in i386+) with a shift/rotate execution unit running at the CPU clock rate whereas the multiply instruction was running at 2x clock rate (double pumped).