Consuela works with a senior developer who has been with the company since its founding, has the CEO’s ear, and basically can do anything they want.
These days, what they want to do is code entirely locally on their machine, hand the .NET DLL off to Consuela for deployment, and then complain that their fancy code is being starved for hardware resources.
Recently, they started to complain that the webserver was using 100% of the CPU resources, so obviously the solution was to upgrade the webserver. Consuela popped open ILSpy and decompiled the DLL. For those unfamiliar with .NET, it’s a supremely decompilable language, as it “compiles” into an Intermediate Language (IL) which is JIT-ed at runtime.
The code, now with symbols reinserted, looked like this:
private static void startLuck()
{
luck._timer = new Timer(30000.0);
luck._timer.Elapsed += delegate
{
try
{
luck.doFiasco().ConfigureAwait(true);
}
catch (Exception)
{
}
};
luck._timer.Enabled = true;
luck._timer.Start();
Console.WriteLine("fabricating...");
Console.WriteLine(DateTime.UtcNow);
while (true)
{
bool flag = true;
}
}
The .NET Timer
class invokes its Elapsed
delegate every interval- in this case, it will invoke the delegate
block every 30,000 milliseconds. This is not an uncommon way to launch a thread which periodically does something, but the way in which they ensured that this new thread never died is… interesting.
The while (true)
loop not only pegs the CPU, but it also ensures that calls to startLuck
are blocking calls, which more or less defeats the purpose of using a Timer
in the first place.
Consuela pointed out the reason this code was using 100% of the CPU. First, the senior developer demanded to know how she had gotten the code, as it was only stored on their machine. After explaining decompilation, the developer submitted a new DLL, this time run through an obfuscator before handing it off. Even with obfuscation, it was easy to spot the while (true)
loop in the IL.