how to : do 2 way communication between user mode and kernel mode - driver

I have written a driver, that extracts a value from IRP buffer. Now based on this keyword I have to pass or discard the IRP. So I need to communicate with the database which is not easy from kernel mode driver. So I am using an application or exe for doing this which will result in true or false based on which I will pass or discard the IRP.
I want to link the driver with the application that I get the data in the client application.
I thought about using temp file that can act as a pipe.
Please suggest something.

I would go with IOCTLs.
The application communicating with database starts with sending one or more IOCTLs to the driver. Let's call IOCTLs of this type IOCTL-1.
The completion of IOCTL-1 idicates a request from driver to the database. The request details can be passed in IOCTL output buffer.
The application detects IOCTL-1 completion, retrieves the request details, runs the query and passes results to the driver using a different IOCTL (IOCTL-2). Then it re-sends IOCTL-1 so that the driver can issue another request.

Related

Encrypt and compress a FirebirdSQL 2.5 backup on-the-fly from Delphi7 securely

We need to protect customer data and using FirebirdSQL 2.5(.8) with Delphi 7.
Also it is essential to do regular backups on "secondary" PC, or pen-drives if the "master" fails.
For that we used this method, calling Gbak.exe and 7z.exe with stdin/out.
Realized that was a bad idea because it's very easy to see the parameters (passwords) added to command line during the process, even with a simple Task-manager.
Is there a more secure way to do it?
(Using standard Interbase componenst OR UIB)
Upgrade to Firebird 3 which added Database Encryption capability. If you don't want or cannot, I believe you might run the GBAK tool from your application with the STDOUT option but instead of using 7-zip for compression you would read that output in your application, and encrypt such input by some encryption library on the fly.
I believe you may find many examples how to run an application and read its standard output over here (here is something related to start with), so the rest might be about finding a way of an on the fly stream encryption. Or just capturing STDOUT in one stream and encypting in another.
Firebird guys on SQL.ru forum say, that actually it is possible to use Services API to get backup stream remotely.
That does not mean that IBX or UIB or any other library readily support it though. Maybe it does, maybe not.
They suggested to read Release Notes for Firebird 2.5.2 or Part 4 of doc\README.services_extension.txt files of Firebird 2.5.2+ installation.
Below is a small excerpt from the latter:
The simplest way to use this feature is fbsvcmgr. To backup database
run approximately the following:
fbsvcmgr remotehost:service_mgr -user sysdba -password XXX action_backup -dbname some.fdb -bkp_file stdout >some.fbk
and to restore it:
fbsvcmgr remotehost:service_mgr -user sysdba -password XXX action_restore -dbname some.fdb -bkp_file stdin <some.fbk
Please notice - you can't use "verbose" switch when performing backup
because data channel from server to client is used to deliver blocks
of fbk files. You will get appropriate error message if you try to do
it. When restoring database verbose mode may be used without
limitations.
If you want to perform backup/restore from your own program, you
should use services API for it. Backup is very simple - just pass
"stdout" as backup file name to server and use isc_info_svc_to_eof in
isc_service_query() call. Data, returned by repeating calls to
isc_service_query() (certainly with isc_info_svc_to_eof tag) is a
stream, representing image of backup file.
Restore is a bit more tricky. Client sends new spb parameter
isc_info_svc_stdin to server in
isc_service_query(). If service needs some data in stdin, it returns
isc_info_svc_stdin in query results, followed by 4-bytes value -
number of bytes server is ready to accept from client. (0 value means
no more data is needed right now.) The main trick is that client
should NOT send more data than requested by server - this causes an
error "Size of data is more than requested". The data is sent in next
isc_service_query() call in the send_items block, using
isc_info_svc_line tag in traditional form: isc_info_svc_line, 2 bytes
length, data. When the server needs next portion, it once more returns
non-zero isc_info_svc_stdin value from isc_service_query().
A sample of how services API should be used for remote backup and
restore can be found in source code of fbsvcmgr.

How to obtain SCARD_ATTR_DEVICE_UNIT correctly

I am developing a smartcard UMDF windows driver. I would like to achieve following behaviour:
When listing all connected readers by using API call SCardListReaders I want to retrieve the correct friendly names for each attached reader. So for example if I have two readers of same brand I want this to be returned by the driver:
SmartcardBrand USBReader 0
SmartcardBrand USBReader 1
I know that the friendly name is composed of the attributes SCARD_ATTR_VENDOR_NAME, SCARD_ATTR_VENDOR_IFD_TYPE and SCARD_ATTR_DEVICE_UNIT the driver returns.
My question is, in my driver, how can I distinguish between SmartcardBrand USBReader 0 and SmartcardBrand USBReader 1?
What shall I return to the OS when SCARD_ATTR_DEVICE_UNIT is requested. I cannot use and increment a global static variable in my driver because every time a new reader gets connected a new UMDF host process is launched (I can see it in the task manager) resulting in a separate new memory area.
What is the proper way of counting device instances in a UMDF driver?
I solved the problem by using memory-mapped files. Basically each UMDF process of my driver creates a memory-mapped file with name of the reader's friendly name. When an other process tries to create a file with the same name it indicates that a driver is already running.
However, there is inconsistency when I connect a reader which uses my driver and afterwards connect a reader which uses Windows native driver. The Windows driver will not see my memory-mapped file I created and apply index 0 for its device.
I found out that, when the Windows driver is loaded it queries SCARD_ATTR_VENDOR_IFD_TYPE, SCARD_ATTR_VENDOR_IFD_TYPE and SCARD_ATTR_DEVICE_UNIT from my driver (and from all other drivers currently loaded). I guess this way the Windows driver can know which device units are taken and apply a free one to its reader.

Sending value from kernel mode to user mode

I'm developing a kernel-mode driver for an Anti Virus program, but I've a problem in Drivers section
I want to send a string value (For example "String") from Kernel-mode driver to user-mode application .
can anyone help me to do this ?
This question was asked a long ago, and I hope you have found the solution. I am posting this solution as there was none.
It depends on how you want to send the string to the user mode client application.
One way is IOCTL command. You issue a simple IOCTL command with METHOD_BUFFERED (assuming that string is little data) and voila, you are done.
Other way is to make client wait for an event, and make driver fire an event when that string is available to kernel driver. Then, as the wait in the user mode application is over, you will get the data. (of course, if wait didn't timed out or many other things)
There is function copy_to_user defined here
include/asm/uaccess.h. With help of it you can safely copy data from kernel mode to user mode.

How to show transfer progress during a DataSnap transmission?

I have a ISAPI DataSnap server and a client application, which communicate over the web. I have been looking for a way to show data transmission progress when the client application is retrieving data or applying updates, but so far I haven't found anything except to set ClientDataSet.PacketRecord to a small number and run a loop to retrieve packets. Since my data contains BLOB data, this method isn't very practical, as each record might grow beyond 1024KB. Is there a way to monitor the actual TCP/IP communication between my client application and the server?
Is it possible to throw a TIdHTTPProxyServer on my client application and monitor data transmission using it?
Update:
Even if that's possible, I'm concerned about the send/receive routine being executed in the main thread, and thus blocking any GUI activity. I read somewhere that I could execute these calls (Refresh and ApplyUpdates) in separate threads, but I haven't got a clue on how to do this.

Virtual channels for VNC?

Does anybody know weather VNC (RFB) supports virtual channels and add-ins to them like it is in the RDP (Microsoft Terminal Services)? I just want to transfer my own data across a VNC connection...
VNC/RFB does not have virtual channels unfortunately.
Here is the best reference I've found to the RFB protocol: http://tigervnc.org/cgi-bin/rfbproto
Without knowing more about what you are trying to send and which direction(s), there are a few of options that come to mind:
The tight encoding has file-transfer support. There is a poorly formatted specification for the full tight encoding here: http://vnc-tight.svn.sourceforge.net/viewvc/vnc-tight/trunk/doc/rfbtight.odt?revision=3619
If you have control of both client and server, then you could define a custom encoding that allows you to send your data. The client would advertise that it supports the encoding and if the server supports it then it will start using it.
You could use the clipboard messages (ClientCutText and ServerCutText) and if you need to send binary data that create a custom encoding the data as ISO 8859-1 (Latin-1). The downside is that if the server doesn't support it and the client sends the data it will get pasted to the server.
If you just need to send from the server to the client, then you could use a framebufferUpdate message that sends data outside the current viewport (i.e. 123 pixels beyond the right side of the viewport). Clients without support may not handle this well though.
Another option if you just need to send from the server to the client, is that you could send a framebufferUpdate within the viewport with a special marker and then immediately send a framebufferUpdate (even in the same packet) with the real visible data to replace it. This would work with existing clients (a bit more overhead). Clients might see brief flicker though.

Resources