UART at TTL levels, it's dead-simple and ubiquitous. Everybody should own a USB-to-UART dongle, as it'll be useful more often than not.
I recommend the ones based cp2104 chip. They are cheap ($2 in ebay or aliexpress), reliable and have good support across OSs.
I suggest to avoid ch340. They have low clock accuracy (likely to do with using internal RC osc instead of an external XTAL), which causes corruption and/or dropped character issues both sending and receiving.
I have a bus pirate, and it is sitting on the shelf most of the time.
For serial, I end up using dedicated adapters. Terminal for text, custom python script for binary protocols.
For I2C, I have some USB dongles which appear as /dev/i2c-* devices. Use bash + i2c-tools to debug, then switch to python for more complex stuff.
For unusual protocols, I can use Arduino(clone) directly. Sometimes this needs a trivial interactive handler, like '2' to toggle CS2 line and 'x' to shift in 5 bits.
The problem with BusPirate is that you are not going to integrate it into your device, so whatever scripts you write to it will need to be rewritten for "real" thing. And its interactive mode is pretty limited and you grow out of it very quickly.
I have two of these configurable adapters, too. But i don't use them anymore. I don't have the control programs installed on every machine, i don't remember their settings... in the end of the day i always use the cheap ch340 one because its stateless, because it doesn't have any persistent settings. I grab one from the box and don't get surprises.
Today you are probably better off owning RPi-pico and just bitbanging (or in the rare case when it is needed the PPI comes in handy) the whatever bus you want to interface to in microPython.
For stuff like this (connecting to a router) you really want to have serial adapters. Because it may or may not work, and if it doesn’t work, a bus pirate or raspberry pi pico has a lot more variables to troubleshoot.
I've got a bus pirate, a JTAGulator, and I ordered a Glasgow over two years ago, but it's presently vaporware. I'm out the money and I'll be surprised if it ever arrives.
I used one (an old nokia cable that had been hacked apart) a few years back to get a serial console on my WD Sharespace, so I could figure out how I was going to get debian running on there, interact with the bootloader etc. It was a fun project.
Start with the multimeter, probe for some pins that look like they might be around the right voltages. Next, if you have shell access, cat some data down the port and see if what you think is the TX pin starts to look more alive, then attach your dongle to the likely-looking pins and away you go...
>The allowable baud rate error of CH343 UART receiving signal is less than 2%, the baud rate error of UART transmitting signal is lessthan 1.5%.
They're still bad. Presumably due to the builtin clock (probably RC, not XTAL). There might also be no supersampling.
(A good implementation will be close to 10% tolerance)
>I have not had any problems with the newer CH343.
Most people will indeed not have issues, thanks to short wires and good (as in better than this uart chip) implementations in the other end.
But when interacting with bitbanged uarts (cheap microcontrollers w/o uart hardware) or otherwise clocks divided from video clocks (typical with retrocomputers), bad tolerance will be a problem.
Of course, for some UART bundled in an arduino-style devboard, a ch340 or variant will likely be more than good enough. For an USB to TTL adapter, however, I'd insist on something better, such as cp2104. No reason to compromise when they go for around $2.
I have never seen a UART receiver that has 10% tolerance on the input baud-rate. I don't think it's even possible from a mathematical perspective, at least if you want an error-free transmission.
A standard UART byte consists of (start-bit + 8 bits + parity bit + stop bit), totaling 11 bits for each data byte.
If you were sampling at the ideal location (right in the middle of each bit), then you'd have a maximum of 50% phase-error before you slipped a bit boundary (assuming an infinitely fast rise-time). That means you can accumulate no more than 4.5% phase-error per bit (50% accumulated error / 11 bits).
That corresponds with a 4.5% total frequency mismatch between the transmitter and the receiver. Assuming worst-case corner cases, that's 2.25% maximum allowable error from each. Note that this is the theoretical best-case, assuming your sampling clock is infinitely fast. In practice, (baud-rate x 16) is a common sampling rate - which quantizes your phase-error and gives you even less margin.
And that's why you tend to see UART baud tolerance that's around 1-2%.
It is an interesting problem, and it has of course had some analysis done to it over the years. I particularly like Analog Device's take[0].
Note that the standard UART byte (8N1) has 10 bits (1 start + 8 data + 1 stop). Use of parity is not at all common. To accumulate 50% you need to be 5% off per-bit.
This is the naive approach, with a single sample in the middle of the bit. Super-sampling and clever clock recovery tricks can get you much better tolerance. An example such as the +4.58/-4.54 on the whole message even older atmega8[1] achieve. They are not even chips designed to be dedicated to UART. This is pretty good, while still working bit by bit.
A strong implementation can go considerably further by super-sampling the whole message, and sampling past the expected end. By super sampling the whole message and an extra bit, you can get to that 10%, or tolerance of clock being off by a whole bit.
ch340 and variants likely do not supersample at all, in addition to using a poor (not xtal oscillator) clock source, and that's why they do that poorly.
Also, I remember the "FTDI-gate" with the ch340, where FTDI updated their driver to break ch340 clones (that are nearly ubiquitous and sometimes indistinguishable).
While ch340 are a dirt cheap solution (the chip is cheap, and it is a single chip solution thanks to the internal oscillator), it is not a FTDI clone.
It presents its own interface to the computer and uses its own drivers.
What FTDI did was specifically targeted against fake FTDI chips. Note that this is no less horrible; FTDI has no business intentionally bricking anybody's chips.
They claimed they were targeting counterfeit FTDI chips. But in reality they have no way of telling the difference between a counterfeit and a clone in software - after all the only difference is what is written on the IC package/what the seller claims it to be.
CH430 is not an FTDI clone as far as I can tell, so i'm not sure how this is relevant?
If you want existing drivers to "just work" with your clone device[1] then you need to return a vendor and product id it already recognizes. Lying to a computer does not make you a counterfeiter (and copying responses verbatim for interoperability purposes is pretty strongly protected, see e.g. Sega v. Accolade)
[1]: After all the whole point of making an FTDI clone instead of just implementing the standard USB communications device class was to get Windows support before Windows 10 introduced support for serial via CDC out-of-the-box.
Outputting text on a serial port that's directly available as io ports or mmio is of course trivial.
Unless I'm missing something important, there's no such mechanism for usb-ttl dongles.
I'd much sooner trust netconsole than the whole usb stack, as sending an UDP packet while bypassing the whole network stack is surprisingly trivial. Just poke some registers. No interrupts needed.
They tend to show up as ttys and be easily usable to get a linux login console after the kernel has booted. You're not going to be using them to interact with (say) the u-boot bootloader on an embedded board, but if your machine has disappeared off the network and you're pretty sure the kernel is at least booting, you can sometimes use one of these to figure out wtf has gone wrong.
Just poking some registers to send an Ethernet frame kind of hand-waves all of the ACPI table lookup, AML parsing, PCIe root/bridge init, etc, so in that regard "mov dx,0x3f8 ; out dx,al" is more simple and reliable - USB needs all of the same PCI/PCIe stack also so is of course a nightmare :)
Kinda weird article, the firmware mod and serial console are essentially completely unrelated. And in this case having console access did not really gain anything, he probably could gave grabbed the passwd from the firmware image much easier.
My understanding is that he was more like exploring the ways to his objective to set up some sort of "backdoor". Discovering that shell gave only the read-only access to fs, he went on the fw modding way.
Almost there, should he not put that <h1> before <head>... Good old HTML!
I was thinking of maybe doing a write-up of how I reverse engineered my Fireplace controller's UART using a sniffer cable and two USB-to-UART dongles.
I've documented my findings here: https://bonaparte.readthedocs.io/en/latest/system_informatio...
But I thought maybe a write-up of how to approach a project like this would be beneficial for beginners, like I was when I started this project a few months ago.
I'd love to hear feedback from people more knowledgeable than me on this. I was struggling especially with finding and using the accurate terminology to describe things like packet (or is it message?) formats and such.
Well yes, but the article doesn't say (that I saw) if that applies to the network interface(s) as well. If it's only once you've opened the case, soldered on headers, and hooked up your TTL2USB UART adapter, I don't think it's anything particularly worrying. It's a domestic wireless wi-fi router after all, not Fort Knox' vault door. Perhaps I'm being naive.
From the article it seems like there are two separate things:
* root shell accessible using UART header -> this is more or less fine as you said. Because at that point you might as well solder wires to intercept communication between RAM and CPU, unsolder flash memory chip containing firmware and connect it to a dedicated reader/writer, or possibly use the CPU debug port. It would be a bit more difficult than using serial connection over UART, but not different from the perspective of overall security model. Note that a physical serial port with shell access is not the same as SSH.
* SSH server listening on ??? network interfaces. Using the UART shell author was able to recover admin password, which might be usable for connecting using SSH over network. But it wasn't really confirmed whether the SSH server is configured to accept passwords and on which network interfaces is it listening. If the SSH server is really accepting hard coded password and listening on all interfaces by default then it's very bad. But the article after getting admin password jumped to completely unrelated stuff of modifying firmware downloaded from manufacturers website and uploaded using the firmware update feature in web interface.
I needed to get the PPPoE account off a router once (My boss didn't remember the router's admin password), so I connected the WAN port to my laptop and captured the PPPoE packets. I might have had to use a second ethernet port (USB hub with eth port) to allow the old router to talk to the telcom modem. Just bridge the two ports and capture the traffic.
Interesting. My house came with one of those awful GE fridges that uses RFID tags to make you change your filter, or it will stop making ice and dispensing water. It also makes you buy "genuine" $60 filters rather than generic $15 filters.
I pulled the board, hoping to be able to hack into it, and it has what looks like a USB TTL header on the left side of this image:
https://postimg.cc/Yvv5XMS9/9837bd66
However, the pins are labeled GND, RST, TOOL, (blank) (blank) 5VDC. I haven't tried anything yet, since the prospect of my food spoiling while I fool around is not attractive to me..
Wow, reading that I've checked a new IoT device I'm working on and turns out it had dropbear running as root by default. Couple this with our policy of not discouraging tinkering and hackers (it served us well with different devices) and it was passwordless account (simple rs232ttl dongle connected to exposed header gives you root, pretty useful for anyone with access to hardware) so anyone with a port scanner could go in. Dropbear also by default advertises on mDNS. One IoT device now fixed, thanks to this article.
I'm curious, a few of your comments are lists of $thing: $link - often without context or any explanation, so is there some form of automation going on here?
Additionally, while the tone of the original comment was a little cheeky, I think if they wanted to downvote and say (and I'm interpreting what they wanted to say from the tone, not making any accusations personally) "These are low-quality, low-effort comments that I think are bot-driven" they wouldn't be terribly unjustified in doing so.
First time hearing about I3C, its not that common yet. Much faster, parity/CRC protected and they got rid of clock stretching, very nice. Did they also finally solve the hung bus problem?
I recommend the ones based cp2104 chip. They are cheap ($2 in ebay or aliexpress), reliable and have good support across OSs.
I suggest to avoid ch340. They have low clock accuracy (likely to do with using internal RC osc instead of an external XTAL), which causes corruption and/or dropped character issues both sending and receiving.