search

bluekitchen / raccoon

Raccoon BLE Sniffer
89 stars 30 forks source link

support for new NRF52832 board #5

Closed protobits closed 3 years ago

protobits commented 3 years ago

Hi, I have a NRF52832 Sparkfun breakout board and a NRF52832 MDK. Would like to add support for either of these so that I can use it to sniff the other (maybe the breakout is easier). Could you give me a few pointers on how to port the firmware to these? I have looked at the files for each board and it seem there's some autogenerated header files.

Thanks!

mringwal commented 3 years ago

Sounds good. Which autogenerated header files?

Raccoon basically only uses the UART and if your boards use the same one as e.g. the PCA10040, the firmware should just run as is... if that work, we can just duplicate the 'port' folder.

protobits commented 3 years ago

Sounds good. Which autogenerated header files?

I found this for PCA10040 (which I think would be a good base): https://github.com/bluekitchen/raccoon/blob/master/firmware/nrf/pca10040/config/nrfx_config.h

Raccoon basically only uses the UART and if your boards use the same one as e.g. the PCA10040, the firmware should just run as is... if that work, we can just duplicate the 'port' folder.

Well, the point is that the Sparkfun board does not expose both pins used on PCA10040 as UART so i cannot use that. And for the MDK, it actually has an interface chip (for SWD+UART) so it would be more appropriate to use those. I was actually interested in your project since I initially found nRF Sniffer firmware but it is closed source and they do not support many boards so I cannot redefine these pins for other boards.

So, how what should I do to get any of these boards supported? Should I just copy PCA10040 and look for RX/TX pin definitions?

mringwal commented 3 years ago

Ok, I see. I think we took the nrfx_config.h from the official nRF SDK examples.

Anyway for porting: Raccoon uses Segger's RTT for debug output if DEBUG is enabled in main.c. If you have a J-Link, or can re-use a J-Link from an STM32 dev kit or a Nordic nRF dev kit, it would allow you to check if the sniffer is already working and then look after the UART.

I would suggest to start with a board that is close, e.g. the PCA10040 certainly isn't wrong and update the UART config, probably in the nrfx_config.h.

protobits commented 3 years ago

I don't have a J-Link but I have SWD debugger so maybe I can debug if needed. Anyway, I guess that if I manage to define the correct pins it should work. I found that other board directories have a custom_board.h but not the PCA10040, where the pins are defined (the nrfx_config.h does not seems to be used for that). I'm confused on how this works for this board. I'm not used to how NRF SDK works so I'm a bit lost there.

mringwal commented 3 years ago

The UART is configured here: https://github.com/bluekitchen/raccoon/blob/master/firmware/nrf/transport_uart.c I'm sorry, I don't remember the details. In transport_uart.c there's an include for 'boards.h'. I think there have been defines for different boards and there are the pin definition. On the other hand, Dirk did use the Adafruit BLEFriend, maybe it shows how UART is configured for a custom board.

With an SWD debugger, you can use OpenOCD and gdb on the command line. It definitely works.

protobits commented 3 years ago

I managed to build it (it required a BOARD_CUSTOM define at build time to pick the custom_board.h file, where I placed the pin definitions). However, the raccoon.py seems to hang at:

❯ pyclient/raccoon.py
[+] Config: output trace.pcap (pcap), min rssi -80 dBm

Not really sure what could be wrong.

mringwal commented 3 years ago

Glad firmware compiled with custom definition. The Python client will try to open the serial port, usually with RTS/CTS enabled. If that is not possible RTS/CTS needs to be disabled. After that, it will try to send a command and get a response (I think).

protobits commented 3 years ago

Yeah, I disabled flow control on the header and also and the racoon.py. I tried alternating RX/TX pins and setting another baud rate, but it seems to still hang.

mringwal commented 3 years ago

If the port opens correctly, I'd use a logic analyzer on the UART pins to see what's going on.

protobits commented 3 years ago

Thats a good idea, will try that.

protobits commented 3 years ago

I had a terminal open and it was conflicting :facepalm: I'm now capturing! I will create a PR for the Sparkfun board

mringwal commented 3 years ago

Excellent! Thanks for the PR

Sent from my iPhone

On 21 Aug 2020, at 20:13, Matias N. notifications@github.com wrote:

 Closed #5.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.