|
The principle of Dll injection is that you get the 3rd party app to load your dll into itself which gives you an opportunity to run some code, override window classes, install some hooks or whatever into an exisiting application. I'm no expert on this but there are articles on CP about it.
In this case your injected Dll would need to establish the command line of the executable that had loaded it, this info is accessible as part of the PROCESS_INFO structure which it should be able to retrieve. If this is an app you want to block then it would Set a named shared Kernel Event that your other process is already waiting on. It might also need some way of communicating the Process ID of the 'bad' process to the monitor, or you could kep the ToolHelp sapshot based scan and just trigger it on the event, or just get the Dll to kill the process itself, 
This may indeed be able to shut down the disallowed process before the user sees anything but it really is no substitute to preventing them launching it in the first place using the Windows user account permissions system.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Have you tried looking for the WM_CREATE message via SetWindowsHookEx(WH_CALLWNDPROC, ...)?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Using a global hook similar to the one above is what I used great success
Cheers
Tom
Philosophy: The art of never getting beyond the concept of life.
Religion: Morality taking credit for the work of luck.
"The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane."
- Marcus Aurelius
|
|
|
|
|
I try a hook function CallWndProc to catch the WM_CREATE event.
The problem is that a lot of windows are created when a program is launched.
It is not easy to determine the first one. Moreover, the first one is not always the main window of the launched application.
Also the name of the executable is not returned by the Hook function.
Maybe is there another message ? I dind't see it !!
|
|
|
|
|
|
What is this supposed to mean :
bool CMyClass::MyFuntion( LPCTSTR pStr, const XStr *&pSourceStr )
Is this legal ? What is the idea behind ?
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
Yes, it is valid if it is given in Correct manour
&pSourceStr -> it gives address of the pSourceStr
And
*&pSourceStr -> it gives Data on that address.
|
|
|
|
|
Yes it is legal, this is how it breaks down, assuming the function was static just for example's sake
LPCTSTR pStr = _T("SomeString");
const XStr Source = _T("SomeSuperString");
const XStr* pSourceStr = &Source;
bool bResult = CMyClass::MyFunction( pStr, pSourceStr );
//pSourceStr may have been modified by the call but Source will still be the same
The function takes a pointer-by-reference, that is a reference to a pointer, as its second parameter. What this means to the caller is that when the function returns pSourceStr might have changed, it might point somewhere else now, but Source will not have.
This is usually done to get, in effect, a second return value from the function. The function will modify pSourceStr in order to communicate it back to the caller along with the bool result.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Cristal clear, thanks Matthew !
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
Rage wrote: What is the idea behind ?
Without knowing all the relevant analysis information it is not possible to say with any certainty, but it very likely means a design flaw.
|
|
|
|
|
Hi All,
I like to learn Debugging tools.
Can any one send some links which r useful for me
Thx a lot..
|
|
|
|
|
MSDN is one option
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
sheshidar wrote: I like to learn Debugging tools.
Can any one send some links which r useful for me
which debugging tool you want to learn, friend. there are many, but best one is Visual Studio itself. just put breakpoint in source code and debugged the application.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
And compile with which key?(F10 or F11)
|
|
|
|
|
Hamid. wrote: And compile with which key?(F10 or F11)
and you forget F5
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Oh yes 
|
|
|
|
|
Hello everyone,
Suppose I have two enums which has an item with the same names -- but different values,
<br />
enum foo {<br />
<br />
NAME = 100;<br />
}<br />
<br />
enum goo {<br />
<br />
NAME = 200;<br />
}<br />
Are there any ways to specify whether I need to access NAME in foo or NAME in goo?
thanks in advance,
George
|
|
|
|
|
There is not! It appears to me to be a scheme designed to confuse both the Compiler and the developer.My advice: Don't!
LateNightsInNewry
|
|
|
|
|
Hi LateNightsInNewry,
Could you show me how to solve this issue in your ideas by simple sample please?
regards,
George
|
|
|
|
|
The Problem is, you have two enum values by the same name. If the compiler is instructed correctly it should throw an error! You managed to compile it regardless!
That did not mean that it was the right thing to do to get your code to compile!
The Bottom Line is, You wrote daft code, and spent time to convince the compiler that it was wrong to issue error messages about it. You managed to convince it, so it issued a daft environment to the compiler. The way you did it is probably by having a project spread out over several folders, and having different versions of a header file in each folder!
The Simple Solution is:
1. If the enum values are meant to represent the same condition, include it's definition in an Header file visible everywere required. i.e. construct a Common Header Directory, and instruct the compiler to search that folder preferentially.
2. If the enum values represent different conditions, give them different names
3. Learn that NameSpace Collision Error Messages are your friend. It is your Indicator that things are wrong, and you catch it when it occurs! Imagine debugging an App where all variables have the same name!
4. Realise that the Names of Objects only come into play at Development Level, and that there is no reason to be coy about naming. There is absolutely No possibility of recovering te name of a correctly compiled and linked retail version of your code from the executable.
Hope this is Helpfull,
Bram van Kampen
|
|
|
|
|
Thanks for your great reply Bram!
regards,
George
|
|
|
|
|
The short answer is no because the names exist in the same scope and same namespace. You could do
<br />
class Cfoo<br />
{<br />
<br />
enum foo <br />
{<br />
NAME = 100;<br />
}<br />
};<br />
<br />
class cGoo<br />
{<br />
enum goo <br />
{<br />
NAME = 200;<br />
}<br />
};<br />
which would then allow Cfoo::NAME to be differentiated from Cgoo::NAME or
<br />
namespace nsfoo<br />
{<br />
enum foo <br />
{<br />
NAME = 100;<br />
}<br />
}<br />
<br />
enum goo <br />
{<br />
NAME = 200;<br />
}<br />
which would differentiate nsfoo::NAME from NAME. I would strongly prefer the class method because namespace resolution is relative.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew!
A great sample! Cool!
have a good weekend,
George
|
|
|
|
|
Hi,
I've been doing some work using C# and like the auto document format (Under the Edit->Advanced Menu).
But noticed that this feature doesn't exist in C/C++!! Anybody know if there is an Add-In that I can use within VS2005?
Many thanks
Gibbo
|
|
|
|
|
What does the "auto document format" do? I mean... What do you want to have?
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
