Have you experimented with modemmanager/networkmanager to handle the configuration of the modem? For me that has worked quite reliably across a pretty large fleet of devices with a Quectel EG25 (qmi over usb).
Regarding FW updates, have you tried opening a support ticket with Quectel? For me they have been extremely responsive and helpful, providing extra documentation on special AT commands and stuff.
I have not—that was what I was trying (mmcli) early on in my exploration, but I kept hitting speedbumps, so switched gears to configuring the modem over TTY and using QMI utils directly.
I would like to use modemmanager though, it _seems_ like it's the nicer path.
With modemmanager you get a lot of nice stuff for "free", like automatic reconnect, DHCP, good logging, and an APN database (useful if you don't provide your own SIMs). It also allows you to easily set up correct priorities between WiFi and LTE, both for routing and DNS. Especially DNS is something I didn't think about at first, but the DNS server provided by your LTE connection is not always reachable over your WiFi/ethernet connection.
You can run modemmanager in debug mode, which allows you to send AT commands over dbus (or mmcli) in case you still want to configure some stuff manually or get debug info.
In this case the EPS already came stock with the functionality to request torque over CAN, that part of the code or the amount of torque was not touched. I agree it would not be a good idea to patch that functionality into an EPS that doesn't come with that from the factory.
One system I know of had to have software to reduce torque at the end stops or it could destroy FETs and shut down. If this system needed such protection, we might wonder if its included when taking external torque commands. I would if I wrote the code, but you never know when operating outside their expected use cases.
It's also much more benign to destroy components than to have actual bugs. And he's not changing software at the source level.
Ghidra uses an intermediate language called p-code. When defining the CPU opcodes (and how to parse them), you also write a small snippet of p-code that represent that instruction. This makes the decompiler architecture agnostic.
The XOR encryption was just for the update container. Newer update files usually employ some stronger forms of compression/encryption. However, it's usually some strange in-house crypto, so eventually people figure it out.
bri3d refers to using RSA signatures on the firmware once it's written to the flash. By ensuring the firmware is signed using the manufacturers private key it should (in theory) prevent messing with the firmware, even if all encryption/flashing steps have been reverse engineered.
Thanks for the reference! That certainly does look much nicer.
That being said, I do still see some "magical" looking constants and dictionary keys here[1], as well as lots of small numbers later in the file. I think it would be confidence-inspiring to have those better documented as well.
Edit: I found some more magic-looking bytestrings in the Volkswagen support here[2].
At some point the values have no deeper meaning and are just whatever VW decided on as their API. DBC files have concepts of enums, but that’s really diminishing returns and wouldn’t make the code that much easier to understand.
Also sometimes there are fixed values in the message that we’ve only observed as static data. Ironically that makes it impossible to reverse engineer what they mean. So those just have to be labeled as hardcoded value.
Those are actually magic. Those are the ECU firmware identifiers from the manufacturer that are used by openpilot to recognize which car it’s connected to.
The file you referenced is related to Ford, which is not a supported car/brand. The code for Ford is provided as a reference and is forced into “read-only” both by openpilot and panda (the bridge between openpilot and the car).
It's really hard to say but I don't think until the summer or even fall although USCIS could bring it back piecemeal, maybe starting with I-140 petitions and certain visa classifications.
Seems like the https://www.vector.com/int/en/products/products-a-z/hardware... has some similar functionality. I have never used it, but by reading the documentation I'm not sure if it would have been useful here. The frame with ID 65 which needs be overwritten, actually contains 4 different messages indicated by the last byte in the payload. To properly time the modification you need to sync up on that, which the Vector box can't do.
Also price on request, so probably not in the price range of our target audience.
Regarding FW updates, have you tried opening a support ticket with Quectel? For me they have been extremely responsive and helpful, providing extra documentation on special AT commands and stuff.