So glad it worked out. I want to give it a shot myself. Would you mind pointing me in the right direction on what to do on the software side of things. Don't expect you to do a full on tutorial just for me, but I've never done this kind of things before and are very curious. I plug the USB into my computer and then what? Is this something I can do from the Command Promt in Windows, or do I need to do this in Linux? And what sort of commands am I suppose to use?
Going to be limited to the general case but going with the idea that understanding general principles is good/the way I try to roll rather than copy-pasting a list of arcane commands and hoping it works.
Most things in this sort of world these days are better in Linux but Windows should be able to be slapped hard enough still. You can do it from stock command line (
https://windowsreport.com/telnet-windows-11/ or
https://learn.microsoft.com/en-us/windows/terminal/tutorials/ssh depending upon what goes) but most would instead suggest putty rather than messing around with command line programs if you are new to this all
https://www.chiark.greenend.org.uk/~sgtatham/putty/ . Leave the command line stuff until you are a grizzled sysadmin
https://xkcd.com/705/ or doing some kind of production run/hacking a batch of things.
The video covered the general case. UART/serial debugging is usually designed to be quite simple both as it is a very old concept and designed for simpler devices.
The USB is likely just an adapter and breakout pins to fake an old serial/RS232 port, might need some drivers on Windows (and often enough, even on high end industrial gear, I have had to fight them a bit/go manual to install things). If you have an old computer or certain modern ones with a serial port you could possibly even use that, though that might also need to find a cable/breakout adapter and at that point I would get the USB for either future use if this is something you like (there are rather more protocols to debug/program/sort inter device communication for electronics
http://dangerousprototypes.com/docs/Bus_Pirate ) or resale.
Commands wise there are two general approaches used in devices. In both cases you remote controlling the device via the cable so whatever you are signing in from is largely immaterial.
1) It exposes a standard command line for itself. Here whatever *nix commands it supports (which are unlikely to be all that many, stripping things out of embedded devices like this is common to get sizes/memory footprints down, though usually still including the stock ones to move around directories and copy files which is what you likely care about here --
https://www.unixtutorial.org/basic-unix-commands ) you get to play with.
2) It is its own custom shell/terminal. I typically see this on the weaker devices (I was somewhat surprised in the video linked above that it was not this*) or ones that at least want fig leaf/"we tried" security. Here commands can be completely and utterly custom, though help, manual, obvious commands, commands from similar known devices, dumping binaries and searching strings, hoping autocomplete (in most things this is pressing tab either once or a couple of times) is installed... all viable paths to finding things. Some might also be able to break out of the custom shell into the standard terminal but that is a rather more advanced trick.
*bit old now but one of my favourite videos on hacking in general -- if you ever wanted a distilled version of the hacker mindset in video form then that is one of the better ones I have ever seen/reason I continue to return to it all these years later
dd mentioned above is a rather powerful command in *nix systems that can copy things at file/lower level still from one place to another, and in some cases wipe things out so be sure your source and destination is correct (possibly less of an issue here if various things are read only)
https://www.unixtutorial.org/commands/dd
Also yes if the little device features wifi/networking and a copy of telnet/ssh you can use that in turn to go back to another machine (possibly the one you are controlling from) and round and round it goes, only stopping when someone presses reboot and realises they were signed in to the server running the whole operation (I would say ask me how I know but it is fairly standard new sysadmin hijinks/failure).