caringcaribou / caringcaribou Goto Github PK

Implement a basic CAN fuzzing module. Preferably based on a PRNG which can be seeded via an optional command line argument for repeatability.

What kind of subfeatures could be useful? E.g. fuzzing message contents against certain arbitration IDs / fuzzing the arbitration IDs as well?

Also, can we analyze responses in a generic way?

I'm trying to run DoiP module and it doen't work.
From the Doip.py, there is somes import (import DoipClient and import udsonscan) but the python file corresponding to these import weren't present in the repo.
Is it possible to push again theses files ?
King regards.

executing "./cc.py dcm discovery" searches for diagnostic services by sending TesterPresent to one ArbID at a time. After a successful hit, the module hit reports what arbid replied and what arbid was used in the reply.

The user can continue to search the rest of the adress space using -min flag but to make it even easier for the user a question to the user would be useful "Do you want to continue the search?". Another approach could be to automatically continue the search. If the user only is interested the first result he/she can interrupt the search with ctrl-c

I am testing a device (blackbox testing) and the result from the UDS service enumeration script is giving me 255/255 as the enabled services.

I know in fact that in the device not every service is open. So my guess is that there is some kind of security mechanism checking for the delay between the UDS messages sent consecutively.

Could this be the issue, and if yes, can the feature be implemented in a future update?

List some common issues and solutions.

Example: missing the ~/.canrc file for python-can, as seen in #55

Latest raspberry pi has switched to Device Tree making kernel module install much easier.

http://downloads.raspberrypi.org/raspbian/images/raspbian-2017-07-05/2017-07-05-raspbian-jessie.zip

sudo apt-get update
sudo apt-get upgrade
sudo reboot
Add the overlays by:
sudo nano /boot/config.txt
Add these 3 lines to the end of file:
dtparam=spi=on
dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25
dtoverlay=spi-bcm2835-overlay

sudo /sbin/ip link set can0 up type can bitrate 500000

pip install

git clone

pyhton vsersion: python-2.7

python-can vsersion: python-can (3.1.1)

example:
sudo python cc.py dcm discovery -min 0x700 ()

CARING CARIBOU v0.1

Loaded module 'dcm'

Traceback (most recent call last):
File "cc.py", line 114, in
main()
File "cc.py", line 106, in main
mod.module_main(args.module_args)
File "modules/dcm.py", line 417, in module_main
args.func(args)
File "modules/dcm.py", line 199, in dcm_discovery
with CanActions() as can_wrap:
File "/home/qili/Desktop/AAAAA/caringcaribou/tool/can_actions.py", line 64, in init
self.bus = can.interface.Bus()
File "build/bdist.linux-x86_64/egg/can/interface.py", line 108, in new
File "build/bdist.linux-x86_64/egg/can/util.py", line 197, in load_config
NotImplementedError: Invalid CAN Bus Type - None

I used all the modules, it all prompted NotImplementedError: Invalid CAN Bus Type - None

I tried to install the old version of the python-can module, but still can't solve my problem. Please help me answer, thank you very much. I am very anxious. Thank you!

Usable when creating testfiles or traffic files used in training. Suggest using a standard/existing comment syntax, for instance the '#'. This change would also make it possible for 'dump -f' to add an informative header, if desired

While I was sending a dump file I got a python exception that sleep requested negative delays.
When I searched the output file, I found that the difference between the timestamp of some lines was indeed negative.

For example:

Timestamp: 1541504408.838742        ID: 0191    S          DLC: 7    01 00 10 a1 41 00 1a
Timestamp: 1541504408.838750        ID: 0133    S          DLC: 5    00 00 00 00 b6
Timestamp: 1541504408.838748        ID: 0244    S          DLC: 5    00 00 00 01 44
Timestamp: 1541504408.838758        ID: 0136    S          DLC: 8    00 02 00 00 00 00 00 39
Timestamp: 1541504408.839845        ID: 013a    S          DLC: 8    00 00 00 00 00 00 00 37

Add an optional argument to loop the list of messages passed to the send module.

Some ECUs require messages to be padded to full length (typically 8 bytes), even though the actual payload within the message may be shorter. When performing manual testing against such targets, the user needs to add a bunch of .00 data bytes after the payload to pad the message to the correct length.

It would be nice to have an optional argument which enables automatic padding, so that e.g.
./cc.py send message -pad 0x123#67.89
would automatically be padded to correspond to
./cc.py send message 0x123#67.89.00.00.00.00.00.00
in order to simplify such use cases.

The -index/-i flag in the brute fuzzing method makes it possible to start at a certain index. This lets the user jump to a certain range of interest and also makes it possible to resume a previous session.

Let's add support for this in the random and mutate methods as well!

Implement support for ISO 15765-2, which makes it possible to send data packets of sizes up to 4095 bytes over CAN.

From https://en.wikipedia.org/wiki/ISO_15765-2:

ISO 15765-2, or ISO-TP (Transport Layer), is an international standard for sending data packets over a CAN-Bus. The protocol allows for the transport of messages that exceed the eight byte maximum payload of CAN frames. ISO-TP segments longer messages into multiple frames, adding metadata that allows the interpretation of individual frames and reassembly into a complete message packet by the recipient. It can carry up to 4095 bytes of payload per message packet.

We are currently recommending users to run a python-can version from 2015. Let's make sure that CaringCaribou is compatible with the latest python-can version (currently 2.0.0a2) and update our installation instructions accordingly.

https://github.com/hardbyte/python-can

I just tested a car yesterday, run "python cc.py dcm discovery""

As the car I tested that it will generate periodic can message 0X12D, and msg.data[1]=50, I got almost every airID that support services.

It's normal response after checking the source in the below:

  def response_analyser(msg):
            # Catch both ok and negative response
            if msg.data[1] in [0x50, 0x7F]:
                print("\nFound diagnostics at arbitration ID 0x{0:04x}, "
                      "reply at 0x{1:04x}".format(arb_id, msg.arbitration_id))
                can_wrap.bruteforce_stop()
        return response_analyser

https://antonz.org/python-packaging/

Add a global interface argument to cc.py.

This would simplify global support for switching interfaces (can0, can1, vcan0 etc), without having to add this logic in every separate module.

Add a replay feature for an existing CAN dump, so that pre-defined lists of messages can easily be sent without adding them as command line arguments. This would e.g. be useful for repeatable exploits and automated testing.

It would make sense to add this as a -f <filename> flag to /tool/modules/send.py

Some reasonable input formats are

1. Default /tool/modules/send.py argument format
2. python-can (default dump format for /tool/modules/dump.py)
3. candump (as produced by /tool/modules/dump.py with -c flag).

Currently the cc.py module takes a '-i' argument which is meant to specify the SocketCAN interface (e.g. can0 or vcan0). However, CaringCaribou uses python-can as its CAN abstraction layer enabling support for a variety of device interfaces and drivers.

I propose removing the '-i' flag altogether and let python-can handle whether can0, vcan0, or whatever interface along with its settings is used.

A help message pointing to the python-can docs (https://python-can.readthedocs.io/en/3.1.1/configuration.html) should be included when "cc.py -h" is ran.

Possibly we already have support for this - verify!

The current template has an ineffective way of handling incoming messages through callbacks. Let's update it to a more intuitive, iterative approach.

Ran ./cc.py xcp discovery -min 0x3 towards a target. The discovery got a response on one of the CONNECT attempts, decoded the response and continued searching for more. When the search reached 0x7ff the printout "XCP could not be found: Brute force of range 0x3-0x7ff completed", which indicates failure.

As mentioned in #19 (comment support) - add an informative comment header to files generated with ./cc.py dump -f <filename>.

I apologize in advance that this question isn't specific to this project.

How are tuning manufacturers able to download the EEPROM from the ECU via OBD-II, tune it, then reupload it? For example, do Bosch ECUs have a special proprietary command that is not documented anywhere to send the ECU into a boot mode?

Any information you can share would be helpful.

Update documentation to reflect the blacklisting options added to the DCM module.

Hi,

Is it possible to run caringcaribou on a virtual can bus wihtout the USB-to-CAN device?

Thanks,
Antonio

While running dcm discovery a 0x733/0x633 combo appeared in the result screen. A new discovery started at 0x734 with nostop option detected a 0x7ff/0x633 combo. A bit suspicious since it is the last id before automatic stop of scan (assumption does not support extended id). Needs verification.

All modules should support both Python 2 and Python 3.

The end of life of Python 2 is less than two years away [1]. There is really no need to wait until then to have full Python 3 support. We should of course keep backwards compatibility for Python 2 as well.

[1] https://www.python.org/dev/peps/pep-0373/#maintenance-releases

Is there a reason why the padding is omitted for xcp connect in line:

but not for other xcp subfunctions like the command discovery:

Without padding the ECU receives frames that are not consistently 8 bytes which leads to problems parsing the frame.

Suggested fix: Consistent use of padding and change

to

can_wrap.send_single_message_with_callback([0xff, 0, 0, 0, 0, 0, 0, 0], handle_connect_reply)

No matter what indices are provided, the function always generates length 3.

See pull request for suggested fix:
#64

Hello guys,

A lot of manufacturers start using this implementation. It will be good to see if first of all it is applicable and if we can implement it in the tool. It will be a nice addition.

It would be nice to be able to simply start a mock ECU directly through a separate module for testing, e.g. ./cc.py -i vcan0 mock uds to start a UDS mock ECU on interface vcan0. This could prove useful when playing around, learning new protocols or developing new modules.

Implement a module which analyses randomness of seeds for security access. Data can be gathered by sending a (large) number of Request Seed [0x27 0x01] messages.

What about ECUs which only renew their seed on boot? Maybe a renewal can be triggered by responding to the seed with an invalid key? Any other ideas?

python-can 2.1.0 introduces breaking changes of the flag format when a Message instance is casted to str. Both the old format (consecutive binary flags) and the new format (character flags separated by spaces) must be supported.

The previous commit c29e1f9 only takes care of the case where exactly one flag is set (quick non-breaking fix, but only covers one of multiple cases).

With all due respect, you guys built something amazing, and not maintaining it is simply disgraceful. I feel like I am just going to work off of my fork and not pass upstream, considering nobody here is paying attention. :/ Really sad.

When dumping the CAN bus using the dump module to either a file or just stdout some packets are missing when using python 3.
I tested using a virtual can bus and the ICSim application.

When changing the python interpreter to python 2 all packets are logged but when using python 3 some packets (such as the blinker controls for example) are missed.

Update docs to reflect changes made when adding the send file functionality.

Run dcm subfuc instruction as follows, and got an error:

python cc.py dcm subfunc 0x710 0x77a 0x24 2

CARING CARIBOU v0.1

Loaded module 'dcm'

Starting DCM sub-function discovery

No sub-functions were found

Traceback (most recent call last):
File "cc.py", line 114, in
main()
File "cc.py", line 106, in main
mod.module_main(args.module_args)
File "modules/dcm.py", line 367, in module_main
args.func(args)
File "modules/dcm.py", line 299, in subfunc_discovery
callback_end=finished)
TypeError: bruteforce_data_new() got an unexpected keyword argument 'callback_end'

Hello,

I am currently getting familiar with car hacking and found your tool.

Since I am not an expert in the field I got two questions regarding possible additions to CC.

Would it be an appropriate use case for caringcaribou to add a function to bruteforce the security access key after the seed request?
I also wondered if it makes sense to try all possible values for the security level (related to cc.py uds security_seed) when checking an ECU.

Thanks!

To enable manual testing through 'send'

Add example usage logs to the documentation for all applicable modules.

Same as #7, but for XCP. We need a way to blacklist responses from individual arbitration IDs from command line. It would also be nice with a passive scan for automatic blacklisting before starting the discovery.

It would make sense to add a blacklisting engine to can_actions.py and use this for both DCM and XCP.

Add a module for performing various denial of service (DoS) attacks.

Useful features could include:

• Spam messages with low arbitration ID
• Spam error frames
• Spam ECU reset messages to a certain ECU

Reported by Bill Hass (@bhass1) through a comment to 481fd94

This patch should check for arb_id > 0x7ff (11-bits) instead of 0xffff (16-bits). This will cause unexpected behavior when using CAN IDs between 0x7ff and 0xffff.

Current implementation: https://github.com/CaringCaribou/caringcaribou/blob/master/tool/can_actions.py

if not is_extended:
  is_extended = arb_id > 0xffff

The limit should be changed to ARBITRATION_ID_MAX (which is defined as 0x7FF)

I suggest adding an appended log recorder, like a blackbox with datetimed results and user actions, with an user-setting for "how big" the log should be and trim it if needed. So in case you need to review some data or behaviour not within the session but another day or week even..as far as the log file size is set, in plain human readable text. This might be helpful as it really comes in handy sometimes on my Dataman chip programmer to actually double check if I did program a chip in the past and what data was loaded into.

The imp library which cc.py uses for custom imports has been deprecated.

Let's simply replace it with importlib.

Using dcm subfunction source dest service 1 (with index = 1) actually bruteforces the service-field. Makes no sense since it is part of another argument. Either change the meaning of the index or make 0 and 1 illegal input

The brute force and mutate modes of the fuzzer module let the user specify initial payloads and bit masks for these as separate arguments. Indices with value 0 in the bit mask will be kept as-is from the initial payload, while 1 means the value can be overridden by the fuzzing algorithm.

It would be simpler if the initial payload and bit mask were combined in a single argument. Values in the initial payload that should be overridden could simply be replaced with e.g. a dot and the bit mask could be removed altogether.

That way, the command
./cc.py fuzzer mutate -d 12ab89ef -db 01001100 -i 7fff -ib 0111
would instead be written
./cc.py fuzzer mutate -d 1.ab..ef -i 7...

Just perform some basic tests to make sure everything runs smoothly.