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
        catch (Exception)
    luck._timer.Enabled = true;
    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.

[Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!