you can use procmon in order to find out which dll gets loaded, from where and when.
Run procmon, define a filter for npp and then start npp.
It needs a bit of training but if you are really interested in finding out what does what
check out the sysinternals tools as well as everything Mark Russinovich has posted/blogged.

Once you are at the level to understand how process, threads, libraries, drivers … work together
download hxd and start investigating memory.

Other useful tools can be found at nirsoft.

Cheers
Claudia

Is it possible to know if my scilexer.dll has been hijacked?

It depends on the hijack. The CIA, related organizations, and black-hat hackers, is adding spyware to computers and devices used by their targets. Among the things they do conceal that spyware is running is that are making changes to DLLs and/or intercepting calls to DLLs. Someone inspecting their process list will see nothing unusual. If they use Notepad++ they would see notepad++.exe running. If they close Notepad++ that process goes away.

If the only change they made to the target’s computer is to replace DLLs with versions that include spyware then, yes, it’s possible to know if scilexer.dll has been hijacked. However, in order to replace scilexer.dll the attacker needed full administrative mode rights. If that’s the case they likely also installed a root kit and much more. If the target inspects scilexer.dll the bits and bytes they see will be exactly the same as the copy of scilexer.dll that comes with Notepad++ or similar products. The only way for a target to see if they have been hacked is to take the machine or device to a forensic lab and to have them tear it apart down to nearly the molecule level. Even with that they may miss the clues. See Stuxnet for an example of how attackers such as the CIA operate. The good news for the CIA is if the target hears about v7.3.3, installs it, that it’s going to pass the test. The target thinks they are safe (until they read this post) and the CIA continues to monitor the target. Once the CIA spots this post they may make arrangements so that the target sees something that leads them to believe they are safe. :-)

I’m not terribly sure if this directly applies, but I found this post on StackOverflow on how to avoid DLL injection in Windows processes/applications:

http://stackoverflow.com/questions/869320/how-do-i-prevent-dll-injection

Honestly, I hadn’t heard of DLL injection prior to the Vault7 release, so the my comprehension of the matter is limited. I have to say that if I understand it correctly though, the concept is fascinating.

1>SciLexer.lib(PlatWin.obj) : error LNK2005: “public: virtual __cdecl Window::~Window(void)” (??1Window@@UEAA@XZ) ist bereits in fileBrowser.obj definiert.
1>SciLexer.lib(UniConversion.obj) : error LNK2005: “unsigned int __cdecl UTF8Length(wchar_t const *,unsigned int)” (?UTF8Length@@YAIPEB_WI@Z) ist bereits in UniConversion.obj definiert.
1>SciLexer.lib(Style.obj) : error LNK2005: “public: __cdecl Style::Style(void)” (??0Style@@QEAA@XZ) ist bereits in Notepad_plus.obj definiert.
1>SciLexer.lib(Style.obj) : error LNK2005: “public: __cdecl Style::~Style(void)” (??1Style@@QEAA@XZ) ist bereits in FindReplaceDlg.obj definiert.

See http://www.scintilla.org/ScintillaDoc.html#BuildingScintilla for builds with STATIC_BUILD.

I still don’t understand what makes this unique to Notepad++/SciTE/Scintilla. You could do the same thing to any dll file.

I think there is no sens in checking certificates or staff like that because project is open source and everybody could create their own version of npp.

Not if the private key is kept private ;-) (so it is open source with parts being not open)
NO ;-) I don’t want to start a new discussion whether this makes sense. :-)

If someone is paranoid then could simply check md5 hash of original files(dlls and so on)

Nope, md5 is considered insecure.

But all in all you are correct and Don, dail etc… do also agree once users’ PC are compromised …

Cheers
Claudia

Yes, well, in this case you’d have to check the MD5 on the SciLexer.dll that will be loaded, which is perhaps a different one than the one that you think will get loaded. :)

P.S. If someone is paranoid then could simply check md5 hash of original files(dlls and so on) :D

Ah, okay Claudia, I think you understood my question and I understand your response. Thank you. Over my long period of observation, Windows seems inherently unsecure, probably because it is backing its way into security rather than having it be a major part of the design criterion. Sad.

Cheers
Claudia

This headline is misleading. The DLL exists for CIA assets to use the cover app while it’s executing other code under the hood. From my reading, it’s not meant to be used against the person using notepad++, it’s to let them use notepad++ without raising any red flags while the DLL does data collection in the background. Those apps listed are the cover apps that look normal, the DLL hijack is to make them malicious with the knowledge of the operator.

ref: https://www.reddit.com/r/sysadmin/comments/5y0iqa/notepad_users_cia_has_had_a_dll_hijack_for_your/

@dail @Claudia-Frank
I agree that once users’ PC are compromised, the certificate checking is meaningless.
However, it makes harder (more job) to hack by checking certificate.
Just like knowing the lock is useless for people who are willing to go into my house, I still shut the door and lock it every morning when I leave home.

We are in a f**king corrupted world! Sigh

The safest solution would just be link the SciLexer statically instead of loading it dynamically but I’m not saying this is the right solution

Yes, you’re right. it’ll be in the roadmap. In the meantime, I will do the quick fix - checking the scilexer.dll before loading it.

just one function call which needs to be passed through to get the same privilege as the main process?

That would assume you bypassed the Windows OS and got into the process space of Notepad++, which by then you have other issues ;)

Maybe a blog worth reading…

Will look at it tomorrow when I have a bit more time.

The safest solution would just be link the SciLexer statically instead of loading it dynamically but I’m not saying this is the right solution

Cheers
Claudia

You are right - loading a dll is a security issue and there is no safe way if MS doesn’t provide a way to run a program
in an encapsulated and signed environment. Something like CI+ or the HDMI content protection. But for this special issue,
I don’t see how it could be solved otherwise.

Maybe a blog worth reading
https://blogs.technet.microsoft.com/srd/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability/

and there is one other issue which might be interesting. If the dll gets verified before load, this breaks npp for all
that use a different scintilla dll at the moment. I’m thinking about @cmeriaux for example.

Cheers
Claudia

can’t npp exe call a function to check scintillas signature again?

Yes it can. But if an attacker has access to SciLexer.DLL why wouldn’t they just attack notepad++.exe. There is never a case where notepad++.exe is from a privileged location and loads SciLexer.DLL from a non-privileged location.

I think we need to take a step back because this discussion doesn’t sound like it is specific to Notepad++ and Scintilla. There are programs every day that have to load DLLs and have to make sure they are valid.

don’t get this - if the file is signed, can’t npp exe call a function to check scintillas signature again?
I mean, when a dll get’s signed it provides an unique stamp so before loading the library couldn’t
you check this stamp?

Cheers
Claudia

but at that point, it isn’t in the responsibility of Don anymore, is it?

Being signed ensures the right files get installed on the system. After that it is impossible for an exe to validate other files if it can’t validate itself first.