few days ago I asked here about implementing USB. Now, If I may, would like to ask few more questions, about thing I dind´t quite understood.
So, first, If I am right, Windows has device driver for USB interface, for the physical device that sends and receives communication. But what this driver offers to system (user)? I mean, USB protocol is made so its devices are adressed. So you first adress device than send message to it.
But how sophisticted is the device controller (HW) and its driver? Is it so sophisticated that it is a chip you just send device adress and data, and it writes the outcomming data out and incomming data to some internal register to be read, or thru DMA directly to memory?
Or, how its drivers (SW) really work? Does its driver has some advanced functions like send _data to _device? Becouse I somewhat internally hope there is a way to directly send some data thru USB, maybe by calling USB drivers itself? Is there any good article, tutorial you know about to really explain how all this logic works? Thanks.
The USB protocol stack has several layers and is quite complex. You really need to read a good book on USB (e.g. USB Complete) to get an understanding of how it all fits together. The bottom line though is that you want to go as high up the protocol stack as you can, ideally using a system level API (e.g. if it's a USB HID device then just treat it like any other HID device, rather than thinking if it as a USB device - ditto for mass storage devices, etc).
Related
I have a USB device (actually, a digital camera) that talks the MSC protocol, i.e. it appears as a disk device and can be talked to with SCSI commands. When it's connected to a Mac, the IOBlockStorageDriver takes over and mounts the volume.
Now, my goal is to prevent this from happening, in hopes that I can then talk to the device thru the SCSI interface functions for SCSITaskDeviceInterface, provided in <IOKit/scsi/SCSITaskLib.h>.
Is that possible? The SCSI Architecture Model Device Interface Guide states that the SCSITaskDeviceInterface is only available for types other than $00, $05, $07 and $0E (the MSC device is type 00), but I wonder if that's only because these types are taken over by the Mass Storage driver and therefore are not available. But if I prevent the Mass Storage driver to take over, will these types, such as 00, become available via SCSITaskDeviceInterface?
If that's possible, what must the kext code do to achieve this? E.g, which class should it subclass and which functions must it implement so that it prevents the mass storage driver from taking over while keeping the device visibile as a SCSI device in the io registry?
If that's not possible, could I then instead use the kext to provide a way to offer SCSI-cmd passthrough somehow? I would like to be able to send custom CDBs to this kext from userland, and it should then route them through the SCSI layer to the USB device. Is that possible? Assuming the kext has received a CDB string, how would it locate the SCSI functions for passing the data onward to the USB layer?
I've so far based my unsuccessful tests on Apple's VendorSpecificType00 sample project, which shows how to inject a kext that adds handling custom properties for a SCSI device.
For now, let's ignore upcoming kext deprecations by recent macOS versions (I want to get this working on High Sierra first).
I want to hack other vendor's microphone driver data. E.g. to change the voice from man to woman.
Solution 1:
Record the vendor's mic data and hack the data, then stream it to a virtual microphone driver, which could be listened by all apps.
Solution 2:
Use APO, and below is Microsoft's official code on GitHub. You could find its APOProcess() function which is used to handle its driver data, to add delay.
https://github.com/microsoft/Windows-driver-samples/blob/master/audio/sysvad/APO/DelayAPO/DelayAPOMFX.cpp
But in this case, the APO hacks its own driver's data.
While my purpose is to hack other vendor's microphone data, whose code is not available for me. So APO is still work in this kind of case? E.g. an accessable shared memory for all vendors' microphone data?
Or any other solution?
I have a device that is emulating nfc tag using pn71501 chip. I don't know how exactly code works in that device but what I definitely know this chip can emulate tag using only ISO14443 standard. So both my readers can read this type of tags but by some reason I can read from this device is UID, nothing else. As I know reading memory from tag with ISO 14443 requires block authentication but it doesn't help for me. For reading tags using IDtronic EVO HF I use software downloaded from here: https://download.idtronic.de/Card%20Reader/Card%20Reader%20HF%20SET%20SDK.zip
For ACS ACR1252U I tried many different apps including my own apps and none of them could read it.
Interesting fact is that android and ios devices can read it.
If you look at the datasheet for that chip it says "PN7150 does not support a complete card protocol. This has to be handled by the host controller"
So the chip itself might not be doing any more than than ISO 14443 A-3 and B-2 parts which really only includes the Anticollision and UID and then storing/transmitting data is handled by the host controller using the higher level protocol parts.
Also the free software you get with card readers tend to be very basic and just reads the UID for inventory purposes, you have to write your own software if you want to do more with these readers and they usually like the ACR1252U have a datasheet on how to do this.
So the question is what is the host controller attached to the NCF chip doing and software it is running?
Update based on comments
I would assume that host controller does implement one of the higher level protocols for a Type 3 or 4 Tag (most likely Type 4)
The you just need to write a program for the USB readers to correctly issue the right commands to read the right type 3 or 4 Tag.
As noted the Android (or Iphone) "Taginfo" App from NXP implements reading using the Type 3 and 4 protocols, so this should tell you what the Tag is behaving as and the you can write the software for the USB readers to match.
Type 3 and 4 specifications
Suppose I have a SIM (which can be used to send SMS when plugged onto a phone of course), how can I send SMS using this SIM number when the SIM is not plugged to any device(i.e., just put it away)? Note: I don't mind what platform the sms is sent from (e.g., it can be sent from a PC, a smart phone), so any possible solutions? I don't mind solutions which involves coding or programming (e.g., by calling APIs) as well.
Note highly simplified/high level answer:
In order to send an SMS, USSD, Call or Data etc the Mobile Network will need to provide the device with a special "key" that is used in the communications. I.e. to send and SMS you will need an encryption key to tell the network to send an SMS.
The issue is that this key is dynamic, it changes based on network configuration. The only way to get a key is to use your SIM as it contains a component of the key.
SIM cards (and Bank chip cards) are really a marvel as they are a very good example of superb security, they have been around in Billions of units for more than 30 years, but have and continue to thwart hacking attempts for the most part.
To answer your question, You need the SIM card to get access to production mobile networks.
If by saying "SIM is not plugged to a phone" you still Ok about SIM to be plugged into some other device - you defintely can use USB/GSM-modems and standalone GSM-gateways.
Also you may want to consider hardware solutions such as GSM-gateways+SIM-banks. SIM-card is placed in the special non-GSM box (SIM-bank) and available for remote commutation into GSM-box (gsm-gateway) via Internet/Ethernet. Commonly SIM-bank holds hundreds of sim-cards remotely available, and GSM-gateways have only few dozens of real gsm-channels (due to hardware cost saving). Everything is controllable via manufacturer-specific API and/or GUI.
I am testing a custom FPGA NIC and I need to send management information (such as header info for matching) and traffic data to it using a traffic generator from within the user space.
The driver built for the FPGA is a modified version of IXGBE with DMA support for management, and also supports DPDK for kernel bypass to achieve high throughput.
I am trying to understand how the various software (driver, userspace application, etc) should be stacked/connected to each-other so I can achieve the objective of reading and writing to PCIe on the NIC using set of scripts from user space?
I have also been looking at this project
https://github.com/CospanDesign/python-pci
which is useful however based on Xilinx XDMA.
Would appreciate any help, pointers on this.
Sorry, the question is too broad. For such a broad question there is a generic answer: have a look at Inter Process Communication:
https://en.wikipedia.org/wiki/Inter-process_communication
There are variety of methods, like Unix sockets, shared memory, netlink etc, to communicate between user space processes. As well as a variety of methods to communicate between user space and kernel space.
Just pick the best for you and try to do something. If it fails, come again on SO and ask ;)