There is a lot of noise about LLMs right now, and a large slice of it is people who never opened the terminal. That is the easy position. I want to take the harder one, because I have put these tools through real work, including reverse engineering things nobody documented, and I have watched them both earn their keep and lie straight to my face.
The model is a tireless second brain on undocumented targets and a confident source of wrong answers, at the same time. The win comes from holding it to ground truth. If you can't tell when it's lying, you'll flash the lie into a device.
01Two kinds of critic
There are two camps and they get lumped together, which is lazy. The first camp uses these tools every day (researchers, people who understand the internals better than the boosters do) and they still have complaints: confident fabrication, the way quality falls off a cliff just outside the training distribution, the economics, the epistemic rot of a tool that is fluent whether or not it is right. Those people are correct. Their complaints are the reason the tools are worth improving.
The second camp saw one bad screenshot in 2023 and decided. That is the camp I am aiming at. Not "if you used it you'd agree with me." Some of the sharpest skeptics have used it plenty. Just: use it seriously before you form a view. Here is what serious use looked like for me.
02The CarPlay adapter
A sealed wireless CarPlay dongle. Allwinner V851S3, 16 MB SPI NOR, no case screws, no visible debug port, no documentation. The goal was a root shell. The model was in the loop the whole way, and this is the honest ledger.
sunxi-tools did not support the chip, so we went to xfel: FEL recovery over USB after shorting the KEY pads into the ROM loader. It spotted that SWUpdate was silently rejecting my repacks because the cpio was 070701 and the device demanded 070702 (newc+CRC), plus 512-byte block padding. And it read the boot scripts closely enough to notice the web UI was overlaid from the customer partition at runtime, so I could patch files without touching the base system.
The plan for the shell was to inject telnetd -p 23 -l /bin/sh & into lyLink.sh. The model was sure. I flashed it. Nothing. Recovery boot loop. We tried again, refined the injection point: same confident suggestion, same silence. It kept proposing the identical broken fix because it had quietly assumed a stock Tina/OpenWrt build.
The assumption was wrong. The base rootfs BusyBox had no telnetd applet compiled in. There was nothing to launch. The model never surfaced that as a possibility; it just kept betting on the happy path.
Not the model getting smarter. Ground truth. I dumped the actual BusyBox, listed the applets, and confirmed telnetd was absent. From there the fix was obvious: bring your own. A static BusyBox with telnetd built in, dropped into the customer partition, launched from lyLink.sh after a short delay so the interface was up first.
root@(none):/# uname -a
Linux (none) 4.9.191 armv7l GNU/Linux
root@(none):/# id
uid=0(root) gid=0(root)03The ChameleonUltra relay
Same texture on a very different target: a standalone BLE relay for ISO 14443-4, DESFire EV3, on the nRF52840. Three moments worth showing.
I asked it to analyse a hf14a sniff capture. It produced a clean, confident, completely wrong decode, because it guessed the frame format instead of reading mine. Only after I pointed it at the actual sniff decoder did it get it: parity-aware, [2-byte BE header][data], ninth-bit parity stripped. The fluency never wavered. The correctness did.
Earlier in the session it suggested raising a relay frame timeout to 10 s to survive a stall. That worked, and then quietly caused repeated-read failures, because the card sat in RS_CARD_AWAIT_RESPONSE for up to ten seconds, so a second read inside that window never forwarded. One fix, one new bug. The model does not hold the whole state machine in its head. Neither do I. That is exactly why you verify.
The real bug: the CARD side was relaying the S(WTX) ACK on to the physical card, corrupting the DESFire session mid-auth. Consume it locally instead: filter (data[0] & 0xF7) == 0xF2, mask the CID bit so both framings are caught, and the round-trip completes. That one it helped nail cleanly, reasoning about protocol state alongside me.
04The honest synthesis
It is not magic. It hallucinates register offsets, invents applets that aren't there, misparses my own wire format, and does all of it with a straight face. Flash that unverified and you brick hardware.
It is also not useless. On a target with no datasheet it is a tireless second brain: it reads the dump, proposes attack paths, writes the boring glue, and now and then sees the thing I missed.
Both are true at once, and the variable that decides which one you get is the operator. These sessions went well because I can tell when it is bluffing and I hold it to the dump, the datasheet, the actual source. A novice running the exact same sessions ships my hallucinated offsets into flash. That is not an argument that the tool is safe. It is an argument that the skill is knowing when to trust it, which is to say, rarely, and always against ground truth.
05The dare
To the serious skeptics: you are right about the failure modes. Keep naming them. That is the pressure that makes the next version less bad.
To everyone dismissing it from a screenshot: open the terminal. Point it at something undocumented. Keep your hand on the wheel and verify every claim against the hardware. Then form a view. A dismissal from someone who never did the work is worth exactly as much as praise from someone who never did either.
I do not trust it. I use it. Those are not in tension: that gap is the whole skill.