Security Essentials Rogue AV Anti-Debugging

While Microsoft Security Essentials is a legitimate AV software, there's also a rogue AV going by the same name.
Usual story, fake alerts constantly popping up, enticing the user to "buy" a licence...



With no surprise, the sample I was looking at calls home in Latvia.

whois 85.234.191.185
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: This output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '85.234.190.0 - 85.234.191.255'

inetnum: 85.234.190.0 - 85.234.191.255
netname: ATECH-SAGADE
descr: Sagade Ltd.
descr: Latvia, Rezekne, Darzu 21
descr: +371 20034981
remarks: abuse-mailbox: piotrek89@gmail.com
country: LV
admin-c: TMCD111-RIPE
tech-c: TMCD111-RIPE
status: ASSIGNED PA
mnt-by: AS6851-MNT
source: RIPE # Filtered

role: TMCD Admin Contacts
address: Ieriku 67a, Riga, LV-1084
org: ORG-TMDA1-RIPE
e-mail: bkc@bkc.lv
admin-c: AS1606-RIPE
admin-c: TP422-RIPE
tech-c: RF2443-RIPE
tech-c: IR106-RIPE
nic-hdl: TMCD111-RIPE
source: RIPE # Filtered

% Information related to '85.234.160.0/19AS6851'

route: 85.234.160.0/19
descr: BKCNET Autonomous System
descr: IZZI SIA
descr: Ieriku 67a, Riga, LATVIA
origin: AS6851
mnt-by: AS6851-MNT
source: RIPE # Filtered

Enough with the boring stuff...

The funny part starts right at the entry point. A quick look at the disassembly reveals that this piece of crap overwrites its own code with the opcode 0x43 (INC EBX) via REP STOSB.



The puzzling detail is that the REP STOSB instruction will be overwritten as well.
And, indeed, if we step trough this code, we end up with that:



Indeed, when single stepping, the debugger executes only one instruction (i.e one iteration of REP) and ends up executing the overwritten bytes.
When the JNZ is reached, ECX equals 1. This is because REP STOSB has been overwritten before the last iteration of STOSB (That's why only half of REP STOSB has been replaced by 0x43).
The jump is taken and the sample quits after showing a dialog box reading "BitDefender". Might be complete crap or a way for the bad guys to underline that BitDefender's emulator cannot handle properly this code. However, I won't bother checking this...

If, instead of single stepping, you set a breakpoint on the JNZ and run the debuggee, the behaviour is different. REP STOSB is executed normally (atomic execution) and ECX equals 0 when the conditional jump is reached.
And malware happily keeps running...

Not very stealth but a nice little anti-debugging and maybe anti-emulation trick.