please consider the microsoft "AVI mux" directshow filter, it have CLSID: {E2510970-F137-11CE-8B67-00AA00A3F1A6}
suppose that, just for an experiment, I want to change this code. I opened the file qcap.dll with WinHex qcap.dll but I can not find this string inside it, then I wonder where is written, if it's written in qcap.dll. Thanks
It is there but it is not a string, it is hardcoded as a binary value. Then you are to consider registration of the DLL, which stands alone from file contents. Whatever you are trying to achieve patching a stock DLL, it is wrong and a no-go for a real task. Not to mention that the file is proceted by System Restore and reversing is likely to be an EULA violation.
Related
Are there any rules for file extensions? For example, I wrote some code which reads and writes a byte pattern that is only understood by that specific programm. I'm assuming my anti virus programm won't be too happy if I give it the name "pleasetrustme.exe"... Is it gerally allowed to use those extensions? And what about the lesser known ones, like ".arw"?
You can use any file extension you want (or none at all). Using standard extensions that reflect the actual type of the file just makes things more convenient. On Windows, file extensions control stuff like how the files are displayed in Windows Explorer and what happens when you double click on it.
I wrote some code which reads and writes a byte pattern that is only
understood by that specific programm.
A file extension is only an indication of what type of data will be inside, never a guarantee that certain data formatted in a specific way will be inside the file.
For your own specific data structure it is of course always best to choose an extension that is not already in use for other file formats (or use a general extension like .dat or .bin maybe). This also has the advantage of being able to use an own icon without it being overwritten by other software using the same extension - or the other way around.
But maybe even more important when creating a custom (binary?) file format, is to provide a magic number as the first bytes of that file, maybe followed by a file header structure containing a version number etc. That way your own software can first check the header data to make sure it's the right type and version (for example: anyone could rename any file type to your extension, so your program needs to have a way to do some checks inside the file before reading the remaining data).
Is the ReplaceFile Windows API a convenience function only, or does it achieve anything beyond what could be coded using multiple calls to MoveFileEx?
I'm currently in the situation where I need to
write a temporary file and then
rename this temporary file to the original filename, possibly replacing the original file.
I thought about using MoveFileEx with MOVEFILE_REPLACE_EXISTING (since I don't need a backup or anything) but there is also the ReplaceFile API and since it is mentioned under Alternatives to TxF.
This got me thinking: Does ReplaceFile actually do anything special, or is it just a convenience wrapper for MoveFile(Ex)?
I think the key to this can be found in this line from the documentation (my emphasis):
The replacement file assumes the name of the replaced file and its identity.
When you use MoveFileEx, the replacement file has a different identity. Its creation date is not preserved, the creator is not preserved, any ACLs are not preserved and so on. Using ReplaceFile allows you to make it look as though you opened the file, and modified its contents.
The documentation says it like this:
Another advantage is that ReplaceFile not only copies the new file data, but also preserves the following attributes of the original file:
Creation time
Short file name
Object identifier
DACLs
Security resource attributes
Encryption
Compression
Named streams not already in the replacement file
For example, if the replacement file is encrypted, but the
replaced file is not encrypted, the resulting file is not
encrypted.
Any app that wants to update a file by writing to a temp and doing the rename/rename/delete dance (handling all the various failure scenarios correctly), would have to change each time a new non-data attribute was added to the system. Rather than forcing all apps to change, they put in an API that is supposed to do this for you.
So you could "just do it yourself", but why? Do you correctly cover all the failure scenarios? Yes, MS may have a bug, but why try to invent the wheel?
NB, I have a number of issues with the programming model (better to do a "CreateUsingTemplate") but it's better than nothing.
Somebody gave me a testing program to write records into the windows event log (but I don't have the sources). I understand the general way of writing and reviewing event log, but that program behaves very special in a way that I can write records, that have a source which does not exist.
There is not even a registry entry in .../eventlog/application, hence no formatting libs.
If I try that from my own code, I can write such a record but the Windows Event Viewer then always tells me something about "description cannot be found" (which is correct and I understand why that happens).
The question is now: Since that foreign test prog CAN do it, it must be possible somehow - but HOW?
Many thx!! :-)
OK, finally I found it (also, got the sources) - the prog creates the registry entry (probably happens when calling CreateEventSource()), it was just not visible until refreshing regedit :-|
And, it DOES register a formatting lib, only that it is something I cannot rely on: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll
Or, can I?
Ah, here we go for an explanation:
Difference between EventLog.WriteEntry and EventLog.WriteEvent methods
So, I cannot, as I'm not using .Net ... :-|
Now, if I NOW send another event from MY prog (with the same, newly created source, as the foreign prog), I see it in the event viewer normally.
That means, WriteEntry() actually does not write a different/special type of evt log record containing the text directly (contrary to the standard method of writing just a msg catalog ID + params) but rather there must be some trick in the formatting lib to make the EventViewer apply some kind of "default" formatting.
Any ideas how I could accomplish this? Except just copying the EventLogMessages.dll above? :-)
OK, finally found an answer about this one in http://msdn.microsoft.com/en-us/magazine/cc163446.aspx
"This file is called EventLogMessages.dll, and it contains 65,536 event descriptions, each of which consists of the string "%1", a placeholder for whatever string you want to write"
I was hoping for something like "messageid=*" but that seems to be too simple :-|
But maybe somebody else is interested in whats happening here ...
I am working on reverse engineering and i wanted to give my own file path without using open dialog box like writing a fixed file path and read a file from that every time the software start.i tried to give the file name in a .data section of the software but it retrieve only the hex number not the string.
Is there any way hooking windows API for file open?or any way to write in memory and to read it every time the software starts?Any advice or direction would be greatly appreciated.
I think that what you may be looking for is "intercepting system call", quick google search came up with this link:
http://jbremer.org/intercepting-system-calls-on-x86_64-windows/ so it should be possible and not too difficult.
Basically if you manage to intercept a call to GetOpenFileName and replace it with custom implementation you should be able to do what you want (that is put hardcoded file path to appropriate buffer in LPOPENFILENAME structure)
As for your attempt to modify compiled code (I assume that what you are referring as reverse engineering is disassembling and modifying binaries) it should be possible to do, but it will require deep knowledge of windows binary architecture and assembly language.
I have to build a GUI application on Windows Mobile, and would like it to be able user to choose the language she wants, or application to choose the language automatically. I consider using multiple dlls containing just required resources.
1) What is the preferred (default?) way to get the application choose the proper resource language automatically, without user intervention? Any samples?
2) What are my options to allow user / application control what language should it display?
3) If possible, how do I create a dll that would contain multiple language resources and then dynamically choose the language?
For #1, you can use the GetSystemDefaultLangID function to get the language identifier for the machine.
For #2, you could list languages you support and when the user selects one, write the selection into a text file or registry (is there a registry on Windows Mobile?). On startup, use the function in #1 only if there is no selection in the file or registry.
For #3, the way we do it is to have one resource DLL per language, each of which contains the same resource IDs. Once you figure out the language, load the DLL for that language and the rest just works.
Re 1: The previous GetSystemDefuaultLangID suggestion is a good one.
Re 2: You can ask as a first step in your installation. Or you can package different installers for each language.
Re 3:
In theory the DLL method mentioned above sounds great, however in practice it didn't work very well at all for me personally.
A better method is to surround all of the strings in your program with either: Localize or NoLocalize.
MessageBox(Localize("Hello"), Localize("Title"), MB_OK);
RegOpenKey(NoLocalize("\\SOFTWARE\\RegKey"), ...);
Localize is just a function that converts your english text to a the selected language. NoLocalize does nothing.
You want to surround your strings with these values though because you can build a couple of useful scripts in your scripting language of choice.
1) A script that searches for all the Localize(" prefixes and outputs a .ini file with english=otherlangauge name value pairs. If the output .ini file already contains a mapping you don't add it again. You never re-create the ini file completely, your script just adds the missing ones each time you run your script.
2) A script that searches all the strings and makes sure they are surrounded by either Localize(" or NoLocalize(". If not it tells you which strings you still need to localize.
The reason #2 is important is because you need to make sure all of your strings are actually consciously marked as needing localization or not. Otherwise it is absolutely impossible to make sure you have proper localization.
The reason for #1 instead of loading from a DLL is because it takes no work to maintain this solution and you can add new strings that need to be translated on the fly.
You ship the ini files that are output with your program. You also give these ini files to your translators so they can convert the english=otherlanguage pairs. When they send it back to you, you simply replace your checked in .ini file with the one given by your translator. Running your script as mentioned in #1 will re-add any missing translations if any were done while the translator was translating.