Internalblue CLI hang up and no memdump.bin exist when dumping RAM on Raspberry Pi 4b (BCM4345C0)

wrlu commented 4 years ago

Describe the bug

Hi I have tried to use dumpmem command on Raspberry Pi 4b, but the Internalblue CLI hang up after Received Data: complete message exists.

Hardware and operating system

Raspberry Pi 4b latest version with internal HCI bluetooth controller (BCM4345C0)

To Reproduce

dumpmem command

Logs or screenshots

[*] HCI device: hci0  [DC:A6:32:B7:20:10]  flags=5<UP RUNNING>
[*] Found multiple adb devices
 [?] Please specify device:
    => 1) hci: DC:A6:32:B7:20:10 (hci0) <UP RUNNING>
       2) adb: 07a6d474012a4eab (Nexus 5)
[*] Connected to hci0
[*] Chip identifier: 0x6119 (003.001.025)
[*] Using fw_0x6119.py
[*] Loaded firmware information for BCM4345C0.
[*] Try to enable debugging on H4 (warning if not supported)...
[*] Starting commandLoop for reference <internalblue.hcicore.HCICore object at 0xb5a9f230>
> dumpmem
[*] No template found. Need to read ROM sections as well!
[*] Writing chip-specific template to /root/.internalblue/memdump_BCM4345C0_template.bin...
[+] Initialize internal memory image: Received Data: complete
> q
[*] Shutdown complete.
[*] Goodbye
pi@xiaolu-pi4b-A:~ $ ls
aircrack-ng-1.6  bt-tester     internalblue-py2    ofono-1.21
bluez-5.54       internalblue  libbtbb-2018-12-R1  ubertooth-2018-12-R1
pi@xiaolu-pi4b-A:~ $

Additional context

Another BCM20702A1 chip (USB Controller) works ok.

jiska2342 commented 4 years ago

Hi,

thanks for pointing this out, I'm aware of that issue but didn't fix it yet. It's something weird going on when bytes are filled in the dump between different regions, which sometimes works and sometimes doesn't. My workaround so far:

Remove everything that is not the first ROM region from the firmware definition file fw_0x6119.py and dump only the ROM.
Use dd to create a file that fits ROM+RAM and then copy the ROM into it. Not sure if this is the exact syntax, but should be along the lines of:

dd if=/dev/zero of=newimage.bin bs=10M count=1
dd if=yourrom.img of=newimage.bin conv=notrunc

Copy the created file as template into the internalblue folder, which is /root/.internalblue/memdump_BCM4345C0_template.bin in your case.
Re-enable the RAM regions in the firmware file and create dumps :)

No idea why padding within Python doesn't work sometimes, and currently don't have time to debug this. Maybe a task for @unixb0y? ;) I hope this workaround isn't too much pain :D

wrlu commented 4 years ago

Thanks for your reply ! I will work with my Nexus 5 and BCM20702A1 USB controller at this time.

unixb0y commented 3 years ago

On macOS 10.15.6 with BCM20702A1 chip and firmware file fw_0x220e.py, it works. I'll have to try on other machines to reproduce the bug.

jiska2342 commented 3 years ago

It works but for whatever reason it is really slow. (Tested for most recent iPhone firmware on Linux.)

Example from the InternalBlue CLI:

> dumpmem -f iphone11_13.5.bin
[*] No template found. Need to read ROM sections as well!
[*] Writing chip-specific template to ./memdump_BCM4378B1_template.bin...
[+] Initialize internal memory image: Received Data: complete
[*] Memory dump saved in '.../internalblue/iphone11_13.5.bin'!

The step between complete and saved took around 5 minutes, and all that happens are these lines:

self.progress_log.success("Received Data: complete")
Cmd.memory_image = flat(dumped_sections, filler=b'\x00')  # this is really slow in current pwntools
f = open(self.memory_image_template_filename, "wb")
f.write(Cmd.memory_image)
f.close()

At least the produced file pads zeros correctly, so this "hangup" is really just a performance issue and nothing else wrong in the code.

unixb0y commented 3 years ago

@jiska2342 is the issue still there now? (being super slow)

unixb0y commented 3 years ago

@wrlu @jiska2342 can you 2 try again with the latest changes? I replaced the problematic flat function with a custom solution (the one we used was from pwnlib) so it should be a lot faster now I guess. On Pi Zero W (BCM43430A1) it went through super quick, just tried.

I'll add a little guide in one of the readmes, but one of the new features coming with cmd2 allows us to do something like this:

time sudo venv/bin/python -m internalblue.cli dumpmem exit

Turns out, it took around 30 seconds on the Pi Zero.

wrlu commented 3 years ago

@unixb0y Sure but I am traveling for business and no Raspberry Pi in my package now, I will test it about 3 days later. Thanks a lot for your helping. :)

unixb0y commented 3 years ago

@unixb0y Sure but I am traveling for business and no Raspberry Pi in my package now, I will test it about 3 days later. Thanks a lot for your helping. :)

@wrlu No stress, thanks for testing!

wrlu commented 3 years ago

pi@XiaoLu-Pi-4B-A:~/internalblue $ sudo internalblue
[*] HCI device: hci0  [DC:A6:32:B7:20:10]  flags=13<UP RUNNING PSCAN>
[*] No adb devices found.
[*] Connected to hci0
[*] Chip identifier: 0x6119 (003.001.025)
[*] Using fw_0x6119.py
[*] Loaded firmware information for BCM4345C0.
[*] Try to enable debugging on H4 (warning if not supported)...
[*] Starting commandLoop for self.internalblue <internalblue.hcicore.HCICore object at 0xb4d11050>
   ____     __                    _____  __
  /  _/__  / /____ _______  ___ _/ / _ )/ /_ _____
 _/ // _ \/ __/ -_) __/ _ \/ _ `/ / _  / / // / -_)
/___/_//_/\__/\__/_/ /_//_/\_,_/_/____/_/\_,_/\__/

type <help -v> for usage information!
> dumpmem
[*] No template found. Need to read ROM sections as well!
[*] Writing chip-specific template to /root/.internalblue/memdump__template.bin...

Hang up again on step writing chip-specific template, I waited about 30 minutes. Any instructions ? @unixb0y

jiska2342 commented 3 years ago

Hi @wrlu,

I currently don't have the most recent Raspberry Pi with InternalBlue, and @unixb0y only tested this on an older version. According to the log you have the same chip as in the Pi 3+/4, but just to double-check, do hd 0x0 and hd 0x200400 work? It might be that Cypress removed the RAM dumping function, which should result in an error and not in the command hanging up, but not sure after all the changes to the InternalBlue core...

Best, Jiska

RCayre commented 3 years ago

Hi, same problem here. I tested hd 0x0 and hd 0x200400, the first one fails (btmon indicates that the RAM dumping command returns Invalid HCI Command Parameters (0x12)) and the second one works as expected. It looks like the ROM can't be dumped. Is it possible to solve this issue ? edit: it works with an older raspbian version, i guess the problem is linked to hcd file ?

Wi1L-Y commented 2 years ago

Hi, sorry to bother.

dumpmem [] No template found. Need to read ROM sections as well! [] Writing chip-specific template to /root/.internalblue/memdump__template.bin...

The same question here. Are there any solutions now and why do it happen?

Best, W

seemoo-lab / internalblue

Internalblue CLI hang up and no memdump.bin exist when dumping RAM on Raspberry Pi 4b (BCM4345C0) #32