Everyone has had that dreaded experience: you open up the task manager on your computer... and there’s a program name you don’t recognize. It gets worse when you google the name and can’t find a concrete answer on what it is and why it’s there. It gets even worse when you remove it from Autoruns and it comes back. It gets terrible when you realize it has keylogger functionality. The icing on the cake, however, is when the mystery program is also eating up all your RAM.

The RAM issue is actually how this special little program on my own computer came to my attention. I recently bought a high-end Windows 8 tablet – to protect the guilty, we’ll call the manufacturer “Spacer”. Like most Windows computers, it came with an assortment of apps preinstalled by “Spacer”, ranging from the mildly useful to trash you delete without hesitation. In particular, I liked the interface that popped up when I plugged into HDMI, so I didn’t go on a vendor utility murdering spree. I happened to have Resource Monitor open, and I noticed that the second-most RAM-hungry program was... a “Spacer” background service with a generic name, consuming 280MB. Not bad for a 15KB binary! Googling the name, “MEMS Enhancement Utility”, only turned up other customers wondering what it was and observing that getting rid of it didn’t seem to break anything. I disabled it and rebooted, but it came back. Presumably, one of the “Spacer” apps was serving as a watchdog for the others. The easy solution is to simply get rid of the program altogether, but I decided to investigate what made this program so important in the first place.


Figure 1: Not the most clarifying metadata

It turns out that the program was written in .NET, which is vastly easier and faster to reverse-engineer than conventional native binaries. At Veracode, we have our own internal tools for automated analysis of .NET programs, but for interactive purposes, I recommend the free JetBrains dotPeek.  When starting an investigation of a binary, I like to take a quick tour of bundled functionality.


Figure 2: Imported Namespaces

Aside from the typical imports, Windows7.Sensors is a fairly self-explanatory name, and is in fact just a sample code kit off MSDN for reading the tablet’s accelerometer. That’s interesting but rather benign functionality. Far more... concerning is the member variables and methods of the “gma” namespace.


Figure 3: Consider my eyebrows raised

This is, of course, the classic sign of a userspace keylogger, but for every keylogger out there, there are a hundred legitimate apps who hook the keyboard and mouse for perfectly sensible reasons; otherwise, why would it even be in the standard Windows API? I was, however, beginning to question the provenance of this application. The actual logic of the utility, however, was... puzzlingly brief. It initiated a nearly-empty form and hid it. It set up handlers to receive keyboard, mouse, and accelerometer activity. It then set up timers to poll the accelerometer based on how long it’d been since the last keyboard or mouse activity. And that’s it. That’s all. The application does not store or transmit or even display the information polled. It does nothing. I spent the better part of two hours scouring the obscure corners of the binary, thinking surely I must be missing some cleverly hidden method that actually uses this data. I couldn’t find one.

Putting aside this issue for now, I couldn’t help but think: why in the world is this little app ballooning into hundreds of megabytes of RAM? That’s usually the sign of a runaway memory leak, but in a pure .NET application, such things are actually difficult to cause, whereas in a C/C++ program they’re very difficult not to cause. The answer lies in the fact that the sensor-reading DLL uses marshaling to interact with native APIs, and actually calls traditional memory allocation routines. Hence, every time the accelerometer is polled, manual allocations are made that may or may not ever be manually freed depending on control flow.


Figure 4: One of the places where the sensor glue code indulges in manual memory management

Violently shaking the tablet (is this thing still under warranty?) causes the RAM usage of “MEMS Enhancement Utility” to spike, but not all at once, as the accelerometer reader is going off at timed intervals rather than constantly. The memory usage will balloon by several megabytes every time I shake the tablet, and after a few minutes, some of it will be reclaimed by the garbage collector but some will not. Hence, the base RAM usage of the process steadily creeps upwards. So now we know what the program does and why its memory usage is so high, but that still leaves the question of why it’s doing this at all. The clues are there, vestigial remnants of removed code, exciting to any Executable Archaeologist:


Figure 5: Declared variables of the main form

The generically named “Form1” of the application contains several widgets which are never actually displayed: a start button, a stop button, a place for displaying mouse coordinates, and a text box for displaying some other unspecified data. I believe this was originally a debugging utility used by “Spacer” engineers to calibrate the accelerometer so that it would not go off when one simply tapped on the touchscreen (triggering a mouse event or keyboard event). They didn’t bother to rigorously prevent memory leaks because it was never intended to run for more than a few minutes at a time. Somehow, through some miscommunication, a copy of this program with the logic for rendering the visuals stripped ended up on the list of utilities that needed to be kept in the final version of “Spacer’s” Windows 8 image for this model of tablet. Someone then dutifully registered it to be launched in the background every time the tablet boots, and every time the tablet is tilted, shaken, or prodded a little too hard, the RAM usage goes up.

Never attribute to malware what can be adequately explained by a few lines of debugging code somebody forgot to disable.

About Melissa Elliott

Melissa Elliott is an application security researcher who has been writing loud opinions from a quiet corner of the Veracode office for two years and counting. She enjoys yelling about computers on Twitter and can be bribed with white chocolate mocha.

Comments (13)

Vitaliy | May 13, 2013 8:41 pm

You should try using ildasm.exe that is bundled with VS .Net.

Matt Lacey | May 14, 2013 12:41 am

Great read! I recently purchased a Samsung hybrid device which runs Windows 8 and was appalled by the amount of crap that came preinstalled.

Don't get me wrong, it's a great machine and great to use, but when you ship a device has having 64GB of storage and then provide the end user with around 12GB something is seriously wrong. Having removed a bunch of the rubbish that was preinstalled (including a copy of Acrobat Reader weighing in at half a gigabyte!) and the recovery partition I've clawed back some usable space. I guess next stop is to check out the running processes!

Naz Mir | May 14, 2013 2:54 am

It was an interesting read. Thanks for taking the time to explain.

Toni | May 14, 2013 7:00 am

Just in case anyone is wondering, it's an Acer.

Mike | May 14, 2013 9:13 am

Naver attribute to malware ...

Mikko Hanlon's razor ?

Lex | May 14, 2013 9:56 am

Good job, and thanks for suggesting DotPeek; that'll help in a SW QA task I'm involved in.
So, how did you permanently disable this memory leech? Rename the executable in safe mode? Won't Win8's internal binary protection scheme just replace the now-missing file at some point?

http | May 14, 2013 3:20 pm

That's the reason I *always* do a fresh reinstall every new computer from an original Windows disk. You have to search for the correct drivers (I mostly find newer drivers anyway) and stuff, but you know what you get that way.

Ah, and the name "Spacer" is a funny choice. That sounds almost like a big commonly known manufacturer if you shorten it a bit.

thev0id | May 14, 2013 5:39 pm

I knew it was "Spacer". Nice post, really worth the time.

Aaron P Rykhus | May 15, 2013 12:13 am

Good explanation of code debugging to determine root cause analysis. That's why I like programmers. dotPeek looks interesting, installed it just now. Tools that I use for scenarios like this also include Resmon.exe (Resource Monitor), Process Explorer and Process Monitor from sysinternals. I think there's CLR tools out there similar to MFC tools like MFCMAPI for email.

export | May 16, 2013 5:08 pm

pardon this software advertisement. dotpeek is pretty cool, but you should also check out ILSpy. i'm an opensource zealot, and that's a huge perk being able to write plugins and modify the app if you need to.

@Vitaliy: ilasm/ildasm is pretty much only good for patching your .NET binary.

Ed | May 30, 2013 11:10 am

Fabulous post! This utility has been bugging me for a while now. I disabled it using CCleaner's startup tools, for what it's worth. It certainly doesn't seem to be back yet. The line is "MEMS_Schedule" and calls "C:Program FilesAcerMEMS enhancement utilityMEMS enhancement utility.exe".

Ajinkya | January 27, 2014 12:25 am

I don't like programmers, who doesn't treat resource with care, this is not an isolated case, Programming is full of careless developers.

mrbil | March 14, 2014 1:32 am

That's great and all. I wonder how many poor sufferers of this sloppy code found this excellent analysis, read all that and just wondered why that really smart person revealed all that but DIDN'T TELL HOW TO GET RID OF IT. ;(

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.