4 ms·

Great article. One thing I’m curious about is the process for interpreting what the raw bytes in each packet mean. Is this just kind a trial and error thing?

Great article. One thing I’m curious about is the process for interpreting what the raw bytes in each packet mean. Is this just kind a trial and error thing? Are there different serialization formats you should look for? Thanks!

wvenable 6y ago
Trial and error. You start with the assumption that the developers are working logically and that they will have chosen the simplest solution. A few of my initial assumptions turned out to be wrong. For example, since I did see some word (16bit) values I assumed all the values would be words. That's probably what I would have done. But that turned out to be incorrect once I started looking at the values (it's a mix of bytes and words).
- shubik22 6y ago
  Interesting, thanks for the reply!
bluGill 6y ago
Mostly it is a matter of making one change to the inputs you control at a time and then seeing what changes. Trial and error, but there typically isn't a lot of error as you quickly see what inputs cause what changes and learn to ignore the other fields. Though if the protocol uses encryption you are probably screwed. If I wanted to figure out the fields he doesn't understand I'd rig up some sort of stepper motor/servo to the pedals so I can precisely control the input, and then start changing things. Go from 0 - 120 rpm in .5 rpm increments, with a change every 15 seconds. Then go from 0 - 60 (or 90) rpm, but over many different accelerations. I used to work for a company that made automotive scan tools and we did this all the time with the automakers official scan tools. Even though the auto makers gave us a lot of documentation, what they did and what the docs say they do is different. (We even had a full time employee who worked at GM's offices with access to GM's source code and rights to pass on the algorithms used: and we still found it valuable to do the above to GM scan tools to work out what they really did)
- shubik22 6y ago
  Got it, changing the inputs is a really clever idea. Thanks for the explanation!

wvenable 6y ago

Trial and error. You start with the assumption that the developers are working logically and that they will have chosen the simplest solution. A few of my initial assumptions turned out to be wrong. For example, since I did see some word (16bit) values I assumed all the values would be words. That's probably what I would have done. But that turned out to be incorrect once I started looking at the values (it's a mix of bytes and words).

shubik22 6y ago
Interesting, thanks for the reply!

bluGill 6y ago

Mostly it is a matter of making one change to the inputs you control at a time and then seeing what changes. Trial and error, but there typically isn't a lot of error as you quickly see what inputs cause what changes and learn to ignore the other fields. Though if the protocol uses encryption you are probably screwed. If I wanted to figure out the fields he doesn't understand I'd rig up some sort of stepper motor/servo to the pedals so I can precisely control the input, and then start changing things. Go from 0 - 120 rpm in .5 rpm increments, with a change every 15 seconds. Then go from 0 - 60 (or 90) rpm, but over many different accelerations. I used to work for a company that made automotive scan tools and we did this all the time with the automakers official scan tools. Even though the auto makers gave us a lot of documentation, what they did and what the docs say they do is different. (We even had a full time employee who worked at GM's offices with access to GM's source code and rights to pass on the algorithms used: and we still found it valuable to do the above to GM scan tools to work out what they really did)

shubik22 6y ago
Got it, changing the inputs is a really clever idea. Thanks for the explanation!