Supressing a MessageBox
-
As Ravi suggested, I'd throw the component away and find another one (or develop it myself.) If you manage to kill this message box, you don't know if there are more hidden just waiting to pop up with your best customer. As to how you could kill it, a
WH_CBTWindows hook probably would do it.eggie5 wrote:
are "dialog" (or whatever it's called)
It's modal (disables parent window) and modeless (doesn´t disable parent window) :)
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Asking them devs to fix it would be best but Luis hooking will work or you can remove the message box dialogs completly by debugging the control and noping the calls to the dialog.
In any case (hooking or patching), there will be problems when a new version is released (most likely with patching.) Making the developers fix that probably would be hard, altough he can try. If a component-developing company allows that code to be released, I would expect great customer support. Altough I might be wrong.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Asking them devs to fix it would be best but Luis hooking will work or you can remove the message box dialogs completly by debugging the control and noping the calls to the dialog.
-
In any case (hooking or patching), there will be problems when a new version is released (most likely with patching.) Making the developers fix that probably would be hard, altough he can try. If a component-developing company allows that code to be released, I would expect great customer support. Altough I might be wrong.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Can you explain this "hooking or patching" process to me? I"m not quite sure what you mean... Also, this component will never be updated again. /\ |_ E X E GG
Patching is actually changing the code in the DLL. In you case, suppose you have somthing like this in machine-type pseudocode:
call DoSomething if error code != 0 go to error call DoSomethingBecauseNoError return error: call MessageBox("error!!") returnSuppose you find that code in the DLL and actually modify the file so that the insctruction
go to erroris changed to aNOP(which is an Intel x86 assembly language instruction that actually does nothing). The next time the DLL is loaded and executed, theDoSomethingBecauseNoErrorcall will always be executed, even if there was a previous error. That's patching: modifying some already-compiled code. I can also be useful in cracking programs. Suppose you have an app that calls a funcion to check whether it's registered or not. If you patch the beginning of that function (by changing the first instruction for areturn true) it will always seem as registered (that's what some cracks actually do.) Hooks are something totally different. A hook is a way to register your code so it's called before or after some other code, and it can optionally alter the normal behavior. In this case the original code is not modified, but the operating system or the code-to-be-called must provide a way to be hooked. Windows provides several types of hooks. One of them, theWH_CBThook, lets your hook procedure be called everytime the system is about to create a window, and you can prevent it from doing so. This way, you could see every window created, and if it's the specific message box, just prevent it. You can find more information in MSDN: About Hooks[^] CBTProc[^] Your hook procedure must reside in a DLL that will be loaded -
Patching is actually changing the code in the DLL. In you case, suppose you have somthing like this in machine-type pseudocode:
call DoSomething if error code != 0 go to error call DoSomethingBecauseNoError return error: call MessageBox("error!!") returnSuppose you find that code in the DLL and actually modify the file so that the insctruction
go to erroris changed to aNOP(which is an Intel x86 assembly language instruction that actually does nothing). The next time the DLL is loaded and executed, theDoSomethingBecauseNoErrorcall will always be executed, even if there was a previous error. That's patching: modifying some already-compiled code. I can also be useful in cracking programs. Suppose you have an app that calls a funcion to check whether it's registered or not. If you patch the beginning of that function (by changing the first instruction for areturn true) it will always seem as registered (that's what some cracks actually do.) Hooks are something totally different. A hook is a way to register your code so it's called before or after some other code, and it can optionally alter the normal behavior. In this case the original code is not modified, but the operating system or the code-to-be-called must provide a way to be hooked. Windows provides several types of hooks. One of them, theWH_CBThook, lets your hook procedure be called everytime the system is about to create a window, and you can prevent it from doing so. This way, you could see every window created, and if it's the specific message box, just prevent it. You can find more information in MSDN: About Hooks[^] CBTProc[^] Your hook procedure must reside in a DLL that will be loaded -
I don't have any of the source code, all I have is the DLL. Can I still do the patch/hack? /\ |_ E X E GG
Yes, that's the idea, without the source code. But it's not easy. You need to disassemble it, find the call to message box, find where you could put a NOP (not all assembly instructions are the same length), get the hexadecimal value of the NOP (it's called the opcode)... it's really not that easy. I would definitely try to find another component, and if not, I would probably use the hook technique. Patching is the last resort.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Yes, that's the idea, without the source code. But it's not easy. You need to disassemble it, find the call to message box, find where you could put a NOP (not all assembly instructions are the same length), get the hexadecimal value of the NOP (it's called the opcode)... it's really not that easy. I would definitely try to find another component, and if not, I would probably use the hook technique. Patching is the last resort.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Can you recommend a disassembler to use? I would like to mess around with this. /\ |_ E X E GG
You'll have to search for one in google. I've not used one in years. I remember using one called WDASM32, but I don't know if it still exists. On a side note, I always wanted to write one myself (interesting project) but never did it. Now that I work for a living, I just don't have time.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
can you explain more to me what you mean by
cnich23 wrote:
debugging the control and noping the calls to the dialog.
??? Can I do this if I don't have access to the source? /\ |_ E X E GG
There is no real easy way to explain this. Either you need to know your machine ASM or if the control is .NET you need to know IL. There are several .NET Dissasmblers some even let you edit the IL code directly. Which in your case you can search for MessageBox and remove them. But there is no easyway to explain this, and most likely it will involve a lot mroe research then waht your trying to accomplish. Best bet is to have the dev's fix it or learn .NET reversing.