Background: There are vulnerable kernel mode drivers for Windows systems, which can be loaded into the system for various purposes. Loaded kernel mode drivers leave traces in the system. Anti-cheat software for video games, for example, look for vulnerable driver traces in various parts of the system because they are used for cheating. The logic used by anti-cheat software could perhaps be (or were already) used by anti-rootkit tools or rootkits themselves.
I am wondering where traces are left after drivers are loaded and then unloaded. From my research, I found these two places in Windows NT kernel, where unloaded drivers leave traces:
(Just to let you know, those are undocumented data structures)
Where else could they leave traces? Is it possible for me to learn it without reverse-engineering the Windows kernel by myself?
I just searched several dozen .msi files, one by one, using Orca to extract the ProductCode from the Property table. It was cumbersome, and I made a couple mistakes when copy/pasting the values. I will have to repeat this task (for a greater number of msi files) at irregular intervals.
I wish I had a tool to echo the selected attributes from a given table in a file (sort of Select Value from Property where Property="ProductCode") - either as a library or as a complete program so I can traverse a directory tree and apply it to all (relevant) msi files.
This time, I needed the ProductCode from the Property table, but later I may want any attribute from any table in the file(s), if it exists.
Does any such program or library exist?
(I do not have resources to dissect e.g. the Wix source code to learn the database structure inside .msi files!)
I do something like that all the time. I just wrote a small VBScript to return the ProductCode in an InputBox. It's easy enough to do.
I added the script to the context menu for .MSI files. Now I just right-click an .MSI and click "Get ProductCode..." Done.
It's very unlikely you're going to find any such tool as you describe. It seems specific to your situation only, so you're probably going to have to write your own tool to traverse your directory tree and gather the specifics you need.
Traversing the directory tree is trivial - I once made a general mechanism for that, and use it all the time (for listing files not accessed for x days, for listing dependencies of Python pakcages, for counting lines of code, for creating warnings about paths that are getting close to the old 260 char limit,...). To this directory travesal function, I supply one or more search roots, filters (such as Extension = "msi"), and a callback function that receives each file that passes the filter. An optional callback handles directory hits, or directories with file hits.
So that part of it is in place. My problem is how do I make that callback function with "a small VBScript to return the ProductCode"? Which mechanism did you use to obtain that value? Is that script available?
The only way I am aware of to read out the ProductCode (or any other .msi value) is to use the GUI application "Orca". At least as a GUI application, it is poorly suited for callback function. It seems to be callable from a script, but the help information gives no help on how to extract a given attribute from a given table. How did your VB script read out the values from the .msi file?
I am programming in C#, but I guess that I could adopt the same mechanism. If I cannot rewrite it to C#, I can run it as a separate process and analyze the console output (I do that all the time, for my other tree traversal functions).
Set msi = CreateObject("WindowsInstaller.Installer")
Set database = msi.OpenDatabase(WScript.Arguments(0), 1)
Set view1 = database.OpenView("SELECT `Value` FROM `Property` WHERE `Property` = 'ProductCode'")
Set record = view1.Fetch
If record IsNothingThen
MsgBox "Unable to find a ProductCode in the MSI database!"
productCode = record.StringData(1)
Set record = Nothing
Set view1 = NothingSet database = NothingSet msi = Nothing
InputBox "The ProductCode is:", WScript.Arguments(0), productCode
My WiFi drivers have not been functioning well lately. They stop working and don't display any error indication until I try to disconnect/connect, and the network I'm on is alone in the network taskbar thing. Sometimes the driver even vanishes without a trace, and I need to reinstall it/restart my laptop to get it working again.
-My laptop is a Lenovo X220
-I run Windows 7 (Professional, I believe)
-My WiFi drivers (I have tried multiple) are Intel
-I know that it's a software issue, as I changed the hard drive between laptops (the same model) and there was no difference.
Any help at all is much appreciated, and this problem is very annoying when I'm trying to play online with .
Hey there, I run a computer repair shop and I'm looking to make basic diagnostics easier for me. I have a list of tasks I do to a computer but I would like to automate with a program. I was wondering what language would best to code the following criteria:
Pull System info such as Version of Windows, processor information, GPU information, Ram, Hard drive and just those basic information. I would then like to export this information to my website or to a text file.
Task Two: Run certain programs I use to clean up the computers. I run them in a certain order so I'd like to be able to somehow run them in a certain order and then when each program finishes, to create a report of the results.
Do you think this would be possible in one program/language? Or would it be best to separate the task based on which programming language would be most efficient? I want to be able to just put it on a flash drive or run a program and just have it autorun while I do other things and then come back to it later.
Imagine a user-mode process is communicating with a driver using IOCTL (DeviceIoControl).
1.) I'd like to learn if there is a way to find if a process is communicating with a driver.
2.) In which cases would it be impossible to find it? For example there are multiple ways that a process can communicate with a driver: IOCTL, shared memory, netlink, system calls, netlink Sockets etc.
"As far as I can see, the future of native applications on Windows has very little to do with the Microsoft Store. However, I do not expect the store to disappear. But I expect that UWP will disappear, especially on the Windows desktop. And that the Microsoft Store remains irrelevant to most users and most developers."
This sums up my opinion of UWP pretty much since its introduction. Thoughts? Any fans of UWP over "legacy" WPF desktop app development?
The thing you have to remember about Thurrott is that he's aiming to make money from clicks so titles like this are massive clickbait. UWP will not disappear - for some reason, he completely failed to understand what all the announcements at Build were wrt UWP.