[Unsolved]Recover Bricked USB

[Deb-fan]

^CSON = coffee shoot out nose. Lmao ... well said Sir, well said.

OT: Nothing new to add, no proposed approach other than what Sunrat already did and I +1'ed it. Sorry OP, haven't yet come up against such a situation, kinda stinks.

[oddmanout]

Okay all,

So first and foremost, thanks for taking time to respond to my post. Super cool of all of you.

Secondly, the saga has ended. I went down a rabbit hole so deep that I was starting to question my own reality.

Essentially, the firmware on the USB stick got hosed by something stupid that I did. I know it was my fault because I was being careless with the cheap little generic piece of junk. Without being a hardware driver developer, or having some special tools, there's no way for me to recover this thing. I know this because I've tried every other option on the planet and then a few more. Even ended up on some virus-laden Russian websites trying to find tools.

Anyway, the stick never gets activate as a device, so there's really no way to access it. There's no '/dev/*' ID to refer to. Nothing. It's bricked beyond bricked.

For a brief moment I considered getting a "universal programmer" and taking on learning to code HW drivers...but alas I've got too many other projects to worry about at the moment.

Thanks again for the help.

[shep]

There is some Windows only utilities which will restore the firmware.

https://www.teamgroupinc.com/en/support/download.php

Not all manufacturers offer this - perhaps yours does.

I had a team usb drive and was able to restore it. I use usb2.0 drives for flash installers - they cheaper and less finicky.

[Soul Singin']

Time out! Time out! Time out!

Let's all do a quick search for the price of a USB drive. The cheapest I found was 4 USD and the most expensive was 40 USD.

Next, let's compare those prices to the cost of our time. In New York City, the minimum wage is 15 USD per hour.

At that rate, the cheapest USB drive is only worth 16 minutes of our time and the most expensive is only worth 2 hours, 40 minutes.

Now how much time have we spent on this?

[shep]

There is another way to spin the $$$$. I view forums as a repository for information and information has value. The original poster is not the first nor will they be the last to blow away the firmware on a usb3.* drive. If we can get this sorted out and marked [SOLVED], it can help a number of users. The forums efforts would be multiplied by the total number of users who benefit.

[Soul Singin']

There is another way to spin the $$$$. I view forums as a repository for information and information has value. The original poster is not the first nor will they be the last to blow away the firmware on a usb3.* drive. If we can get this sorted out and marked [SOLVED], it can help a number of users. The forums efforts would be multiplied by the total number of users who benefit.

I agree. I really do.

But I also imagine that each case would be different -- different damage, different firmware ... So is a universal solution even possible?

I know very little about hardware, so I would be interested in reading what the experts have to say, just as I have already enjoyed reading their posts in this thread.

[pylkko]

No, a universal solution is highly unlikely. With more expensive devices there are communities out there that do this. For example, for routers, smart watches and so on. But it is almost always the case that the hacked solution is device-specific, even at times you need to know the revision number. You need to find the data sheet and many times do reverse engineering (i.e just put stuff into it in different combinations to see what comes out) and you may need special programmers or cables for it.

I managed to figure out how to dommand the of firmware of an ATWINC 1500 (a WiFi module) so that it does not have an annoying LED on always after it gets a lease from DHCP). Had to read through a 1000 page manual, look at code and guess the pin number that was putting the thing high. Then realized that the one that I had was a later revision and that the pin number had changed. Took several hours... was it worth it? For learning, yes. But other than that, definitely no.

I would buy all my hardware from a single manufacturer if that manufacturer strived to make a many devices as possible with simple, easy to modify and well documented firmware. For some reason, this never becomes a business model for any company, although there are some developments in that direction. For example the Librem 5 smart phone.

[oddmanout]

Since there was so much attention on this, I figured I'd close with a little more information.

Having recently taken the plunge into developing/porting/hacking alternative wireless router firmwares, I've made some realizations that are likely applicable to my dead USB stick. Flash has an MTD layout, like a partition table of sorts, it's deeper than a FS. Usually the first chunk of that has some stored information and firmware for the device. In routers, this also stores a zipped Linux kernel that is loaded into memory upon boot. This would also explain some of the ways that bad actors are able to infect computers with USB flash drives that seem to be clean. The malware is hidden in the part of the USB drive that isn't detectable by normal CLI tools. Anywho, I'm convinced I fubar'd the MTD layout of the USB stick with a 'dd' command and a careless removal from the port while the command was running, I could be off, but I think this guess has potential.

[shep]

I think one of the MTD partitions houses USB3.x firmware.
A thought; I recently needed a larger USB drive for an install and mount/cleaned the drive. Then dd if=/dev/sdX of=team_64_usb_backup.img.
This suggests you could purchase the same exact drive and make a backup image of the new drive. Then flash that image to the bricked drive. This may not work if the Drives have an encoded ID #

[p.H]

This method won't recover anything.
USB sticks are not MTDs. MTDs are bare flash chips accessed directly by the system, commonly found in embedded systems such as routers and smartphones, and require specific handling and filesystems such as YAFFS or UBIFS. USB sticks have an FTL (flash translation layer) controller which interfaces with the flash chips and present the stick as a regular block device. dd won't read or write hidden parts of the flash memory.

[oddmanout]

This method won't recover anything.
USB sticks are not MTDs. MTDs are bare flash chips accessed directly by the system, commonly found in embedded systems such as routers and smartphones, and require specific handling and filesystems such as YAFFS or UBIFS. USB sticks have an FTL (flash translation layer) controller which interfaces with the flash chips and present the stick as a regular block device. dd won't read or write hidden parts of the flash memory.

I stand corrected. However, I think the basic gist is that something very low level was damaged by yours truly. And I don't have the tools or the know-how to correct it.