If ChipGenius reports a USBest controller, you have a useful starting point, not a repair in itself. ChipGenius is diagnostic only: it reads and reports what the drive claims about itself, and it does not repair, format, or reflash anything. The safe use of its report is to identify the controller family, confirm the NAND through the Flash ID, and only then decide whether a matching MPTool is even a sensible next step. Recover files BEFORE any reflash. A reflash erases the drive, and a mismatched tool or firmware can brick it permanently.
Recover files BEFORE any reflash. If the drive is still detected at all, copy what you can first, or use a recovery tool such as DMDE to attempt recovery from the drive as it is. Do not run a format, a low-level tool, or an MPTool until the files you care about are safely elsewhere, and keep a second copy of anything irreplaceable. If the drive is not detected, or if recovery finds nothing readable, that itself is information: it pushes the decision toward replacement rather than toward a risky reflash.
What ChipGenius shows for a USBest controller
Run ChipGenius with only the drive in question plugged in, so there is no doubt about which device the report describes. You can get ChipGenius from our download page. The lines that matter most are the vendor and chip part-number lines, the VID and PID, and the Flash ID. Read them together; no single line identifies a drive on its own.
| ChipGenius field | What to look for | Why it matters |
|---|---|---|
| Chip Vendor and Chip Part-Number | USBest and a part such as UT165, UT161, UT163 and other UT16x-series parts | This is the controller identity. It decides which MPTool family could match at all. |
| VID / PID | A VID often reported as 1307 for this family, with a PID that varies by product and brand | VID and PID describe the USB identity the drive presents. They support the controller reading but never prove it alone, because VID values are reused and a PID can be shared across products. |
| Flash ID | A hexadecimal string identifying the NAND flash behind the controller | The Flash ID tells the tool which NAND die it is dealing with. The wrong NAND setting is one of the commonest causes of a bricked or wrong-capacity drive after a reflash. |
| Device name and capacity | The product string and the size the drive reports | A capacity that does not match the shell labelling, or a generic device name on a branded stick, is a warning sign to slow down and verify before trusting any tool. |
USBest controllers are an older and less common family today, which makes identification trickier: many USBest drives are unbranded, documentation is thin, and tool builds for a given UT16x part can be hard to verify. A careful ChipGenius reading matters more here, not less, because guessing is more likely to go wrong.
Why the Flash ID matters more than the brand on the shell
The brand printed on a USB stick describes the seller, not the silicon. Two sticks in identical shells can carry different controllers, and two sticks with the same controller can carry different NAND. The Flash ID is the bridge between the two: it identifies the NAND manufacturer and die, and a correct MPTool configuration must agree with it. If the Flash ID is blank, garbled, or inconsistent with the reported capacity, stop. That pattern often means the drive is failing at a hardware level, or the controller is not communicating with its NAND properly, and no tool selection can fix that from software alone.
Record the full ChipGenius output before you change anything: vendor, part number, VID, PID, Flash ID, and reported capacity.
Which MPTool family matches a USBest controller
For a USBest controller, the matching tool family is the USBest UT16x MPTool family. That is a family name, not a single download: builds differ by controller variant, and a build made for one variant does not automatically suit another. Match on the full part number first, then check that the tool recognises the Flash ID of your drive before allowing any write step. If a tool does not recognise the drive, or recognises it with the wrong capacity, do not force it. Forcing a mismatched tool is how working drives become unrecognised ones.
Do not host or directly link MPTool binaries from untrusted mirrors. Community indexes such as usbdev.ru and flashboot are names you may see when researching, but treat any binary from an unfamiliar source as untrusted, and never run one on a drive holding unrecovered files. If you cannot verify a tool build for your exact part number and Flash ID, stop at diagnosis and replace the drive.
A safe workflow, in order
- Plug in only the drive in question and run ChipGenius. Record vendor, part number, VID, PID, Flash ID, and capacity.
- Recover files before anything destructive. Copy readable files off, or attempt read-only recovery, and verify the copies open.
- Confirm the controller family and the Flash ID agree with a USBest UT16x MPTool build before considering any tool step. If they do not agree, stop.
- Decide honestly whether a reflash is worth the risk. A drive with intermittent detection, disappearing capacity, or write errors is often failing hardware, and no reflash restores worn NAND.
- If you proceed, use the matched tool family only, follow its own prompts, and do not interrupt the process. A power loss or unplug mid-write can brick the drive.
- After any tool step, test the drive properly: full capacity check, a large file copy, and a read-back. A drive that passes a quick format but fails a full write test is not fixed.
What can go wrong
- Assuming an old USBest drive is worth reflashing at all. If the NAND is worn, a reflash only postpones failure and a replacement is the honest fix.
- Using a UT16x tool build for a different UT16x part, which may refuse the drive or write an incompatible configuration.
- Ignoring the Flash ID, which is the only reliable check on which NAND the tool configuration actually describes.
- Reflashing before recovery. Even on an old drive, files that are still readable should be copied off before any erase step.
MPTools can erase all data on the drive, and a mismatched tool or firmware can brick a drive outright. That is not a theoretical warning: a wrong NAND configuration can leave the controller unable to address its own flash, and at that point the drive may stop enumerating entirely. There is no ChipGenius undo for that, because ChipGenius never wrote anything in the first place. This is why the order above is recovery first, identification second, and any write step last, if at all.
When replacement beats repair
Replace, do not repair, when the drive is not detected consistently, when its capacity changes between insertions, when write errors keep returning after a successful-looking format, or when the files on it matter more than the price of a new stick. A replacement also makes sense when the tool build for your exact part number and Flash ID cannot be verified. In that case a new drive such as the SanDisk Ultra Flair is cheaper than the time and risk of forcing an unverified reflash. Back up recovered files to a second location afterwards, so one stick is never the only copy.
Related guides in this Controllers cluster: Phison controller guide, SMI controller guide, Alcor controller guide. Also see our download page for ChipGenius itself.
The point of a ChipGenius reading is to replace guessing with evidence: the part number, the VID pattern, and above all the Flash ID. If those agree with a verified USBest UT16x MPTool build and your files are already safe elsewhere, you can make an informed choice. If any disagree, or your files are not yet safe, stop, recover, or replace.