On win32, using winapi, is there anyway to know which comports (from com0 upwards) actually exist as devices?
At the moment I am just attemping to open them all (0 to 9), but I can't figure out the difference of failure between one not existing, and one not simply being available for use because someone else is using it. Both situations seem to return the same last error, so I was wondering if I could list all the comports available on the system.
I believe you can call QueryDosDevice() and pass null for the first parameter and then parse the results.
Search google for "enumerate com ports". This is an example link.
The name is unfortunate, but "SetupAPI" is the relevant part of the Windows API. Call SetupDiCreateDeviceInfoList once for device interface class GUID_DEVINTERFACE_COMPORT. Then call SetupDiEnumDeviceInfo repeatedly, starting at index 0 until GetLastError()==ERROR_NO_MORE_ITEMS.
Related
I am a beginner to kernel module programming. And using resources online (especially this tutorial) I have managed to write most of my driver.
The driver basically is a character device which maps different areas of SRAM into separate files. You can see the actual code here.
Right now I am able to successfully create 4 files under /dev and reading/writing the first file works too but the other 3 files do not work. I am using minor number to distinguish between the files and assign the starting address accordingly.
Questions:
Why are the other files not working?
Is there a better way to implement the module?
Thanks.
Line 141,
"if (cdev_add(&c_dev, first, 1) == -1)",
only applies the file_operations struct to the first device.
You should use MAXDEVICES instead of 1 here
On another note, the init code is messy (better use goto and not duplicate the cleanup for every function that can fail) and in some cases plain wrong (device_destroy() before any devices were created, resource leak in case you fail the create a device that isn't the first).
The entire file does not stand up to kernel coding conventions.
I am playing around with the demo of IDA and I am trying to do some reverse engineering of a program to figure out the structure of one of its files that it uses. My final goal is to be able to read that file directly from my own program.
Using Process Monitor I was able to find the subroutine that calls kernel32_ReadFile. What I would like to know is how do I find out what the hFile variable is pointing to before it makes the call to ReadFile
I have been exploring around the menus while in debug mode and I have not found anywhere inside IDA where I can look up information about what file is associated with a file handle.
How do I map a handle to a real file?
This MSDN page describes ways to get the file name from a file handle:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366789(v=vs.85).aspx
Is that the information you were looking for? I'm not sure why you can't see the the file name directly in Process Monitor.
I would set a breakpoint on CreateFileA and CreateFileW and see what files are being opened. You can then match the returned HANDLE value to the subsequent ReadFile call.
Let's take for example notepad. How can I in my application be 100% sure whether notepad is running or not?
By 100% I mean, if there is another process whose name is "notepad.exe" which in fact is not a real notepad but for example an imitation, I don't want to detect it. Only real notepads.
I've already thought about reading the process memory but it's more difficult than it appears to be, because of memory displacements etc.
The standard way is by name, right? But for me it is really important, that it is not any other program since I want to interact with it what would critical fail if I found a wrong process.
Does anyone know a good way of doing this?
PS: There is no specific programming language to do it in. If possible I would prefer an indipendent solution. But if required, I specifically use .Net/C#.
The only way to be 99.9%1 sure you're looking at the right executable is to validate the file's digital signature. For example, you'd ensure that the notepad.exe in question was signed by "Microsoft Corporation".
I'd do something like this:
Get the list of running processes.
Filter down to name of interest (notepad.exe)
Get each process' image [executable] path.
Validate that the Authenticode signature is valid and trusted.
Compare the name of the signer to the expected value.
Success! You can be very certain this is the correct file.
This method avoids issues like having to know ahead of time where the file should be located (which is nearly impossible – Notepad is installed in two locations), what its hash value should be (obviously bound to change), or strange user behavior (replacing Notepad with some other text editor).
1 - of course, it's impossible to be 100% sure. Someone really determined could self-sign an executable with the expected signer name and add the certificate to their machine's root store, causing the signature to appear valid.
Well, I haven't been confronted to that kind of problem, but you can first check if the process is running by searching by name (in your case, that would be notepad.exe), parse the Process.GetProcesses() list for that, then get
Process.StartInfo.FileName
and see if this is the path to the Notepad executable, that would do the deal, right ?
What exactly do you know of the executable we want to be running? If you knew the filesize that could work as a "hack". Use #josh3736 's method, but replace point 4 and 5 by comparing the filesize with the one you know [different versions will have different sizes, but if there are not too many you can hardcode them]. Calculation a Md5-Hashtag would look more professional, but would do basicly the same thing.
**
If your process has a GUI: you could use EnumWindows for the children to get Edit-Boxes etc. Find something destinctive for your "notepad.exe" and check if it's there.
Is there a way to detect the file name of a file when a user prints from any application, somwhere in the printer events? I am looking for a windows api where I can determine what file is being printed.
Print jibs are opened with names but typically this doesn't mean the filename - the names which are displayed in the print queue are accessible by querying the printer driver directly I believe.
The printer driver does not have any external API for finding the filename. I assume you would be looking at creating some kind of systray agent sort of app that would be monitoring print queues for jobs being sent. If so -
Refer to http://support.microsoft.com/kb/196805 for a microsoft tool that allows you to monitor print queues for print job status
Refer to http://msdn.microsoft.com/en-us/library/ff562742%28v=vs.85%29.aspx which explains how Windows supports printer change notifications. You can create an app that registers for this and get handle to the Print Queue. Once you get a handle you can call the GetPrinter and GetJob APIs to get access to the JOB_INFO_2 structure. The pDocumentName in the JOB_INFO_2 structure is the name of the file
Hope this helps. If so, please vote a +1 :)
No, there is not, at least not reliably. Keep in mind that there may not be a file name at all. For example, I could open an application like notepad, type some stuff, and print. What file am I printing? None.
In the above scenario most applications will provide some sort of default file name like "untitled", and sometimes you can find that name by parsing the print job's name. For example, if you call GetJob, the JOB_INFO_1 struct's pDocument member will contain a pointer to the print job's name, and that name will often contain the file name.
However, every application formats it differently, and some don't provide it at all. So the answer is you can find the file name perhaps 75% of the time with a lot of effort, but there simply is no 100% solution.
On UNIX, I can, for example, tell the OS that the mapping will be needed in the future with posix_fadvise(POSIX_FADV_WILLNEED). It will then read-ahead the data if it feels so.
How to tell the access intend to Windows ?
Beginning with Windows 8, there is the PrefetchVirtualMemory function for this purpose.
Actually, as Anders mostly suggested, there is no such method in the memory management functions available in Windows 7 and earlier.
2 different ways exists to do something similar :
Read the data asynchronously with ReadFileEx. The data might then still be in the file cache when needed later.
Open the file with a streaming hint with the FILE_FLAG_SEQUENTIAL_SCAN attribute of CreateFile. Readahead would then perhaps be automatically done.
You can pass FILE_FLAG_RANDOM_ACCESS or FILE_FLAG_SEQUENTIAL_SCAN to CreateFile()