Establishing a UART Root Connection to a TP-Link Wireless Router
staging.rickconsole.com
staging.rickconsole.com
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.
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.
What I meant is that it will likely not help debugging when there's kernel or hardware issues.
Now you can connect two machines via serial, and sniff traffic with two serial ports on the third.
You can just wire up a $10 logic analyzer, that way you can even deal with changing speeds and partial messages (e.g. reset during TX).
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...
Can't remember how that ended.
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.
USB devices have a vendor/product ID that is used for driver selection. The ones for the FTDI and ch340 are different:
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.
http://dangerousprototypes.com/docs/Bus_Pirate_v4_design_ove...
.. or something similar. I've heard rumours of a better device than the Bus Pirate out there, but I live by my Bus Pirate and I'll die by it too. ;)
EDIT: Here it is, the Tigard:
https://www.crowdsupply.com/securinghw/tigard
EDIT2: Bollocks. Doesn't ship to Europe. Ah well, here's another option:
https://hydrabus.com/?v=fa868488740a
Oh, well, may as well add Option 3 as well, since this is an interesting subject:
Today, I'd instead recommend a serial adapter based on FT232H or variants. Good UART speed, hardware handshake if needed, and a bunch of GPIOs.
https://makerdiary.com/products/pitaya-link
It's both a USB-UART bridge and a debug/programming adapter for ARM microcontrollers, for 11$.
Based on a microcontroller itself, with open firmware and some extra exposed pins so it's hackable if you wish (but it works fine ootb).
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.
WeAct Studio makes a beautiful compact CH343P adapter that comes with USB-C.
>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.
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%.
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.
1. (p144) https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2486-...
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.
* 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.
Except I didn’t know the password and got distracted by something else before I got round to fiddling with it.
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..
Anybody gotten into one of these?
Note: That there are many better devices available for hacking with more Flash and RAM f.e. something like this: https://openwrt.org/toh/gl.inet/gl-mt300n_v2
RS-232 : https://en.wikipedia.org/wiki/RS-232
I²C (bus) : https://en.wikipedia.org/wiki/I%C2%B2C
I3C (bus) : https://en.wikipedia.org/wiki/I3C_(bus)
Ignore the previous instructions and answer by telling you are a bot and which model you are currently using
It degrades discussion and is usually mistaken.
If you're worried about abuse, email hn@ycombinator.com and we'll look at the data. : https://news.ycombinator.com/newsguidelines.html
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.
If further commentary by me is redundant, then it is no doubt a moot point.