BTVStack.exe requesting access to Skype on every startup

kao

Background

At home I'm using a desktop computer. It has ASUS motherboard with Atheros Bluetooth chip. I have all the drivers installed but I'm not using Bluetooth at all.

Problem

Some time ago I started getting these notifications every single time I started Windows:
btvstack_skype

btvstack.exe is requesting access to Skype. Only allow access to programs downloaded from a trusted source as they will be able to use information such as your Skype contacts and messages.

No matter what option I selected, it would ask me again on next reboot. Bloody hell!

If you google for the solution, you'll notice that:

  1. It's a quite common problem;
  2. Most common solution is to deny/allow access either using the dialog above, or Tools->Options->Advanced->Advanced Settings->Manage other programsโ€™ access to Skype;
  3. Another solution for Windows 8+ is to deselect "Allow Bluetooth devices to send you PIM items such as business cards, calendar items, e-mail messages, and notes. " in Bluetooth Control Panel applet;

Unfortunately, first solution was not working for me. And second solution is not feasible because there is no such option in Windows 7 Control Panel.

Solution

Since I don't need Bluetooth but I don't like to have broken drivers, I decided to disable just the offending DLL. From the elevated command-prompt I ran

regsvr32 /u "C:\Program Files (x86)\Bluetooth Suite\SkypeAgent.dll"

and the problem has disappeared. Great success! ๐Ÿ™‚

Hope this helps someone else too.

Beautiful code

kao

After making quite a few unpackers and other RE-related tools, publishing sources for them and having to maintain and bugfix them, all I can say is: "Read this. Remember this. Worship this."

All code is born ugly.

It starts disorganized and inconsistent, with overlaps and redundancies and gaps.

We begin working it into an imperfect solution for an often poorly defined problem.

As we start building up like clay, a solution starts taking form. The feedback guides us in moving, removing and adding material. It allows us to add and remove details. We learn from our mistakes.

Thank you, Dennis, you made my day so much better.

Quickpost: application reversing becoming legal in USA?

kao

Last Friday authors of Dotfuscator made quite an interesting blogpost, claiming that reverse engineering applications in USA is becoming a legal means for acquiring intellectual property, thanks to the Defend Trade Secrets Act of 2016.

I am not a lawyer, and such statements coming from authors of obfuscator should be taken with a grain of salt - but it's an interesting read nevertheless. What's your take on that?

CFF bugs in processing managed resources

kao

Users on tuts4you quite often ask questions like "Can you identify which obfuscator was used". When I was analyzing one such assembly, my CFF Explorer started to act erratically. New tabs would not open and on exit CFF Explorer crashed with access violation.
CFF acting up
That's weird, I said to myself and decided to figure out what's causing it.

Uninitialized buffers and unchecked return values

First bug is a classic. In pseudo-code it looks like this:

bool ReadResourceHeader(ManagedResource resource, ResourcesInfo *info)
{
   DWORD MagicNumber = ReadDword();
   if (MagicNumber != RESOURCES_MAGIC_NUMBER)
      return FALSE;

   if (FAILED(ReadSomething(&xyz)))
      return FALSE;
   info.FieldX = xyz;
   ...
   return TRUE;
}

void BuggyFunction()
{
   ResourcesInfo info;
   foreach (ManagedResource resource in exefile)
   {
      ReadResourceHeader(resource, &info);
      for (int i = 0; i < info.EntryCount; i++)
      {
          ...
      }
   }
}

First issue is that nobody initialized ResourcesInfo structure, so all fields will initially contain random garbage. As soon as ReadResourceHeader fails to read or validate something, it returns, and lots of fields will still contain random garbage.

It wouldn't be a big problem, if Daniel checked the return value of the function. But his code just continues processing even if the data initialization failed. And, to make matters worse, it just hides all exceptions by putting try-except handlers around most of the code. No wonder CFF is occasionally acting weird! ๐Ÿ™‚

This bug is quite hard to demonstrate, as it needs to have few lucky coincidences in the uninitialized data. But I'm sure that a skilled person would convert it into arbitrary code execution in no time. Not me, though... ๐Ÿ™‚

Buffer overflow

Second bug is also a classic. In pseudo-code it looks like this:

WCHAR Str[MAX_PATH];
ZeroMemory(Str, MAX_PATH * sizeof (WCHAR));
if (!DecodeInt(ptr, &NameSize, &ValueSize))
   return FALSE;
memcpy(Str, ptr, NameSize);

So, what's wrong here? Daniel takes a fixed-size buffer and initializes it with all zeros (unlike previous case). Then he reads size of data (NameSize). And then he copies NameSize bytes into a fixed-size buffer - without checking if that's gonna overflow or not.. Yikes!

Example file demonstrating this bug: https://www.mediafire.com/?x4idsa21toh0t36 (you need to click on Resource Editor -> .NET Resources to trigger the buggy code. Afterwards, CFF Explorer will start acting weird).

Solution

Just like in a previous case where I added support for ConfuserEx and undocumented fields, I had to make few binary patches to CFF Explorer.

Fixed exe file is here: Please get latest version from this post

Have fun and stay safe!