Author Topic: Explaining DLL Injection to the layman  (Read 14275 times)

Offline Jeremy Collake

  • Administrator
  • Member#
  • *****
  • Posts: 5410
  • Gender: Male
  • The Lasso
    • Bitsum
Explaining DLL Injection to the layman
« on: May 08, 2012, 05:48:06 PM »
DLL Injection is one of the largest problems with (Windows) PC stability. The problem is that this is a very technical subject .. so, to explain it in an understandable way to non-programmers requires some effort.

First, let's define what a DLL is. A DLL is like an EXE. They are both in the same format, called PE. The acronym was formed long ago, and the backing definition will confuse you, so ignore it.. but it is Portable Executable. Nothing at all to do with being 'portable', as with thumb drives or such.

The only difference is between an EXE and a DLL is that a DLL has a different type of 'entry point'. Again, here we go with the Jargon. Let's just say -- they both contain blocks of code and data.

DLLs are typically made when one or more applications, or instances of an application (a process), needs the same code and data. That way, the process can simply load that DLL, and there is the code and data it needs.

DLL injection is when a program does *not* need the DLL, but the DLL is shoved into the program anyway. This is most often done by a Windows mechanism known as 'global message hooks'. These message hooks are intended to allow for interception of hotkeys or other operations by third-party software. In order for them to work, they must map a DLL into a process, so that DLL's code can be there to intercept the messages. The next most popular type of injection is done to hook APIs the program may call and modify their input or output.

So, an injected DLL is something the program didn't ask for, but got. Now, if the code in this DLL crashes, what can this program do? Not much. It wasn't its code that crashed, it was the DLL. Can the DLL be forcibly removed? Lets just say it isn't feasible, because it isn't. Forget wildly impractical theories and its a plain NO, they can't be forcibly removed from the program once loaded.

When you have so many programs on your PC that use DLL injection for various purposes, then sometimes you can have big problems. These DLLs may crash some random program, and you're thinking -- why did this program just crash? Naturally, you think it is the program's fault - and it might be. However, it might also be an injected DLL.

Does this make sense to non-programmers? Of course, you need to be a bit tech savvy at least.

« Last Edit: May 08, 2012, 11:40:35 PM by bitsum.support »
Software Engineer. Bitsum LLC.

Offline Wind_it_up

  • New
  • *
  • Posts: 4
Re: Explaining DLL Injection to the layman
« Reply #1 on: October 22, 2012, 12:36:15 PM »
It is funny that you are writing this on your forum, the entire reason I wanted to use BitSum Process Lasso was because of vendor .dll patching.

From a software artist like myself (music, digital art, video), a variety of useful tools (audio drivers) come in neat little per-compiled packages.

Is there a way to get Microsoft or Audio Card manufactures to provide check-sums? Obviously Microsoft authentication doesn't solve all issues when it comes to espionage.

Offline Jeremy Collake

  • Administrator
  • Member#
  • *****
  • Posts: 5410
  • Gender: Male
  • The Lasso
    • Bitsum
Re: Explaining DLL Injection to the layman
« Reply #2 on: October 22, 2012, 05:27:38 PM »
I often ramble on about subjects that I feel people might benefit from knowing about.

If you're fooling with DLLs, don't forget Process Lasso does have DLL and Thread view in its View menu, though they are not maintained much, and I even dropped the old Handles tab. These functions are for full task managers, not automation software. Once you determine the cause, then the automation software can perhaps then help.

You are right that digitally signed modules are not the end solution to all problems, BUT you can adjust the local security policy so that modules must be digitally signed. Of course, this is very dangerous, and who knows if the digital signature is from a trusted vendor. It does, however, allow you to explicitly allow certain vendors and explicitly disallow others. It would require more work to implement on a system, but would be the most effective method at preventing corporate or government espionage via a mechanism relying on DLL injection. In fact, it would work for many other security cases as well.

For more information see the Local Security Policy I've taken a nifty screenshot of (disabled in my case), and then see this article for how to use it: Local Security Policy - System Settings - Use Certificate Rules on Windows Executables for Software Restriction Policies
Software Engineer. Bitsum LLC.

Offline Jeremy Collake

  • Administrator
  • Member#
  • *****
  • Posts: 5410
  • Gender: Male
  • The Lasso
    • Bitsum
Re: Explaining DLL Injection to the layman
« Reply #3 on: October 22, 2012, 05:32:55 PM »
Oh, but off of espionage, and back to your question --- some vendors provide secure digests (hashes/checksums/...), others don't. You can ask, or compare to files you extract from their installers. Yes, WinRAR and other software will often be able to 'open up' common types of installers these days.

However, their digital signature should suffice to verify that the software is from them - so long as you rely on the signature itself and are careful that it doesn't say "Mirosoft" or something.
Software Engineer. Bitsum LLC.

Offline Wind_it_up

  • New
  • *
  • Posts: 4
Re: Explaining DLL Injection to the layman
« Reply #4 on: October 23, 2012, 08:11:38 AM »
Microsoft Authentication is the issue. How can authenticated code get into production systems without any checks and bounds? I want to treat all resident libraries the same, and wish Microsoft would release checksums for Realtek audio drivers. Everyone knows the Mirosoft XPlee edition an obvious fraud. However, when Realtek Microsoft Authenticated code was released, it was directly installed into production systems, and I use another sound card provider. How can I be sure Realtek didn't just flame my new sound card provider.

It is a dual standard. On one hand, all Mirosoft code is rejected and all Microsoft authenticated virus are accepted. The checksums should match regardless and I would turn off the automatic updates.

Offline Jeremy Collake

  • Administrator
  • Member#
  • *****
  • Posts: 5410
  • Gender: Male
  • The Lasso
    • Bitsum
Re: Explaining DLL Injection to the layman
« Reply #5 on: October 23, 2012, 09:23:20 AM »
Ah, yes, I was off topic. You speak of driver signing for WHQL and I'm talking more about standard application signing. The difference is that one is mandatory for x64 systems, the WHQL signing. It is supposed to be a badge that certifies the driver as compliant and tested. Which would you want? I would take the one Microsoft certified over anything the vendor releases more recently, unless they note some bug or reason to not use the driver Microsoft has certified.

As for how to get around it, you'd have to turn off the mandatory driver signing, then install the new driver... dunno if you'd have more problems after hiding the driver update. I haven't tried this procedure.

EDIT: Of course, I'm still not really sure we are even talking about the same thing ;p. I am half into the conversation, working on some code.
Software Engineer. Bitsum LLC.

Offline Jeremy Collake

  • Administrator
  • Member#
  • *****
  • Posts: 5410
  • Gender: Male
  • The Lasso
    • Bitsum
Re: Explaining DLL Injection to the layman
« Reply #6 on: October 23, 2012, 09:27:13 AM »
(post edited)
Software Engineer. Bitsum LLC.

Offline BenYeeHua

  • Member#
  • *****
  • Posts: 2232
  • Gender: Male
Re: Explaining DLL Injection to the layman
« Reply #7 on: October 23, 2012, 01:04:01 PM »
If I am reading it right, I think he is saying that,

How can be the normal driver can be inject by other drivers dll that signed?
Did the Microsoft did not check the checksums of the drivers before running it?

Offline Wind_it_up

  • New
  • *
  • Posts: 4
Re: Explaining DLL Injection to the layman
« Reply #8 on: October 23, 2012, 03:25:15 PM »
Yes WHQL is why I would want to use Windows over any other product. I would prefer to pay someone to deal with this issue, if Microsoft has failed to prevent forgery of digital signatures it would create unnecessary work for everyone.

People who invented:
- Linux
- Deep freeze
- Virtualization
- Process Lasso
- and many more...
 must have been faced with the same dilemma. Obviously, everyone felt it was necessary to write sections of there own OS rather than trying to tackle the real issue... Validity of static code and verification of process data.

Offline Wind_it_up

  • New
  • *
  • Posts: 4
Re: Explaining DLL Injection to the layman
« Reply #9 on: October 23, 2012, 03:48:02 PM »
The way I see it, the worse thing to happen for Capitalism is DARPA (socialism) if they continue to want to bomb the internet I hope that they are prepared for legal battles. Insurance companies can't stress the importance enough about heavy equipment using Windows.

Offline Jeremy Collake

  • Administrator
  • Member#
  • *****
  • Posts: 5410
  • Gender: Male
  • The Lasso
    • Bitsum
Re: Explaining DLL Injection to the layman
« Reply #10 on: October 23, 2012, 05:11:47 PM »
You are getting into much larger issues, things I could shed light on. Things aren't so 'easy' for everyone else. The OS vendor things are easiest on is Apple - and you know why - they have total control of all their hardware and drivers (or the vast majority of it).

Forgery of digital signatures is a problem. In state sponsored malware recently (US+Israel), a stolen Microsoft certificate was used to push out a Windows update that installed the state sponsored malware (target: Iran). Read up on Flame (aka Flamer). Highly sophisticated. Of course, I'm sure this certificate was not stolen, it was more likely given to the CIA, but that is a total guess. They are trying to make nuclear bombs in Iran, after all.

Forgery of application digital signatures is usually dealt with by the security softwares and/or blacklisting the certificate. They track the history of digital certificates. This is good and bad. Recently I switched to Symantec/Verisign from Comodo. Problem is that I could only buy a 1 year cert at this special price they offered at that time. This means that in another year all my good time history will be wiped out, as it was for the 2 year cert I had before. Of course, the false positive rate is still through the roof for some products, but Microsoft consistently has the lowest false positive rate of anyone. They don't call something malicious unless it really is, none of this "reputation_problem.1" because the security software hasn't seen that version of that software before, despite it being digitally signed. Sorry, on a tangent, for more see False Positive Report.

DARPA, a wing of our mighty military industrial complex, is indeed one of the ways the government pumps money into the dosmetic economy. Every senator and congressman wants tanks built into their district, etc... or bombs.. or fighter planes.. or aircraft carriers.. whatever. That's why military spending is out of control. There have been recent cases where the DoD didn't even want things, but congress forced it down their throats. So, blame congress on that.

DARPA is of course itself the defense department advanced research agency, which every country has, and I wouldn't personally call that socialism. Our economy is a mixed one though, with socialist and capitalist policies in place since the Great Depression and the New Deal. Social Security, Medicare/medicaid, those are socialist programs. DARPA, well, you gotta stretch your imagination on that example as most of the money spent ends up in the pocket of CEO's of companies that routinely over-bill the DoD. I've actually seen it. When I was 17-20 (approx), I worked on security stuff for a defense contractor. They BS the government, take their money, and give them shit.
« Last Edit: October 23, 2012, 05:18:00 PM by jeremy.collake »
Software Engineer. Bitsum LLC.