CamelCase is mingled with upper and lower case VERBOSE_DEFINITIONS separated_by_underscores. This lack of a clear coding style may be visually annoying, but can be added during a final obfuscation step. The unstyled code may not be present in the unobfuscated repo, and does not necessarily indicate the presence of conflicting coding styles on the malware team.
The properties table called flame_props is created and populated inside of a deeply nested if-statement. Are all other branches of this function forced to operate without a valid properties table? This is not an obvious design choice for any programmer who values harmony in a team working on a shared codebase. Perhaps the Lua coder worked alone. Also, this kind of wtf_logic is difficult to insert later as obfuscation.
On lines 2 and 4 of the example, the Flame Lua supervisor appears to be loading text from an external source and eval'ing it as code. Lua distributions have long offered an entire API for managing and loading modules. Breaking a large project into modules is a standard practice. Reinventing a module loading tool, then, is probably not a path to reliability. The module loading code in Lua is a time-tested grab bag of platform-specific heuristics and yet is still a frequent topic of discussion on the mailing list. Given the multi-platform operating requirements of the program, reinventing it doesn't seem like the most robust design decision.
Similarly, the flame_props table is initialized with strings that looks like the names of entries in property tables of other modules. Why is there not a central way to create and populate these tables? Requiring conversion of "string dot string" into a clean table reference before use seems to unnecessarily add danger to the setup code.
Although I keep referring to a possible obfuscation step, I don't see strong evidence for one. The code uses variable names like SUCCESSFUL_INTERNET_TIMES_CONFIG next to l_1_0 and l_1_1. The short names are quite likely to cause new bugs due to typos, yet the long is very descriptive, almost self-documenting. I have seen code like this before -- it came from neglect bordering on malice, not from deliberate obfuscation.
CamelCase is mingled with upper and lower case VERBOSE_DEFINITIONS separated_by_underscores. This lack of a clear coding style may be visually annoying, but can be added during a final obfuscation step. The unstyled code may not be present in the unobfuscated repo, and does not necessarily indicate the presence of conflicting coding styles on the malware team.
The properties table called flame_props is created and populated inside of a deeply nested if-statement. Are all other branches of this function forced to operate without a valid properties table? This is not an obvious design choice for any programmer who values harmony in a team working on a shared codebase. Perhaps the Lua coder worked alone. Also, this kind of wtf_logic is difficult to insert later as obfuscation.
On lines 2 and 4 of the example, the Flame Lua supervisor appears to be loading text from an external source and eval'ing it as code. Lua distributions have long offered an entire API for managing and loading modules. Breaking a large project into modules is a standard practice. Reinventing a module loading tool, then, is probably not a path to reliability. The module loading code in Lua is a time-tested grab bag of platform-specific heuristics and yet is still a frequent topic of discussion on the mailing list. Given the multi-platform operating requirements of the program, reinventing it doesn't seem like the most robust design decision.
Similarly, the flame_props table is initialized with strings that looks like the names of entries in property tables of other modules. Why is there not a central way to create and populate these tables? Requiring conversion of "string dot string" into a clean table reference before use seems to unnecessarily add danger to the setup code.
Although I keep referring to a possible obfuscation step, I don't see strong evidence for one. The code uses variable names like SUCCESSFUL_INTERNET_TIMES_CONFIG next to l_1_0 and l_1_1. The short names are quite likely to cause new bugs due to typos, yet the long is very descriptive, almost self-documenting. I have seen code like this before -- it came from neglect bordering on malice, not from deliberate obfuscation.
There is plenty more in there.
[0] "What's in a name?" http://www.lua.org/about.html#name