MacOS Big Sur 11.2.3
MacBook Pro 15' Mid 2015
External disk: Samsung T5 SSD 2TB
I've installed smartmontools and DriveDX
I've installed the kernel driver as described here: https://binaryfruit.com/drivedx/usb-drive-support
With smartmontools and DriveDX I can successfully get data from a Maxtor HDD and a WD Element HDD, so I think, drivers are good, and the procedure of attaching the external drives after a reboot works.
Still can't get SMART data from the Samsung T5.
The only hypothesis is that the T5 has an enclosure that doesn't support SMART technology, but I've seen reviews of the disk which included SMART reports.
Anything I can try?
This could be a long journey, hold on tight.
As this SMART reading is based on SATSMART driver, I would say there is something bad with driver to device part.
I suggest you to diagnose it with IORegistryExplorer: find your T5 device and check, whether there is a fi_dungeon_driver_IOSATDriver in the device tree.
If it is there, which I would say is less possible, I have a bad news: you will need to debug the driver and try to find, what is going on there during data exchange, why it can't retreive SMART data from the device. This is a complicated process with a lot of places for you to shoot in the leg.
However I think the problem starts earlier, the driver is not matched to the T5 device.
To keep long story short: matching is a process, when the system decides, what driver is a proper for a new device. What you will need to do to match SATSMART driver to your Samsung T5, is to add its record to Info.plist of the driver in the same format, like:
<key>Samsung T5</key>
<dict>
<key>PassThroughMode</key>
<string>YOUR_DEVICE_PASSTHROUGH_MODE</string>
<key>YOUR_DEVICE_PID</key>
<integer>24626</integer>
<key>idVendor</key>
<integer>YOUR_DEVICE_VID</integer>
</dict>
Here the PID and VID is a product and vendor ids, there are a lot ways to find such from your device, including IORegistryExplorer.
The YOUR_DEVICE_PASSTHROUGH_MODE is more complicated, it seems that there is no public info about usb bridge type used there, so I advice to try different values, starting from sat16 and jmicron.
After you changed the Info.plist you will need to build the driver. There would be a plenty errors because of old macro used: you could use the unmerged pull request to solve them.
In the end, you should get the kext with your modifications.
To test it with your macOS you will need either to sign it with driver signature or to disable SIP on your mac.
After the testing, if it works, you could use it as is, or write a mail to binaryfruit.com and ask them to integrate your findings to their product :)
Based on the specification (https://www.samsung.com/semiconductor/minisite/ssd/product/portable/t5/), T5 has USB 3.1 interface to communicate with PC. Internal SSD module of T5 has M.2 form factor. See https://www.youtube.com/watch?v=A6WQOQ-bEtQ. Your guess is correct - there is interposer in-between USB <-> M.2. Your external T5 Drive may not be recognized as SATA or NVMe device while your HDDs do (most likely as SATA). In such case obtaining SMART data can be a problem. Try to use Vendor tool at T5 web link mentioned before (Section "Download Files"). There is also Mac version. May be this tool can shows the SMART correctly.
Related
I have a client issue that I am working on with a stack of SSD drives and a machine that they were previously installed in. As of now, the stack of drives shows up in a few Operating Systems (Win10, Win7, Mac OSX) as an unpartitioned raw space. I am looking for a simple way to examine the drive and see if it is actually raw, or just formatted for ZFS.
Does anyone know of a Windows or Mac Utility that could help? I've tried a few recovery software programs, that hinted at being compatible with ZFS formatted drives, but have yet to see anything that would indicate if it was actually a ZFS, or simply not formatted.
Regards,
Ed
ZFS is storing at the start and at the end of each device a magic number, 0x00bab10c ("oobabloc", i.e. überblock), reversed for little-endian: 0x0cb1ba00.
So if this number doesn't appear in the device data, you can be sure it isn't used by ZFS. If it does appear, you need to investigate a little further.
For details, have a look to the ZFS on disk specification draft available here, especially page 13.
I received a direct marketing USB stick on the mail the other day. As soon as I inserted it into my test-Mac - it opened Safari and wrote in the address of a website it wanted to visit. It had the exact same behaviour on my test PC.
Now, I was under the assumption that OSX didn't have an autorun feature. I'm running 10.10.3 and I can't even find the device under disk utility.
Any ideas on how they are doing this? The only thing I can think of is that it's piggybacking on a helper service, but I've never used any products from this company before.
How can I investigate the contents of the USB if I can't find it on my mac?
I can't even find the device under disk utility.
That is beacause it is not a disk device, but a USB HID "keyboard". The stick sends the key codes that will open the website automatically.
I wonder if anyone can help at all, a bit of a specialist problem this.
I have an application that needs to read and analyse a number of USB devices (not simultaneously, they are each run in seperate tests and could in theory be run on different machines).
Each of the USB devices is based on the USB HID class, and are manufactured by different companies, none of these USB devices are designed to be run on PC, but are meant for a different platform, however for the purposes of testing the devices the client has requested that the test application is run from a PC.
Some of the devices will start up, be recognised by windows which will initialise and start them correctly using the generic HID class driver built into windows, the devices will then start sending correct data packets of the data to be tested.
Some of the devices will start up, be recognised by windows which will try to start them but fail to fully to initialise them leaving them in a half initialised state. This is fine, as I can use my beagle protocol analyser to capture the initialisation packets from the genuine platform and then use the LibUSBDotNet library to replicate the remaining packets in the initialisation sequence and get them to start sending the packets correctly.
The problem I have is with one particular device (though there are some more I haven't tested yet so it's quite possible one of those may also exhibit the same problem). The issue is the the Windows HID class driver recognises the device and trys to initialise and start it, this works after a fashion and the device starts sending data.
The problem is that the data being sent is different to that which is sent to the genuine platform (containing only a subset of the full data). It's as though windows has initialised the device into a different mode.
When I capture the initialisation packets from both the PC and the genuine platform using my USB protocol analyser I see that Windows is sending some slightly different initialisation packets. Using LibUSBDotNet to resend the correct packets once Windows has already started the device seems to have no effect.
My problem is that I need to stop windows from trying to initialise the device using the standard HID class driver, I've tried removing the driver in Device Manager but it still initialises it (and the driver is magically reassigned in device manager). I've done some investigation and there are possible alternatives:
Create a specific driver which windows will assign to the particular VID/PID of the device but that does nothing, then I can use LibUSBDotNet to send the correct initialisation sequence to the device from within my own code.
Use something like WinUSB to create a proper driver for the device (or possibly to create a "dead" driver like 1.
Will a driver with a specific VID/PID defined be used by windows in preference to it's inbuilt USB HID class driver? If not then I would be wasting my time going down this route?
Note, my mac initialises the problem device correctly, and I've asked the question of the client whether the application can be developed for Mac and their answer was frustrating Windows only.
I've no experience in writing proper Windows drivers, though I have experience in talking to USB at a relatively low level (so that part doesn't worry too much). Can anyone suggest a good course of action (before I potentially waste weeks investigating how to write drivers for the PC only to find my selected course of action can't deliver what I required).
Any help or suggest much appreciated.
Thanks,
Rich
Added after trying suggestions below:
I tried using the LibUsbDotNet inf wizard to create the necessary files and install them and this appeared to work - certainly the device was now appearing in Device Manager as a libusb-win32 device - not HID device and the associated driver was libusb driver. Even after doing this the device still seems to become initialised and start sending the wrong type of data packets although now those packets are no longer handled by the class driver and are just lost.
I also came across Zadig which has a similar inf creation wizard for WinUSB and this had exactly the same result.
A colleague has suggested that it might not be windows itself that is switching the device into this mode, rather the device identifying that it is connected to a windows machine and switching itself into this mode. I suspect this is the case, in which case I am stuck - time to have another conversation with the client.
Many thanks for the help.
You're using libusb-win32 as a filter driver; that is, the HidUsb device driver is assigned and loaded for your device, but then the libusb-win32 driver is loaded on top and gives you unobstructed access to the hardware.
If you don't want a HidUsb (or any other class driver) to perform any communication "on your behalf", simply associate libusb-win32 as a device driver with your hardware. For this, you'd have to create an .INF file associating it with the VID/PID/Revision of each USB device. If I recall correctly, libusb-win32 even comes with a utility to generate such .INF files.
If you install this .INF file e.g. with PnpUtil.exe (available on Vista or higher), you might still run into issues where, although you're a better match than the generic HID driver, the HID driver is still selected.
The generic HID driver matches devices by their Compatible IDs (i.e. by a USB interface class) while you'd be matching by Hardware IDs (which have higher priority). However, Windows might give priority to other aspects, such as your driver being unsigned. Read: How Windows Selects Drivers
Luckily, even in that scenario, signing drivers with a self-generated certificate (use CertUtil.exe, MakeCat.exe and SignTool.exe) is not too difficult.
I have one USB stick having FAT32 type file system.I really in need to dump and analyze that file system in the usb stick in windows or in linux platform.
My ultimate aim is to read the usb's hardware( ,type and manufacturer) information by reading that dump file.
You will not find the information you are looking for in the file system, those are embedded in the chip and are transmitted when the device gets plugged in. You will find all details in the device manager if you look up the details of the device.
Regarding your comment: It is irrelevant for the OS what the actual filesystem is, as the controller on the device controls the access to the actual flash memory. If the controller says that there are only 400mb to be accessed, you can only access 400mb. You either got a faulty stick or it's a fraud, you probably should check with the origin of it (ie. where you bought it). Sometimes, you can flash the device's firmware, for that the information you get in the device manager is enough. However, at most times, you are out of luck - return the stick if you can in that case.
there seem to be more and more questions that are answered by "why do you want to do that" instead of real information. Strange.
Here is an answer:
Don't use Windows. Use Linux, plug in the stick, and use 'dd' to dump partitions from the stick to files.
Cheers.
I am writing a UMDF sensor driver for a device that connects to the system via Bluetooth and is accessible as an HID input device. I saw the "Sensor Development Kit" sample driver and noticed that it works with the Freescale hardware via HID also though it connects to the system via USB. Is there any difference in the way the UMDF driver communicates with the device in case it connects to the system via Bluetooth? For some reason, I find that the call to CreateWdfFile returns ERROR_INVALID_FUNCTION even when I have the device paired with the system. I am able to access the device directly via HID just fine.
In the INF for the driver I have specified the hardware ID like so - HID\VID_1234&PID_5678 (haven't used the actual IDs here). Is this sufficient for the UMDF framework to determine which driver it should use further down the stack? Or is there something else that one needs to do?
I managed to resolve this one myself. Turns out I wasn't using the correct hardware ID. On a whim I looked up what hardware IDs the bluetooth device had been registered with under HKLM\SYSTEM\CurrentControlSet\Enum\HID and used another ID that had been given there and voila! - IWDFDevice::CreateWdfFile worked! :) And sure enough, this is described quite clearly on MSDN here. So, all's good!