Reverse engineering tools #291
Replies: 2 comments 1 reply
-
|
I agree, this is a useful technique. In fact, I almost wrote something like this about 5 years ago when I was first writing SavvyCAN. It's still in there as the hidden "Single/Multistate" window. My idea was something similar to your outline. But, I never really completed it. I guess I just went on to other aspects and essentially forgot about it. Well, not forgot but never got back to. I never really sat down to properly map out exactly what it should do and how it should do it. There is some code in there but it isn't really functional at this point. Other aspects of SavvyCAN can be used for similar goals so I never really got to the point where I absolutely needed this old code to work. For instance, you can use the "Range State" window to find a lot of the same things. But, it's much more interactive and relies on visual feedback from the user. So, not really anywhere near the same thing or as easy to use. Anyway, yes, I need to complete the existing code and make it work very much along the lines of what you've outlined. One thing I would like to bring up, though, is that many features in car don't manifest as new IDs but rather new information in existing frames. A particularly nasty example is shifting. Some vehicles send a byte that basically means "nothing is happening" most of the time then send the gear shift signal for 2-3 frames and go back to nothing again. This can be tough find as the ID is regularly sent and the thing you're looking for doesn't even "stick." It's very transient. So, my idea was to accumulate a baseline reading first then have the user do the action a few times and try to see if new bits were set or previously unseen values were suddenly sent. But, some actions do cause new frames. The easiest is probably single wire CAN where it tends to use extended IDs that encode the sender and receiver and thus you really do get a frame when doing a gear shift, lock, unlock, roll down a window, etc. For those types of things (and that type of CAN bus) a scheme where it looks for new IDs would work really well. So, it might be good to support a few different modes or even automatically run all the modes and report findings. |
Beta Was this translation helpful? Give feedback.
-
|
Oh without a doubt that something like this would need to be added onto. The idea behind it is to keep it as simple to use as possible. And that is going to mean some really in depth code in order to have it cover all of the bases. Most can frame will have changing data . so in the first step we only filter out the frames that have had data that is changing. This would cover the issue you just described. and allow the rest of the tool too operate as it should. easy solution. It would be pretty hard for something to accidentally make it past the next 2 steps. The really cool thing about this is that is really is so simple it almost seems like it wouldn't work. But it does. spot on perfect to.... You could even use the same mechanism and make is so that it would walk a user through most of the major systems in a vehicle mapping everything out and then creating a DBC file in the end. setting it up to do an auto discovery of things like steering angle, rpm, speed, IAT, MAP, is also not that hard. most manufacturers have a factor they use and they use it across the board on all the vehicles they make. they may move the bit/byte positions and change the frame id's but the factor will remain the same. So having the user enter the vehicle manufacturer the factor is now known. so for something like RPM tell the user to raise the RPM's to 1500. and then to 2000 and then to drop it back down to 1000 and then back to an idle. for speed tell the user to drive the vehicle at 5 mph for 10 seconds, then stop the car for 10 seconds, then drive at 10mph for 5 seconds and stop the car. have the app black out the screen when they press the start button. and after the time expires and the found frame is reading a 0 then unblack the screen. You can also have it isolate frames that are text. information passed from the radio to the DIC. have the user perform tasks on the radio that displays information on the DIC, the user would have to set the language to English to do this. all that would have to be done from the tool side of things is looking at the frames payload and checking if the majority of the payload is in the ordinal range 32 to 126. |
Beta Was this translation helpful? Give feedback.
-
|
Here is another tool idea. I know you are wanting to add in the ability to directly access an interface. when this gets off the ground there are quite a few fairly inexpensive interfaces that have 2 channels on them. 2 examples are Ginko and CANalyst-II. Another nice feature would be the brute force attack of the OBDII vendor modes. for GM and Ford this is mode $22 and Toyota is mode $21 check every single PIID between 0x0000 and 0xFFFF and capture the replies. the user can then narrow in on a specific PID and monitor it for changes. |
Beta Was this translation helpful? Give feedback.
-
I had mentioned this in an issue but I thought I would also bring it up here and see if others wanted to comment on it or had any ideas.
I have used this type of a system when reverse engineering the CAN BUS in my car.
This tool would be a dialog that the user can open up. There isn't much in the dialog except a test area for messages from the program, and OK/Start/Stop button and a Cancel button. What this would do is it locates the frame for a specific component in a vehicle. This tool works best for isolating frames that get sent on the bust from something the user has done inside of the vehicle. Things like turn signals, headlights, steering wheel buttons. those types of things.
How it works is there would be the dialog with the 2 buttons and a message that reads something to the effect of
The user presses the start button and for 10 seconds the tool records the frame id's of all of the frames that have been received in that 10 seconds.
Next message then comes up when that is finished that instructs the user to press the Start button and activate the device a single time and then press the stop button. When the user presses the start button the program records any frames that do not have a frame id that was captured in the previous step.
Then a message is displayed that instructs the user to press the start button and then activate and deactivate the same device 10 times and then press the stop button. the program is going to record the frames that have a frame id that was recorded in the previous step.
once the stop button has been pressed the tool would then look at the captured frames and it counts the number of frames that have the same frame id. The magic numbers are 10 and 20 frames if the tool located 10 frames that have the same data it will display one of the frames to the user. If there are 20 frames that have been located if the frames have an alternating payload, 10 frames have an identical payload and the other 10 have an identical payload it will display one of each of the frames to the user identifying the bits that have changed.
It then looks for rollling data changes. it will only display a single frame for each payload that is identical and it will identify the bits that are different from any other payloads that were received for that frame id.
The user would have the abillity to select a frame and transmit it. It would also be nice to be able to add it to a DBC file allowing the user to enter a name for the frame (message). have it display all of the bits received and provide the user the ability to select which bits they want to bundle together to make a signal. have fields so the user can enter the name, factor, offset, data type (signed, unsigned, float32 and float64), min and max values once they hit the OK button to add the signal they get prompted for what database they want to put the signal into.
Beta Was this translation helpful? Give feedback.
All reactions