Open wrlu opened 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:
fw_0x6119.py
and dump only the ROM.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
internalblue
folder, which is /root/.internalblue/memdump_BCM4345C0_template.bin
in your case.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
Thanks for your reply ! I will work with my Nexus 5 and BCM20702A1 USB controller at this time.
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.
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.
@jiska2342 is the issue still there now? (being super slow)
@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.
@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 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!
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
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
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 ?
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
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
Additional context
Another BCM20702A1 chip (USB Controller) works ok.