I've written a small C++ program which checks if Windows clipboard content has changed and prints a type of that content. I compiled the program to .exe file using Windows Visual Studio 2019 and it was blocked by the Windows Defender (file was removed). Why is that happened and how to prevent it?
Of course, if I open the Windows Defender and mark my file as "not a virus" then all works fine, but how to prevent blocking on customers computers? Do I need to create some "manifest" file..?
Sorry if the question is dumb, I'm new in C++ world
#include <iostream>
#include <io.h>
#include <fcntl.h>
#include <Windows.h>
#include <conio.h>
int main()
{
DWORD m_lastClipboardSequenceNumber = GetClipboardSequenceNumber();
while (1) {
Sleep(100);
const DWORD newClipboardSequenceNumber = GetClipboardSequenceNumber();
if (newClipboardSequenceNumber == m_lastClipboardSequenceNumber)
continue;
if (IsClipboardFormatAvailable(CF_UNICODETEXT)) {
std::wcout << "CF_UNICODETEXT\n";
}
if (IsClipboardFormatAvailable(CF_HDROP)) {
std::wcout << "CF_HDROP\n";
}
if (IsClipboardFormatAvailable(CF_BITMAP)) {
std::wcout << "CF_BITMAP\n";
}
m_lastClipboardSequenceNumber = newClipboardSequenceNumber;
}
return 0;
}
Sounds like your issue isn't with C++ at all and more just with Windows, more precisely, Windows Defender. The issue here, to my knowledge, is that Windows Defender started by default not allowing .exe files from unknown sources to be run on the computer without Admin privileges. This is an issue you cannot fix remotely, otherwise that would massively undermine the existing usefulness of Windows Defender, as malicious actors could just use that to run their exploits.
Steps you could take to possibly fix this for your use case: if you have access to the computers you want to run this on, try adding your distribution method to trusted sources. Alternatively, try signing it with a key and adding that signature to trusted.
I personally think since your method for watching clipboard is too abusive, windows defender is blocking your code.
Try monitoring clipboard section and register listeners for clipboard changes to see if same thing happens or not. Your code will be much more complex, since you will need to create a window loop for receiving messages, but I think it will OK that way.
Related
There are two PCs with Visual Studio 2017 installed. I'm running a simple program on both of them, one that lists the name of modules (exes/DLLs) inside its own process.
But I get wildly different results. On one PC, I only get 7 modules:
Lab7_1.exe
ntdll.dll
KERNEL32.DLL
KERNELBASE.dll
MSVCP140D.dll
VCRUNTIME140D.dll
ucrtbased.dll
On the other, I get whopping 31 modules. The full list includes, for example, user32.dll, which my sample program isn't using (it's a console app, not a GUI app).
So the question is: what exactly affects the list of DLLs imported by default? Debug/Release and x86/x64 switches produces some difference, but nothing that drastic.
Differences between platform tools versions (and corresponding versions of MS VC++ Redist) I can understand, but why are different system DLLs being imported as well?
I'm unsure where else to look.
Context: it's a part of an assignment. On of those PCs is mine, the other is where the students work. The assignment goes like this "We have this set of modules by default, now we use MessageBoxA(), and we see that more modules are imported, user32.dll among them". Which doesn't quite work if user32.dll is always imported by default.
Since the behaviour is vastly different, and I can't reproduce it on my PC, it's hard to adapt the assignment so the students can see import mechanics at work.
Sample program code:
#include <iostream>
#include <vector>
#include <string>
#include <Windows.h>
#include <Psapi.h>
using namespace std;
#pragma comment(lib, "psapi.lib") //needed for MS VS 2010
void EnumerateModules(vector<HMODULE>& modules)
{
HANDLE me = GetCurrentProcess();
DWORD needed_size = 0;
while (true)
{
DWORD actual_size = modules.size() * sizeof(HMODULE);
EnumProcessModules(
me, //which process
modules.data(), //where to put the module handlers
actual_size, //allocated buffer size
&needed_size //desired buffer size
);
if (needed_size != actual_size)
modules.resize(needed_size / sizeof(HMODULE));
else
break;
}
}
string ModuleName(HMODULE module)
{
HANDLE me = GetCurrentProcess();
string buffer(FILENAME_MAX, 0);
DWORD real_length = GetModuleBaseNameA(
me, //which process
module, //which module
&buffer[0], //where to put the name
buffer.size() //size of the name buffer
);
if (real_length > 0)
return buffer.substr(0, real_length);
buffer = "";
return buffer;
}
int main(int argc, char* argv[])
{
setlocale(0, "");
vector<HMODULE> modules;
EnumerateModules(modules);
cout << modules.size() << " modules:" << endl;
for (size_t i = 0; i < modules.size(); i++)
{
string name = ModuleName(modules[i]);
cout << name.c_str() << endl;
}
return 0;
}
The assignment goes like this "We have this set of modules by default, now we use MessageBoxA(), and we see that more modules are imported, user32.dll among them"
Win32 programs, by default, will import ALL their dependent DLLs up front before any code is executed. When you invoke MessageBox it MIGHT pull in other modules via LoadLibrary, but user32.dll is already loaded before that function is invoked.
The project setting you are wanting is delay loading which will generate the behavior you are claiming will happen. That is, the DLL won't effectively be loaded until the function is actually invoked.
Okay, turns out it's not related to Visual Studio settings. I compiled the sample code on one machine, ran in on the other, and got the same result as if I compiled the code there. So it's either Windows version (7 vs 10) or MS VS Redistributable version (though I think both projects used v140). In either case, I can't reproduce the behaviour on my machine unless I'm willing to set up a VM.
To anyone that can help Please,
(My operating system is Windows XP)
I have looked on the this forum but have not found a similair answer that I could use or adapt to suite this particular situation. I will try to explain (I apologise in advance if my question seems confusing)
I am constructing a batch file that will call a C++ program (.exe) The C++ program is hard coded to the C: drive. By the way I did not write the C++ program as I am incapable of writing in C++ but would like to exchange the C: in C++ for what would be in batch %SystemDrive%. The line of code in C++ reads as follows:
SetSfcFileException(0, L"c:\\windows\\system32\\calc.exe",-1);
// Now we can modify the system file in a complete stealth.
}
The bit of code I would like to alter in the above code is C: or "C" to change it to %systemDrive% but in C++ code language, in effect change the hard coded part of the C++ program to read a System path variable within XP.
I have also looked elsewhere on the net but have not found a suitable answer as I do Not want to break the C++ code you see.
The C++ code was obtained from the folowing website written by Abdellatif_El_Khlifi:
https://www.codeproject.com/Articles/14933/A-simple-way-to-hack-Windows-File-Protection-WFP-u
Many Thanks for any help given,
David
The search term you should be looking for is Known Folders.
Specifically, calling SHGetKnownFolderPath() with the FOLDERID_System identifier, one of the many IDs found here.
That's for Vista or better. For earlier than that (such as XP), you have to use CSIDL values, CSIDL_SYSTEM (see here for list) passed into SHGetFolderPath().
You can still use the pre-Vista ones but I think they're just thin wrappers around the newer ones.
This is the simplest console application I could come up with that shows this in action (Visual Studio 2019):
#include <iostream>
#include <shlobj_core.h>
#include <comutil.h>
int main()
{
PWSTR path = NULL;
HRESULT hr = SHGetKnownFolderPath(FOLDERID_System, 0, NULL, &path);
_bstr_t bstrPath(path);
std::string strPath((char*)bstrPath);
std::cout << "Path is '" << strPath << "'\n";
}
and the output on my system is:
Path is 'C:\WINDOWS\system32'
This is not really answering my own question, well it is but in a alternative manner, many ways to skin a cat so to speak!
Here is one encouraging bit of news though I have stumbled across the very thing I need called WFPReplacer, it is a commandline windows utility that pretty well does what I want & generally in the same manner. it disables WFP for both singular files & can be used for wholesale switching off of WFP if the right file is replaced. All I need to do is write a batch file as a front end to back up the system files I want to disable use WFPReplacer.exe. So if in the event of the proceedings the routine gets stuffed I can revert back to the backed up files. I think this program uses the same type of embedded coding but is written in Delphi/pascal, it is called Remko Weijnen's Blog (Remko's Blog) "replacing Wfp protected files".
I generally like to leave whatever I am doing on a positive note. So just in case someone else lands on this forum & is trying to accomplish a similair exercise here is the code that one can compile (This is not my code it belongs to Remko Weijnen's Blog (Remko's Blog)) Please be advised it is NOT C++ it is a commandline exe Delhi/Pascal found at this link, so all credits belong to him. The link is:
https://www.remkoweijnen.nl/blog/2012/12/05/replacing-wfp-protected-files/
DWORD __stdcall SfcFileException(RPC_BINDING_HANDLE hServer, LPCWSTR lpSrc, int Unknown)
{
RPC_BINDING_HANDLE hServerVar; // eax#2
int nts; // eax#6
__int32 dwResult; // eax#7
DWORD dwResultVar; // esi#9
int v8; // [sp+8h] [bp-8h]#1
int v9; // [sp+Ch] [bp-4h]#1
LOWORD(v8) = 0;
*(int *)((char *)&v8 + 2) = 0;
HIWORD(v9) = 0;
if ( !hServer )
{
hServerVar = _pRpcHandle;
if ( !_pRpcHandle )
{
hServerVar = SfcConnectToServer(0);
_pRpcHandle = hServerVar;
if ( !hServerVar )
return 0x6BA; // RPC_S_SERVER_UNAVAILABLE
}
hServer = hServerVar;
}
nts = SfcRedirectPath(lpSrc, (int)&v8);
if ( nts >= 0 )
dwResult = SfcCli_FileException((int)hServer, v9, Unknown).Simple;
else
dwResult = RtlNtStatusToDosError(nts);
dwResultVar = dwResult;
MemFree(v9);
return dwResultVar;
}
Also as one further warning (Unless you know what you are doing!!!) do not attempt to use this program, ALWAYS ALWAYS ALWAYS backup your system files before deletion or alteration.
What this program will do is disarm WFP for 60 seconds whilst you intercange or amend your files. Example usage for example is:
WfpReplacer.exe c:\windows\Notepad.exe (Errorlevel true or false will be produced on execution).
Best Regards
David
I am creating an application to manage other applications or exe files on a user's computer, and stop them from accessing them at certain times (like ColdTurkey's application blocking feature).
The way I am trying to do this has not been working so far - I attempted to do this by opening the file dwShareMode set to 0 using the CreateFile function. This seems to work for files such as text files and does not allow the file to be opened, however this is not the case if I try and do this same approach on exe files, and the user is free to open the file.
I assume that exe files are not 'read' in the same way by Windows as a text file is read by notepad and that that means setting the dwShareMode to 0 does not affect it being opened, however I do not know what the difference between these are. Any help would be appreciated.
Code here (for the text file):
#include <windows.h>
#include <string>
#include <iostream>
using namespace std;
int main()
{
HANDLE test;
test = CreateFile("test.txt",
GENERIC_WRITE,
0,
NULL,
CREATE_NEW,
FILE_ATTRIBUTE_NORMAL,
NULL);
cout << "press enter to stop blocking application: ";
string b;
getline(cin, b);
cout << endl;
CloseHandle(test);
return 0;
}
Your code works fine for me to block execution of the file. You do need to specify OPEN_EXISTING instead of CREATE_NEW (because you're not trying to create a new file here).
Not a windows expert -- I'm used to Unix/Linux and use the Cygwin package so I can program "in Unix" on my Windows desktop -- but it looks to me like you need to set the lpSecurityAttributes parameter, the one that comes after dwShareMode.
I think the following page might be helpful:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364399(v=vs.85).aspx
I am working on a simple program to copy all files in folders from one drive to another using C++. Using the Windows API function CopyFile(). I have used the following code:
#include <iostream>
#include <windows.h>
int main()
{
std::cout << "File Copier Version 1";
CopyFile("U:\\whateverfile.file","U:\\whateverfile2.file",0);
return 0;
}
What is the best way to handle copying an entire directory and all the files in it? Any other advice on this? Problems I may encounter?
If you wish to do it on Windows with progress display and other features, without putting too much effort into it, look up IFileOperation::CopyItem. However, it requires Vista or later.
I am currently experimenting with xdotool to send keys to a process (I understand that it may not work for all processes that does not set _NET_WM_PID). I have trouble sending keystrokes to windows other from the focus. It does work if you are sending keystrokes to the CURRENTWINDOW. Below is the snippet that I used to test xdotool's functionality.
extern "C"{
#include <xdo.h>
}
//extern "C" xdo_window_search
#include <iostream>
#include <string.h>
using namespace std;
int main(){
xdo_t* p_xdo = xdo_new(NULL);
// Allocate memory for search query.
xdo_search_t s;
// Clear the allocated memory.
memset(&s, 0, sizeof(xdo_search_t));
// Set the search query.
s.pid = 1916;
s.max_depth = -1;
s.searchmask = SEARCH_PID;
s.require = xdo_search::SEARCH_ANY;
// Allocate memory for output
Window* windows;
int no_windows;
xdo_window_search(p_xdo,&s,&windows,&no_windows);
cout << no_windows << endl;
// Prints all windows' names with matching criteria
for( int i=0;i<no_windows;i++ ){
unsigned char * name;
int size;
int type;
xdo_get_window_name(p_xdo,windows[i],&name,&size,&type);
cout << i << ":" << name << endl;
}
for( int i=0;i<no_windows;i++ ){
xdo_type(p_xdo,windows[i],"Hello World",0);
}
//xdo_type(p_xdo,CURRENTWINDOW,"Hello World",0); // This does work.
return 0;
}
In additional to testing xdotool's functionality, I've looked into xdotool's source code. Interestingly, I found that they are using Xtest to send keystrokes to the focused window (CURRENTWINDOW) and X11's XSendEvent for other windows. I turned to xdotool because I couldn't get XSendEvent to work and Xtest cannot send keys to any other windows than the focused window.
Am I not using the xdotool correctly? Does xdotool not work with all *nix OS with X11?
[I am running this on Ubuntu 13.04.]
EDIT
So, it looks like that does work but not for all windows that it finds. For example, it works for firefox but not gedit and gnome-terminal although it found gedit and gnome-terminal by its pid. It behaves differently if I used CURRENTWINDOW.
So, it would be great if someone can explain why is this so. Like, is it related the force send flag in an XEvent?
Directly from the xdotool manual:
SENDEVENT NOTES
If you are trying to send key input to a specific window, and it does
not appear to be working, then it's likely your application is ignoring
the events xdotool is generating. This is fairly common.
Sending keystrokes to a specific window uses a different API than
simply typing to the active window. If you specify 'xdotool type
--window 12345 hello' xdotool will generate key events and send them
directly to window 12345. However, X11 servers will set a special flag
on all events generated in this way (see XEvent.xany.send_event in
X11's manual). Many programs observe this flag and reject these events.
It is important to note that for key and mouse events, we only use
XSendEvent when a specific window is targeted. Otherwise, we use XTEST.
Some programs can be configured to accept events even if they are
generated by xdotool. Seek the documentation of your application for
help.
Specific application notes (from the author's testing): * Firefox 3
seems to ignore all input when it does not have focus. * xterm can be
configured while running with ctrl+leftclick, 'Allow SendEvents' *
gnome-terminal appears to accept generated input by default.