I have a program (a game, really), which uses a .wad file to store its resources. Is it possible to somehow intercept access to this file, and emulate it?
For instance, I want to dynamically replace some sprites. Instead of creating a new file, is it possible to make this game think it is accessing the .wad, but actually we process its requests?
Under Windows the File System Filter Driver provides a low level I/O hook that a program can register to be passed the I/O requests to the file system.
Filter drivers can also alter the data passed via filters or deny filesystem requests.
Implementation, maintenance and support of your such kernel-mode code is non-trivial.
Anyway you could also take a look at:
Winpooch: an antivirus has to intercept file accesses so an open source antivirus can be a good starting point to study filters.
EasyHook: for Windows API hooking
Related
I'm doing an embedded-system project now. From my view, AT commands can be sent to a device to retrieve 4G information, dial and so on. On the other hand, we can also do that by calling APIs provided by the 4G vendor.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
TL;DR
Vendor's API (not only C, but also C++, Java or Python depending to the vendor and the modem model) can both be wrappers for AT commands and a wider, more powerful set of API were the user can port complex applications.
It depends on the vendor and on the model.
A jungle of modems produced by different vendors
It is impossible to define a general "rule" about API provided by a Cellular Module (not necessarily a 4G module).
First of all every vendor usually implements standard AT Commands (both Hayes commands and extended standard commands for cellular devices). In the same way every vendor has it's own implementation of the user application area where the customers can store their own application to control the modem's functionalities and to use them according to their own application requirements.
AT commands remain the interface to be used when the modem needs to be connected (and driven) by an external host. When the user application area is used, instead, a wider set of API is usually provided. They may include:
A library exporting a subset of the OS capabilities (threads management, events, semaphores, mutexes, SW timers, FS access and so on)
A library offering the capability to manage the specific HW of the device (GPIOs, SPI, I2C, ADC, DAC and so on)
A library offering a programmatical way to perform action, related to connectivity, that would normally be executed through AT commands (registration status check, PIN code insertion, PDP context activation, SMS management, TCP/UDP/TLS sockets)
The latter usually access a base layer involving all the functionalities provided by the modem. Usually this is the same layer invoked by the AT commands sent through modem's serial interface.
Sending AT commands... from the vendor's API?
Of course it often happens that the library mentioned above provides just a subset of the functionalities usually exported with the AT commands set so, in order to "fill the gap", a further set of APIs is usually exported as well:
A set of functions that allow the simulation of AT commands sent to the modem's serial port. Sending them and parsering the responses they send in the vitual internal serial/USB interface allow the user to port in the internal user application area the the application they previously run on an external host processor (with obvious BOM benefits).
As an example, please check Telit Appzone here and here. It was the inspiration of my answer because I know it very well.
I don't know why you name the title that there's a relationship between AT command and Linux-C API.
Regarding AT command, you can take a look at this wiki article for general information.
Each module has a specified AT command sets. Normally, the module manufacture just offers AT command set and what return values are.
Is API a wrapper of AT command?
If you can use the API provided by the manufacturer, then yes, it's a wrapper of the AT command handler.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
It is impossible to be sure without having any details of the device, but probably any C API for it wraps the AT command set, either by communicating with the device directly over an internal serial interface or by going through a device driver that uses AT commands to communicate with it.
However, it is at least conceivable, albeit unlikely, that the 4G device offers an alternative control path that the C API uses (definitely via a driver in this case).
I'm not quite sure what the point of the question is, though. If you are programming the device and its 4G component in C, and the manufacturer has provided a C API, then use it! If you are programming in some other language then at least consider using the C API, which you should be able to access from most other languages in some language-specific way. You should not expend effort on rolling your own without a compelling reason to reject the API already provided to you.
I am trying to implement "simple file-system" for my personal experience. For this, I have created a block device driver with which I will perform read/write operations in unit of blocks. Now my question is how should I perform open, read, write and close operation on the block device from the user application.
What I am actually looking for is a function with which I can open the block device /dev/sbd and it returns the struct block_device, if successful. And for the read/write functions, I can issue request to block device struct request with parameters as "buffer, sectore_number, numbe_of_sectors".
Till now I only got block_read() and block_write() functions. But it seems that they are BSD specific. And I am using Debain.
Anyone having idea about it?
Thanks.
I've been doing something similar writing a application level file system that works with files or devices. What you are writing is not really a device driver as device drivers are directly handled/used by the kernel. A user application has no way to access one directly. Regardless, I want to point you to the function calls open(2), read(2), write(2), close(2) (manual page section 2 for all of them). You will need the unistd.h header file to use these. You can set your read/write size as a multiple of your block size when calling read and write. But in the end, you are still going through the kernel.
EDIT: Upon further examination and comments, the device driver really is in the kernel. Normally, there is no direct connection between a driver and an application as there are several layers of code within the kernel to abstract the device so it looks the same like everything else to the application.
There are two ways around this. One is to establish one or more system calls in the system call tree to expose the read/write routines of the device driver to the application. Another idea that I had was to use the ioctl (I/O Control) system call to perform this, but this call is meant to control the actual device. For example, the hard disk uses read and write commands to transfer data, but to talk to the hard drive to get information about it, such as what the last LBA is or get its identity, you would use IOCTL to do that.
Hope this helps.
I've been looking at Windows's File System Filter Drivers. I started with this "FsFilter" example:
http://www.codeproject.com/Articles/43586/File-System-Filter-Driver-Tutorial
With effort, I managed to get it built and signed in versions that work on everything from 64-bit Win8 to 32-bit WinXP. (Well, as long as I run Bcdedit.exe -set TESTSIGNING ON to allow it to accept my test certificate, since I didn't pay Microsoft $250 to sign my .SYS file. :-/)
Now I want to modify FsFilter. I'd like write accesses to certain types of files to be trapped by the filter. I then want the user to receive a dialog box, in which they can either allow the access or deny it.
Perhaps obviously...the kernel-mode code cannot display the UI. It will have to signal some user mode process, which will (after an arbitrarily latent period of time) signal back the user's wish to the driver. I've looked a bit over
User-Mode Interactions: Guidelines for Kernel-Mode Drivers (here's Google's Cache as HTML, instead of .DOC)
I don't know what the best way to attack this is. The only example I've yet found to study is SysInternals FileMon. The driver it installs gathers data in a buffer, which is periodically requested by the .EXE according to a WM_TIMER loop:
// Have driver fill Stats buffer with information
if ( ! DeviceIoControl( SysHandle, IOCTL_FILEMON_GETSTATS,
NULL, 0, &Stats, sizeof Stats,
&StatsLen, NULL ) )
{
Abort( hWnd, _T("Couldn't access device driver"), GetLastError() );
return TRUE;
}
Should I use a similar technique? Perhaps the filter driver, upon receiving a request it wants to check, could place a record to track the request in a buffer that would contain two HEVENTs. It would then WaitForMultipleObjects on these two HEVENTs, which represent a signaled "YES" or "NO" from user mode on whether to allow access.
Periodically the monitor process (running in user mode) will poll the driver from another thread using a custom IOCTL. The filter driver would return the request information... as well as the two HEVENTs that request is waiting on. The monitor would wait for the user's feedback, and when available signal the appropriate event.
I could also invert this model. The user mode code could use a custom IOCTL to pass in data... such as HEVENTs which could be signaled by the driver, and just implement some kind of safe protocol. This would eliminate the need for polling.
Basically just looking for guidance on method, or a working example on the web! I'd also be interested to know what the mechanics would be on an asynchronous file access. I assume there's a way so a client making an async call that is being checked could keep running and only be held up when they waited on the request to finish...?
(Note: Along the way of getting the filters built and debugged, I learned there are some more modern techniques via "miniFilters"--which are part of something called the Filter Manager Model. But for the moment, I'm not that concerned as long as the legacy model is supported. It looks rather similar anyway.)
You (a.k.a. I) have pretty much enumerated the possibilities. Either poll the way FileMon does, or pass an event. Passing the event is probably a bit more error prone, and if you aren't a threading guru then there's probably more chance for error. But if you tend to make lots of mistakes then device drivers may not be for you...skydiving might be a poor choice too.
I'll offer taking a look at this project, but please note the disclaimers in the README. (It is only a test and investigation):
https://github.com/hostilefork/CloneLocker
And yes, to the extent that Microsoft and their driver model is to be something one worries about, miniFilters are the better choice these days.
I've been assigned to upgrade an embedded application written in C. The application is configured via a web interface.
When the user modifies the web application a file is written to /var/www/settings.json and the file /var/www/UPDATE_SETTINGS is touched.
In the main application loop it checks to see if UPDATE_SETTINGS exists. If it does it parses the settings.json with json-c and then deletes UPDATE_SETTINGS.
This works well enough, however, we would prefer to move to an event-driven architecture (perhaps libev) in which settings.json is fed directly into the program by the webapp script to a plain-old UDP port and then issue a callback to perform the update.
What are some other elegant ways to solve this problem? Should we just stick with the current approach?
Just use inotify. It was created for cases like yours.
I am making some assumptions here.
1) you are connected to the internet all the time with you embedded device.
2) your device can set up interrupts on things like "USART RX buffer not empty"
note: depending on what kind of hardware you are using you could set up interrupts on things like pings and other stuff this could be another way of interrupting the embedded device.
if those two assumptions are correct you could do this, have another "script" on a server or computer somewhere that watches the /var/www/settings.json for changes you could use something like rsync to watch for changes. this "script" when it notices that the json file changes will communicate to the embedded device using tcp/ip you can either ping the device or just send the file over. If you can set an USART interrupt on the embedded device then the device will be able to detect the data coming in and therefore respond by either reading the data you are sending or going to the website to download the json file to be parsed.
this way you will have an event drive embedded device and it will not waste time checking to see if this json file has changed.
I hope this helps
The user, administrators and support staff need detailed runtime and monitoring information from a daemon developed in C.
In my case these information are e.g.
the current system health, like throughput (MB/s), already written data, ...
the current configuration
I would use JMX in the Java world and the procfs (or sysfs) interface for a kernel module. A log file doesn't seem to be the best way.
What is the best way for such a information interface for a C daemon?
I thought about opening a socket and implementing a bare-metal http or xmlrpc server, but that seems to be overkill. What are alternatives?
You can use a signal handler in your daemon that reacts to, say USR1, and dumps information to the screen/log/net. This way, you can just send the process a USR1 signal whenever you need the info.
You could listen on a UNIX-domain socket, and write regularly write the current status (say once a second) to anyone who connects to it. You don't need to implement a protocol like HTTP or XMLRPC - since the communication will be one-way just regularly write a single line of plain text containing the state.
If you are using a relational database anyway, create another table and fill it with the current status as frequent as necessary. If you don't have a relational database, write the status in a file, and implement some rotation scheme to avoid overwriting a file that somebody reads at that very moment.
Write to a file. Use a file locking protocol to force atomic reads and writes. Anything you agree on will work. There's probably a UUCP locking library floating around that you can use. In a previous life I found one for Linux. I've also implemented it from scratch. It's fairly trivial to do that too.
Check out the lockdev(3) library on Linux. It's for devices, but it may work for plain files too.
I like the socket idea best. There's no need to support HTTP or any RPC protocol. You can create a simple application specific protocol that returns requested information. If the server always returns the same info, then handling incoming requests is trivial, though the trivial approach may cause problems down the line if you ever want to expand on the possible queries. The main reason to use a pre-existing protocol is to leverage existing libraries and tools.
Speaking of leveraging, another option is to use SNMP and access the daemon as a managed component. If you need to query/manage the daemon remotely, this option has its advantages, but otherwise can turn out to be greater overkill than an HTTP server.