3 ms·

GNU confirmed as Equation Group: https://godbolt.org/g/EDvrn2 https://godbolt.org/g/EDvrn2. Wait, MSVC does this too---they're all in cahoots! $LL8@f:

by pbsd 10y ago

GNU confirmed as Equation Group: https://godbolt.org/g/EDvrn2 https://godbolt.org/g/EDvrn2. Wait, MSVC does this too---they're all in cahoots! $LL8@f: ; Line 4 mov ecx, DWORD PTR [edx+eax*4-4] sub ecx, 1640531527 ; 61c88647H mov DWORD PTR [edx+eax*4], ecx inc eax cmp eax, 44 ; 0000002cH jl SHORT $LL8@f Flipping the sign of addends is a common compiler transformation, likely there to optimize for code size in some cases. Unless that code looks weird enough that it _had_ to be coded by hand, that constant switch doesn't mean much of anything.

nkurz 10y ago
I started writing a reply along the lines of "you may be misinterpreting the authors", but looking more closely I agree that their logic is particularly flimsy here. They explain their reasoning more fully in a 2015 piece, where they concluded that two code bases were distinct because they used different constants: Searching for "0x61C88647 0xB7E15163" on Google results in barely two pages of results, indicating this combination of constants is relatively rare. Most of the hits are on Chinese forums. Searching for the 2-inverse constant "0x9E3779B9 0xB7E15163" results in a whopping 2500 hits. ... This suggests that the EQUATION group and the Regin group are two different entities. https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf https://securelist.com/files/2015/02/Equation_group_question..., page 28. They seem to be totally ignoring the fact that Google is more likely to index text files than binary executables and short lived assembly temp files. If you search on Google, you do indeed find source files with the "0x9E3779B9 0xB7E15163" pair, which makes sense as these are used in the reference implementation: https://tools.ietf.org/html/rfc2040 https://tools.ietf.org/html/rfc2040. But as you say, if you compile the reference implementation, you are likely to produce an executable which contains the negated form. If you then "decompile" this executable, you get the "rare" pair, where "rare" just means that Google is more likely to index the input source code than compiler generated assembly or the output of 'objdump'. I think you nailed it --- all the compilers are in cahoots, and the perpetrators can assumed to be using one! But not Clang, which gamely tries to vectorize. What's less clear is whether the authors of the exposé are charlatans or just "logically challenged". Since they are obviously smart enough to be working for the "goto source" for commentary on these issues, I'd be inclined to guess "charlatan".

by pbsd 10y ago

nkurz 10y ago

I started writing a reply along the lines of "you may be misinterpreting the authors", but looking more closely I agree that their logic is particularly flimsy here. They explain their reasoning more fully in a 2015 piece, where they concluded that two code bases were distinct because they used different constants: Searching for "0x61C88647 0xB7E15163" on Google results in barely two pages of results, indicating this combination of constants is relatively rare. Most of the hits are on Chinese forums. Searching for the 2-inverse constant "0x9E3779B9 0xB7E15163" results in a whopping 2500 hits. ... This suggests that the EQUATION group and the Regin group are two different entities. https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf https://securelist.com/files/2015/02/Equation_group_question..., page 28. They seem to be totally ignoring the fact that Google is more likely to index text files than binary executables and short lived assembly temp files. If you search on Google, you do indeed find source files with the "0x9E3779B9 0xB7E15163" pair, which makes sense as these are used in the reference implementation: https://tools.ietf.org/html/rfc2040 https://tools.ietf.org/html/rfc2040. But as you say, if you compile the reference implementation, you are likely to produce an executable which contains the negated form. If you then "decompile" this executable, you get the "rare" pair, where "rare" just means that Google is more likely to index the input source code than compiler generated assembly or the output of 'objdump'. I think you nailed it --- all the compilers are in cahoots, and the perpetrators can assumed to be using one! But not Clang, which gamely tries to vectorize. What's less clear is whether the authors of the exposé are charlatans or just "logically challenged". Since they are obviously smart enough to be working for the "goto source" for commentary on these issues, I'd be inclined to guess "charlatan".