In my program written for Linux in C++, I would like to display information (including the device hierarchy) about the PCI devices of the system executing the program. Is there a C- or C++-Linux-API for that?
I am looking at /sys/devices and /sys/bus/pci/devices. The information in those directories is quite raw and I would prefer not to implement a second lspci.
I am looking at /sys/devices and /sys/bus/pci/devices
That's exactly where you get your information from. Personally I prefer to fetch such information directly from there. But you might find, that libudev suits your needs. However be advised that udev, while being widespread, may not be present on some systems.
Related
I am using Windows Portable Device API to access some MTP devices. I want to read the vendor extended properties from the device, it should look something like this:
"microsoft.com/WPDNA" or "microsoft.com/MTPZ"
It seems like this should be a quite simple task but I cannot figure it out.
I have been able to enumerate objects on a device and transfer files and so on, this was included in the WpdApiSample Application.
I also found this article that I think is what I want to do. But I don't understand how to create those queries.
Without getting into code, the short answer is to scan a range of PIDs for a given FormatID to see what kinds of data are in there. This is a debugging exercise, just for discovery purposes. I basically just write a loop: for example if I want to scan for the first 16 PIDs under the basic extended properties you'd use the WPD_PROPERTIES_MTP_VENDOR_EXTENDED_DEVICE_PROPS as FormatID and then for PID change it on each iteration and scan values 0xD101 through 0xD10F. You can usually tell from the output what may be contained in that PID location.
Once you know the PIDs for the pieces of data you want, you can write that into your code as part of your enumeration routine.
Does anyone know a way to programmatically retrieve the ram memory manufacturer?
Thanks!
Modern RAM chips have an additional EPROM on board that contains a lot of information about the RAM. The standard for this is SPD, or Serial Presence Detect. At least some versions of SPD include a JDEC manufacturer's code.
Look at this article for some introductory information on SPD. Not every RAM chip has the information you need, and not every BIOS exposes it, but the article should get you started on handling this stuff in those cases where it's possible.
In WINAPI, you should be able to call GetSystemFirmwareTable to retrieve the SMBIOS table, and then parse the table to extract that information.
See this
http://msdn.microsoft.com/en-us/library/ms724379%28v=VS.85%29.aspx
And this
http://dmtf.org/sites/default/files/standards/documents/DSP0134_2.7.0.pdf
The other option, as mentioned by ruslik, is to use WMI, as described here
http://msdn.microsoft.com/en-us/library/aa390423%28v=VS.85%29.aspx
(you're looking for objects of type Win32_PhysicalMemoryArray)
I'm not sure which way would be easier. Both seem hard.
I would like to create a virtual drive for windows. I'm not looking to map a drive or something like that, I'm looking to map it to my DLL functions or something of that sort.
How can I get this accomplished?
I read that I would have to develop a device driver, or a shell extension?
I have a lot of experience with C++ and C#. Where do I get started?
I want to make it as simple as possible at first, how much time do I think it would take me? And what's the simplest way to do it, so that I could build my prototype.
My motivation is to pipe a file into an application, that currently only reads files from the file system. I'm only interested in pumping 1 file, so I think that a whole virtual drive would be an overkill, as well as writing kernel mode code.
If you want to build it from scratch then yes, you have to build a driver. However, it would be much easier for you to use a proxy driver like Dokan, and create the file system in user mode.
Take a look at the Wikipedia article on IFS, there are links to other useful tools at the bottom of the page.
I don't know what it worth, and it's not open source, but I've found this. It's a "fuse" like for windows
I've recalled using little 'filesystems' before that basically provided an interface to something else. For example, I believe there was a GMail filesystem that created an entry in My Computer and could be used like any other drive on your local computer. How can I go about implementing something like this in C++?
Thank you!
Try Dokan. It's like FUSE, except for Windows. I think there are certain limitations to namespace extensions, like they cannot be accessed from the command line, but I'm really not sure as of now.
Writing an actual file-system involves writing a driver; which means kernel-mode code (scary stuff) and paying for getting the IFS DDK. (edit: looks like they don't charge for it anymore)
What you probably want is a “namespace extension”.
Try this: The Complete Idiot's Guide to Writing Namespace Extensions - CodeProject
This may be a starting point to extending NTFS in the way that the GMail filesystem used to do: Windows NT reparse points.
The GMail Filesystem is just the name given; it is not any filesystem as such. It is just a namespace extension for Windows Explorer that links with the GMail account of yours!
I dont know exactly what you are trying to do, but in anyway, I believe, the following link will be of some use to you:
http://msdn.microsoft.com/en-us/magazine/cc188741.aspx
Just as a reference: virtual drives can be created using our Callback File System product, which is a supported, documented and maintained solution.
I was thinking of this too, perhaps some example code ? (email me if i forget plz ;p doin sdk now)
I'm thinking of a similar filesystem that would plug in as a driver and allow dynamic 'soft raid' on larger files mostly by putting them on more than one disk, perhaps some compression options and 'smart' filters to toggle usage in high disk space low usage and other situations more effectively, with status controls and indicators as a normalish program too
Seems like I would load the driver kit,
then i want the file writing event, and am mostly replacing fopen and similar functions automatically as an intermediate driver with a little windows network driver experience
I also heard good things about developing on a virtual machine for less crashing and more debugging
Also perhaps more metainfo on some or all files, including files in special folders with options too, including maybe both fast and simple (obfuscated and/or symmetic key) encryption options on folder, specified, all, letter, etc, or whatever, or the slower version and maybe integrated and optional (also profitable) online cvs-like diff style backups that mostly target changes to hot files for online backup at intervals and prices, mostly perhaps with matching keyboard events and might even be useful as simply a keylogging online backup service that is reasonably secure too
while avoiding common files like windows files or the normal stuff in the 'programs' directory that can be copied easily with pirate tools, unlike all of your documents.
I'm trying to write a chat client for a popular network. The original client is proprietary, and is about 15 GB larger than I would like. (To be fair, others call it a game.)
There is absolutely no documentation available for the protocol on the internet, and most search results only come back with the client's scripting interface. I can understand that, since used in the wrong way, it could lead to ruining other people's experience.
I've downloaded the source code of a couple of alternative servers, including the one I want to connect to, but those
contain no documentation other than install instructions
are poorly commented (I did a superficial browsing)
are HUGE (the src folder of the target server contains 12 MB worth of .cpp and .h files), and grep didn't find anything related
I've also tried searching their forums and contacting the maintainers of the server, but so far, no luck.
Packet sniffing isn't likely to help, as the protocol relies heavily on encryption.
At this point, all my hope is my ability to chew through an ungodly amount of code. How do I start?
Edit: A related question.
If your original code is encrypted with some well known library like OpenSSL or Ctypto++ it might be useful to write your wrapper for the main entry points of these libraries, then delagating the call to the actual library. If you make such substitution and build the project successfully, you will be able to trace everything which goes out in the plain text way.
If your project is not using third party encryption libs, hopefully it is still possible to substitute the encryption routines with some wrappers which trace their input and then delegate encryption to the actual code.
Your bet is that usually enctyption is implemented in separate, relatively small number of source files so that should be easier for you to track input/output in these files.
Good luck!
I'd say
find the command that is used to send data through the socket (the call depends on the network library)
find references of this command and unroll from there. If you can modify-recompile the server code, it might help.
On the way, you will be able to log decrypted (or, more likely, not yet encrypted) network activity.
IMO, the best answer is to read the source code of the alternative server. Try using a good C++ IDE to help you. It will make a lot of difference.
It is likely that the protocol related material you need to understand will be limited to a subset of the files. These will contain references to network sockets and things. Start from there and work outwards as far as you need to.
A viable approach is to tackle this as a crypto challenge. That makes it easy, because you control so much.
For instance, you can use a current client to send a known message to the server, and then check server memory for that string. Once you've found out in which object the string ends, it also becomes possible to trace its ancestry through the code. Set a breakpoint on any non-const method of the object, and find the stacktraces. This gives you a live view of how messages arrive at the server, and a list of core functions essential to message processing. You can next find related functions (caller/callee of the functions on your list).