I am reverse engineering a driver that implements HID for the purposes of searching for vulnerabilities.
The main IOCTLs it implements are all from the HID minidriver libraries in the WDK.
I am in particular interested in sending malformed values to the IOCTL_HID_SET_FEATURE IOCTL. However, based on Microsoft's documentation:
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidclass/ni-hidclass-ioctl_hid_set_feature
It is somewhat unclear as to how I would set a feature for one particular HID device as opposed to any other from the documentation. It is a little hand wavy as to what is expected to be in a feature report.
The input buffer size, in bytes, must be large enough to hold the feature report -- excluding its report >ID, if report IDs are used - plus one additional byte that specifies a nonzero report ID or zero.
The Irp->AssociatedIrp.SystemBuffer member points to the input buffer that contains a feature report. If >the collection includes report IDs, the requester must set the first byte of the buffer to a nonzero >report ID; otherwise the requester must set the first byte to zero. The feature report -- excluding its >report ID, if report IDs are used - is located at ((PUCHAR)ReportBuffer + 1).
The documentation refers to the IOCTL as targeting a "top-level collection." but based on my reading of my own driver's disassembly it looks like you can specify features on a granular level, specific to an individual device.
Two interrelated questions here:
Is it possible to target these IOCTLs toward a specific device rather than a class of devices? If so how? If you can point me toward an example of a client that does this, that would be awesome.
What specifically is in a HID feature report/where can I find a spec that defines it?
Related
Does anyone know what ZCD may refer to? It is described as a segment with a link back to PreManage for the patient!
Can anyone please provide more details?
The Z segments (segments those begin with the letter "Z") are custom segments. Those are not defined in specifications. They vary from vendor to vendor. Vendor may publish a document explaining usage of segment. Two connected parties should know in advance and decide the usage by mutual understanding.
As those are custom, and if there is no way to know what data they contain, it may be safe to neglect them hoping the sender have not put critical data in it.
Please refer to this:
Z-segments can be inserted anywhere in the HL7 message. A popular approach is to place the Z-segment within a group of segments that contain similar information, such as insurance. Z-segments are also often placed at the end of the message. The advantage of doing so is that this placement prevents systems configured to parse “standard” HL7 format from requiring any configuration modifications in order to process the message. The application simply reads the segments in the order expected and then extracts the data from the Z-segment (if needed) via parser modifications.
Working with unexpected Z-segments
Sometimes systems may send unexpected Z-segments, whether or not they were part of the original specifications. Even if you are not interested in the data in the Z-segment, you may still (depending on its location) need to take the segment into account while testing and developing your interface.
Rather new to Bluetooth Low-energy devices, and having recently purchased a bunch of trackers off Amazon, decided to write a little application to see what type of information I can get from these.
The trackers are from a Chinese company, and they don't have a ton of information around advertisement information, so I'm playing by best guess here.
What I've been able to achieve so far, through Flutter Reactive BLE, is to find the devices by their ID (filter out additional noise I don't care about) and pull information like RSSI, Name and ID from it.
Now I want to interpret the manufacturerData object, screenshot attached of just one of them, and can't seem to get anything concrete from it.
I half assumed that reactive_ble would've stripped the leading checks and only supplied the the necessary portions of the data object that's relevant to interpret, however, this does not seem to be the case.
My first feel was to just convert this UInt8List to String utf8.decode(device.manufacturerData), however, this returns either a 1x spaced string or nothing at all.
I've tried using ByteData with a start of 3 and end of 4, and that's not very helpful either.
Is there something I'm missing in it's interpretation? I've read the Bluetooth spec and as I don't come from a CompSci background, is rather foreign to me, so would appreciate a layman response.
The first 16 bits (little endian) in manufacturer data contain the manufacturer id (Bluetooth SIG's web site has a list). The layout of the rest of the bytes are totally up to the manufacturer. If you can't guess what they mean, you'll have to ask the manufacturer.
Using DDS I know I can print a box and color it in using the the BOX keyword:
A R BOX5 BOX(2.5 0.5 5.1 6.3 0.2 +
A (*COLOR *HIGHLIGHT 3 75)
Is there something similar to create a circle?
According to the DDS Reference: No. I can't find any keywords to directly draw a circle.
My guess is that back in the heyday of high volume impact printers, there was no fast way to print such circles. Note: Impact isn't necessarily the same as dot-matrix printers. Lines were possible with special characters, though. The "language" to steer such a printer was called SCS (SNA Character String).
But you can create a circle as desired with external programs, convert the result to a page segment, using specialized IBM software, and load that via DDS onto a page. See the PAGSEG keyword on the linked documentation for information and caveats. Especially the need to use AFP might pose a serious obstacle. (AFP is — overly simplified and thus not entirely correct — like PCL or PostScript, a page description language. IPDS can be roughly seen as equivalent to PJL.) Ricoh printers sometimes have native IPDS/AFP support. Also, there were some manufacturers for converter boxes, faking an SCS or even IPDS/AFP printer to the host side, and appearing as a PJL/PCL printer data generator to the printer.
The built-in Host Print Transform feature which can be enabled for printer devices converts the spooled output to PCL, so it can be sent to stock printers. The drawback is, it uses local CPU resources which might not be desired. Older releases of the OS might only support SCS with Host Print Transform.
Newer IBM I releases include InfoPrint Server, a java-based background task enabling to convert print jobs on the machine to PDF. I assume this should work with AFP. Not talking about resource usage, though…
Printing on IBM i is a deep rabbit hole in itself. See the accompanying documentation.
I'm in charge of technology at my local camera club, a not-for-profit charity in Malvern UK. We have a database-centric competition management system which is home-brewed by me in Delphi 6 and now we wish to add a scoring system to it. This entails attaching 5 x cheap-and-standard USB numeric keypads to a PC (using a USB hub) and being able to programmatically read the keystrokes from each keyboard as they are entered by the 5 judges. Of course, they will hit their keys in a completely parallel and asynchronous way, so I need to identify which key has been struck by which judge, so as to assemble the scores (i.e. possible multiple keystrokes each) they have entered individually.
From what I can gather, Windows grabs the attention of keyboard devices and looks after the characer strings they produce, simply squirting the chars into the normal keyboard queue (and I have confirmed that by experiment!). This won't do for my needs, as I really must collect the 5 sets of (possibly multiple) key-presses and allocate the received characters as 5 separate variables for the scoring system to manipulate thereafter.
Can anyone (a) suggest a method for doing this in Delphi and (b) offer some guide to the code that might be needed? Whilst I am pretty Delphi-aware, I have no experience of accessing USB devices, or capturing their data.
Any help or guidance would be most gratefully received!
Windows provides a Raw Input API, which can be used for this purpose. In the reference at the link provided, one of the advantages is listed as:
An application can distinguish the source of the input even if it is
from the same type of device. For example, two mouse devices.
While this is more work than regular Windows input messages, it is a lot easier than writing USB device drivers.
One example of its use (while not written in Delphi) demonstrates what it can do, and provides some information on using it:
Using Raw Input from C# to handle multiple keyboards.
I'm developing a product connected to a CAN bus with the J1939 protocol.
In address claiming process, it is supposed to be mandatory to send the NAME of my product, which includes, among other data, a manufacturer code. This manufacturer code is 11 bits length, and it is supposed to be assigned by SAE committee.
But I am a bit confused about this.
With only 11bits length, there are only 2048 different codes. This seems not too many for all manufacturers in the world (and there are some of them that have more than one code assigned).
On the other hand, do I REALLY need a manufacturer code? Is there any strategy that I can use to avoid getting one? Is there any commonly used strategy for this purpose?
On the other hand, do I REALLY need a manufacturer code?
It depends on the nature of your device, if it's intended for mass production, then you'll need to register yourself and get an id.
Is there any strategy that I can use to avoid getting one?
You can use 11'b0 as your ID, but only for experimental/development purposes, othewise you won't be J1939 compliant.
The NAME is used only during the address claiming procedure, where in the case of two ECUs claiming the same address compare their names to check who's keeping it.
The contention basically compares the NAME as a numerical value, the lowest the value, the higher the priority. Depending on what is your device priority the name may not even taked into account.
You need to evaluate the function that your device is playing the the system and assing a higher NAME if it's not critical or lower NAME if is safety related.