16 Feb

NetBalancer: should you trust it?

Last few months people kept bashing antivirus and security software in general. Like on Twitter or their personal pages. Sure, Twitter is full of opinionated idiots who just love to complain about everything that doesn’t match their point of view. On a few occasions they are right and even I have written about some of the issues with antiviruses before.

But!

But you’d be f*king stupid to delete your antivirus just because it has some bugs. Doorlocks get picked by criminals every day and people still use them. Professional lockpickers do exist – it’s their job to break lock’s security mechanism and get you back in the house when you lose your keys. Tavis Ormandy is a professional lockpicker – only he works in the digital world. It’s his job to break digital security mechanisms and help vendors to fix the issues.

Having said that, not all software is created equal. Sometimes new and dangerous features get added to an otherwise great software. These features look good on paper but they can really ruin someone’s day. Today, I’ll demonstrate one such feature.

Introducing SeriousBit NetBalancer

NetBalancer is a Windows application for local network traffic control and monitoring. It shows you the network traffic on your computer and helps you to set limits, priorities and rules for that traffic. Some sort of a firewall – but better. It can prioritize your traffic, schedule it for specific times, do statistics, make graphs and charts and what not. And it looks really good!

Predefined Priorities

NetBalancer’s Predefined Priorities is a feature that looks great on paper.

For those of you who are not sure what priorities are best for your PC we decided in NetBalancer 8.5 to add some predefined priorities.
These priorities include the most used programs and processes, currently about 1700 total (and counting), and are set to match the needs of most users

It could be used for virtually everything:

  • giving high priority to VoIP applications and games
  • making sure background processes (eg. software updaters) don’t interrupt your Youtube experience
  • and even blocking malware

The possibilities are endless. In fact, virtually all of the antivirus products use similar databases to preconfigure their firewalls. It makes total sense after all!

However, the devil is in the details. All such databases must be maintained. New version of Skype comes out, you need to update database. League of Legends releases new update, you must update the database. And you must do it very fast, so that your users don’t suffer from misbehaved firewall. It’s a lot of work.

Since NetBalancer is made by a small company called SeriousBit SRL, I was naturally curious how they manage to do that. smile

Inside Predefined Priorities

First, I needed to obtain the complete database of the priorities. You could try to find something in C:\ProgramData\SeriousBit\NetBalancer\ but it would be more interesting to find and download correct files for the official servers, right? smile After a quick string search, I learned that priorities can be downloaded from https://netbalancer.com/api/internal/predefinedpriorities. It’s a huge JSON file but isn’t encrypted or signed in any way.

That’s a serious red flag right there. Security companies vigorously protect their databases – it’s their know-how, their crown jewels. And they use digital signatures to make sure that the databases aren’t tampered with. After all, which developer wants to see his product in news like “MalwareBytes: multiple security issues“? smile

OK, in this case JSON file is downloaded over HTTPS, therefore it’s slightly harder to intercept traffic and modify it. So, let’s ignore this issue for a moment and look at the JSON data instead.

In a minute or two, I was in the full “WTF?” mode.

Here’s an excerpt from the JSON, prettified for easier viewing:

Setting high priority for RAR and TMP files.. More than 2000 entries like that? WTF?

How about this?

Yes, I want to download my porn with a high priority, thank you very much!

But how on earth that got through the QA process? Is there any QA process in SeriousBit SRL? I highly doubt that..

Unsolicited user data gathering

All those entries made me think – how is it possible that NetBalancer’s database contains such crap information? Most obvious answer was – it’s submitted by users. To verify the guess, I took a sneak peek inside SeriousBit.NetBalancer.Core.dll. And there it was:

The call is coming from here:

There you have it – if you have enabled “Predefined Priorities”, NetBalancer will also silently upload all your priorities to their servers.

Want to wreak some havoc with unsuspecting users of NetBalancer? Post your own JSON file that blocks all traffic for all the browsers – apparently NetBalancer doesn’t validate user submissions and will happily distribute them to other users. bigsmile

Abusing existing database

I was also wondering what is the meaning of ExeNameCrc field. smile Turns out that NetBalancer uses CRC32 of filename as a key in the dictionary that manages process priorities To make matters easier, they also supply you with a proper filename in ExecutablePath field. So, if you want to make sure your malware has unlimited traffic and high download priority, just name it swarm.exe:

Indeed, CRC32(“swarm.exe”) = 1475648703, as you can verify in some online CRC32 calculator..

A quick test confirms that too:

Conclusion

Trust is a delicate subject. On the one hand, all the Cloud and Connected things make your life much easier. On the other hand, you must choose wisely who you trust and what data he/she can access. I doubt that SeriousBit intentionally created such buggy and dangerous feature in NetBalancer. But that doesn’t mean I would ever want it to be running on my machine!

Have fun and stay safe!

27 Sep

Why I’m not using x64dbg

x64dbg is (probably) the most user-friendly x64 debugger right now. It’s pretty, it’s open-source and it usually works. But I find it very hard to switch from WinDbg to x64dbg for several reasons. Some of them are purely emotional (don’t worry, I’m not going to bore you to death explaining those) but most of them are technical and related to the way x64dbg is being developed.

So, here goes slightly exaggerated but still serious list of my grievances. smile

Insane system requirements

Both DNSpy and x64dbg suffer from this disease. They love to use the “latest and greatest” of technologies, meaning Visual Studio 2017, .NET 4.6 and what not. That’s perfectly fine when you’re writing normal software. But debugger is not a normal software.

If I have a customer with a software crashing on his production servers, I can’t tell him “You need to install Windows 7 SP2 and 3 different VS redistributables and reboot your machine twice just for me to run my debugger”. No, I really can’t.

Debugger must run on any and all systems out-of-the box. Olly does that. WinDbg does that. And it wouldn’t be hard to link x64bdg with static VS runtime libs and target WinXP while using all the modern goodies. But for some reason it’s not done that way.

Updated 30-Sep-2016: Mr. eXoDia let me know that now x64dbg is distributed together with the necessary runtime DLLs. We can remove this grievance off of my list. Hooray! smile

Uncertain direction and feature bloat

Antoine de Saint Exupery said:

Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away

These are really wise words and Olly is designed that way. It does all the basic stuff and has stable SDK that enables plugin authors to implement all the extras.

On the contrary, Mr. eXoDia is adding features left and right and the direction of x64dbg development looks more like this:
BrownianMovement

For example, why does a debugger need 3 (yes, three!) different assembler engines?
assemble

Want another example? Let’s just look at the latest weekly digest.. How about this:

… change to the info box. Basically the pointer values in the instruction were not resolved (so if the instruction contained qword ptr ds:[rsp+30] it would not show the value of rsp+30). Personally this is quite useless

Yes, Mr. eXoDia, you’re right. It is useless for everyone but few people.

And how about:

The commands plugload and plugunload have been added. This is useful for plugin developers who want to test plugins without having to restart x64dbg all the time.

How many people in the entire world will actually benefit from that? 5? 10?

So, why add such bloat? Once you add something, that something must be maintained. And it’s very hard to remove stuff later, as it might break something else. So, please don’t..

Broken features

When I am on a job and need to debug something, last thing I want to spend my time on, is fighting with debugger bugs. And my customers certainly don’t want to pay me for doing that.

Oleh Yuschuk got it exactly right with the OllyDbg. There were few releases – but they were properly tested and rock solid. From what I can see, x64dbg is going the other way:
compiles_ship_it

Frequent commits like “Fixed search for constant references”, “Fixed intermodular calls in module”, “Fixed FS/GS memory branch destinations” is not something you want to see in any software, let alone a debugger.

Well, it wouldn’t matter much, if there was some known-stable version I could put in my tool collection and use it anytime anywhere. But no, Mr. eXoDia thinks that “No more excuses to not update every day!” is a way to go. Instead of using tried-and-tested version, I should use a probably buggy and unstable one? Dafuq?

Conclusion

So, those are my 3 biggest complaints about x64dbg. I’d love to love x64dbg. I’d love to use x64dbg for everything. But right now I just can’t.

How about you?

21 Sep

IDA bug in PE export processing

Hi, I’m back from vacation. And now I’m catching up on all the things that have happened during that time. So, here’s a short writeup regarding publicly-known IDA bug and how it will (not) affect reversers.

It was supposed to be a long post showing how to use PatchDiff to locate patched code and then backport it. But, as you’ll see later, that’s not necessary at all. Maybe another time..

Initial research by Palo Alto

When checking my RSS feed, I stumbled upon the article by Palo Alto researchers called “The Dukes R&D Finds a New Anti-Analysis Technique“. It stated:

Using the exported functions by ordinal meant the exported function name was unnecessary, which allowed the developer of this DLL to leave the names for the exported functions blank … The less obvious reason is that it takes advantage of a bug in the popular IDA disassembler that was recently fixed in the latest version of IDA.

Bug in IDA?! How nice, I want to test this!

Testing the bug

Palo Alto report contained most of the information to reproduce the issue. But IDA 6.95 changelog was even more detailed about what was fixed:

BUGFIX: PE: IDA would not detect DLL exports with empty names
BUGFIX: PE: IDA would show no exports if the export directory’s DLL name was an empty string

Armed with the detailed description, I used MASM32 package and their Examples to build a DLL file.

Empty DLL name

First, I took hex editor and changed DLL name in export directory.
export_dll_name_1
export_dll_name_2
Now the exported DLL name is 0-length string. Let’s see what IDA does..

I started with IDA 6.95 Demo you can download from official site. No surprises here, the bug is fixed:
export_dll_name_IDA695

Then I took legit copy of IDA 6.90. As already demonstrated by Palo Alto, it’s buggy:
export_dll_name_IDA690

Naturally, I wanted to see how old this bug is. So, I took a copy of IDA 6.80. Surprise, surprise, it’s not buggy!
export_dll_name_IDA680
So, it looks like this bug was introduced in IDA 6.90.

Empty export name

For completeness sake, I repeated the experiment with empty exported API name.
export_api_name_1
export_api_name_2
The results were identical, the bug is only present in IDA 6.90.

How it affects you?

If you’re using IDA Free, latest version is 6.95. You’re good.
If you’re using legit IDA, you have received the updated version 6.95. You’re good.
If you’re using the latest publicly leaked version of IDA (6.80), it didn’t have the bug. So, you’re good, too.

To sum it up – it’s a fun bit of information but no one is really affected. Good news, I guess. smile

Example DLL files if you want to verify your tools: https://www.mediafire.com/?c9t6hm4icd3kk46

28 Jun

Bugs in Enigma Virtual Box

While working on a new version of my static EnigmaVB unpacker, I tried to generate test files to cover most of the Enigma Virtual Box features. In the process, I ran into quite a few bugs in Enigma Virtual Box v7.40.

So, here’s a short list:

Registry virtualization

1. Importing REG file with wrapped lines:

Data get truncated at the end of first line.

2. Importing REG file with entry type REG_NONE:

It gets virtualized as a string value “hex(0):”

File virtualization

1. If size of any embedded file > 4GB: creates invalid x86 executable;
2. If total size of all embedded files > 4GB: creates invalid x86 executable;
3. If size of main EXE > 2 GB: creates executable that seems to be valid but won’t run;
..and that’s only for x86 executables. I wonder how many more issue will surface when I start testing x64 executables. wink

TLS callbacks

Since Enigma Virtual Box uses TLS callbacks to initialize its hooks and handlers, it will (accidentally?) break any executable that also uses TLS callbacks. However, it preserves TLS StartAddressOfRawData, EndAddressOfRawData and AddressofIndex fields. Very weird.. smile

Have fun (and remember to test your software properly)!

06 Jun

CFF bug in RVA2Offset

Yes, this is yet another post about bugs in CFF Explorer. So far I’ve described:

Today, I’ll describe an issue with CFF Explorer’s RVA2Offset function and provide a solution to the problem (patched executable).

And no, I really don’t hate CFF Explorer. In fact, it’s one of my favorite tools and I use it every day – that’s why I keep noticing more and more issues with it. wink

Introduction

Here is an executable that demonstrates the bug: https://www.mediafire.com/?9ju0cfm36b32ys9

If you open it in CFF Explorer and try to check Import Directory. In this case, CFF will show that it’s empty.

cff_bug_empty_imports

That’s incorrect, import directory of this executable is present and valid. It contains 2 DLLs and 3 APIs:

actual_imports

In other executables, it can get stuck into eternal loop or – even worse – show incorrect data.

Also, CFF’s Address Converter feature is affected. In my demo executable, try convert RVA 0x2000 to file offset. It will return 0:

CFF_address_converter_bug

So, what’s happening here?

Background of the bug

To put it simply, bug is triggered when one section in executable has SizeOfRawData much larger than VirtualSize. In my crafted executable it looks like this:

CFF_cause_of_bug

Nitpickers corner: it’s actually more complicated. The exact condition is ALIGN_UP(sec.SizeOfRawData, pe.FileAlignment) > ALIGN_UP(sec.VirtualSize, pe.SectionAlignment). But who cares about those small details, anyway?

And the offending pseudo-code in CFF Explorer looks something like this:

Fixing the bug

Since I’m doing binary patches to CFF Explorer, I’m quite limited to what I can do and how. In the end, I chose the following pseudocode:

While it doesn’t look like much (and it doesn’t cover edge cases, for example, when PE file is truncated), in general it should work just fine.

Download link for fixed CFF Explorer: https://www.mediafire.com/?5eg1bs9a9bv39ge
It also includes all my previous fixes.

Conclusion

While writing this post, I noticed that PE viewer in ExeinfoPE v0.0.4.1 has very similar bug. And ProtectionID v6.6.6. And PETools 1.5 Xmas edition. And Stud_PE 2.1. And LordPE. And then I ran out of tools to test. bigsmile

Obviously, I can’t fix them all. All I can say – use PE editing/viewing tools that actually work, for example, HIEW or IDA. And when you’re writing your own PE parser library, make sure you test it on weird executables.

Have fun and stay safe!

Further reading