|
Hi,
I am creating a file using CreateFile().
My machine is having symantec anti virus, when I done with CreateFile and closes the file handle I gets warning box from symantec
"Scan type: Auto-Protect Scan
Event: Security Risk Found!
Security risk detected: Bloodhound.Exploit.274
...................................
..................................."
How can I avoid that?
code is :
HANDLE hFile = CreateFile(szFilePath,GENERIC_READ|GENERIC_WRITE,NULL,NULL,CREATE_ALWAYS,NULL,NULL);
|
|
|
|
|
You can change your anti-virus settings to ignore a particular path or file, and possibly digitally sign your file. However, I am very surprised that CreateFile causes a problem. I think I've used Symantec with CreateFile before without any issues and without needing to specify that it should not scan the exe.
|
|
|
|
|
Is there anything special about the file's name or its contents?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
See this[^]. You might send one of your files to Symantec as a sample of missidentified file.
|
|
|
|
|
The content that you write in the file probably match the signature of the virus.
|
|
|
|
|
Symantec is not new in making "strange things".
Look at this[^]
It seems even an empty WinMain is a virus!
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I think that this isn't a major problem.
As per their docs, they identify something as a bloodhound exploit 274 if there's a piece of potentially malicious code that attempts to exploit the integer overflow vulnerability in GDI+. Symantec themself say that even an innocent program could be identified as malicious due to the "sensitive" nature of the detection technology used for identifying this particular malware (in cases where your program somehow share the behavioural characteristics of the code that exploits the said vulnerability).
Apply the patches if that's not already done, and if the problem persists, send your program to Symantec as what's being wrongly detected as malware.
Bloodhound Exploit 274[^]
Microsoft security bulletin article on the topic.[^]
And with all seriousness, I do hope that you're not writing code that exploits the vulnerability.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Rajesh R Subramanian wrote: As per their docs, they identify something as a bloodhound exploit 274 if there's a piece of potentially malicious code that attempts to exploit the integer overflow vulnerability in GDI+.
Humm ... What does it have to do with "CreateFile"?
Rajesh R Subramanian wrote: Symantec themself say that even an innocent program could be identified as malicious due to the "sensitive" nature of the detection technology used for identifying this particular malware
Buzzshit and Bullwords. They have a bug and are trying to sell it as a feature. Not a good behavior for a commercial company.
Rajesh R Subramanian wrote: Apply the patches if that's not already done, and if the problem persists, send your program to Symantec as what's being wrongly detected as malware.
int WinMain(HINSTANCE, HINSTANCE, char*, int)
{ return 0; }
We're still wating aswer s from them!
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Emilio Garavaglia wrote: Humm ... What does it have to do with "CreateFile"?
If he's writing binary data into a file, and if the buffer pattern matches with what they think could be malicious, then they'd want to stop it.
Emilio Garavaglia wrote: Buzzshit and Bullwords. They have a bug and are trying to sell it as a feature. Not a good behavior for a commercial company.
Yeah, I kinda agree. I thought what the hell could be sensitive (you see, I marked that in double quotes in my previous response).
Emilio Garavaglia wrote: We're still wating aswer s from them!
You didn't receive a response from them doesn't mean the OP shouldn't submit his case.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
|
|
|
|
|
Hi!
What's the size of an empty class? When I execute the following code:
#include "iostream"
using namespace std;
class test
{
};
void main()
{
test test1;
std::cout<<sizeof(test1)<<endl;
}
it prints 1. How it prints 1 with out any variable being declared?
|
|
|
|
|
|
OR i can say in otherwords like opertor sizeof never returns ZERO
If u can Dream... U can do it
|
|
|
|
|
C++ needs to be able to create pointers to arbitrary objects for inheritance.
You could create a class OBJECT that is a base class that you derive from.
|
|
|
|
|
The answer to your question is in the link provided by markkuk.
You can actually store a one byte character in an empty class.
class test
{
};
void main()
{
test test1;
*((char*)&test1) = 'A';
}
|
|
|
|
|
Dangerous!
The standard says tat distinct objects must have distinct identity (and if the identity is the address, a common way to get that is posing sizeof(A) = 1 by definition).
But this is ... compiler dependent. (they can even use 4 bytes to preserve the alignment!)
An Empty B inheriting the empty A may still have sizeof(B) == 1, not 2.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Why is it dangerous (maybe I didn't get you)?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Because what Santosh is trying to do is assign a char to a byte that it is not granted to really exist.
(it may or not depending on the compiler implementation and level of optimization)
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I'm almost sure you're right (I cannot see other ways to implement it, but this is a problem of mine).
Thank you.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Dear,
empty class does not have any size.
but size of operator always return +ve value.
so you get empty class size 1.
|
|
|
|
|
Hi there!
I need an array of strings of char * type and I am not clear about how to free up memory after use. The code below does not work.
char * ptr_p_c[3];
ptr_p_c[0] = new char;
strcpy (ptr_p_c[0], "hi there");
ptr_p_c[1] = new char;
strcpy (ptr_p_c[1], "whatever");
delete ptr_p_c;
I know I shouldn't be using this type for strings and all this. Believe me, I've tried repeatedly to convince my customer this is not the right way to do things, but unfortunately it is not my decission...
Thanks a lot.
|
|
|
|
|
First up, the "customer" has no business wrt such low level programming details. I smell something else here.
Anyway, to the point, the allocation itself is flawed. You are allocating just one character and copying several characters into it. A lot of corrupted memory. The delete will cry.
The proper way to delete is to loop through the array and delete every allocated sub array.
|
|
|
|
|
Something like this??
const int num = 3;
char * ptr_p_c[num];
for (int i = 0; i<num; i++)
ptr_p_c[i] = new char[20];
strcpy_s (ptr_p_c[0], 9, "hi there");
strcpy_s (ptr_p_c[1], 7, "change");
for (int i = 0; i<num; i++)
delete ptr_p_c[i];
|
|
|
|
|
better
const int N = ??
const char* names[N] = {"...", "...", ...}
char *arr[N];
for(n=0;n<N;n++)
arr[n] = strdup(names[n]);
for(n=0;n<N;n++)
free(arr[n]);
|
|
|
|
|
Well, you already know that avoiding std::string is just plain silly so I don't bother you more:
char * ptr_p_c[2];
ptr_p_c[0] = new char[sizeof("hi there")];
strcpy (ptr_p_c[0], "hi there");
ptr_p_c[1] = new char[sizeof("whatever")];
strcpy (ptr_p_c[1], "whatever");
delete ptr_p_c[0];
delete ptr_p_c[1];
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Agreed. Use std::string or you can use one of many already existing string classes. You also could create an array of char[] if you have a series of strings whose length the compiler can computebv in advance.
|
|
|
|