Closed mugichiya closed 3 years ago
I've been having the same problem with a lot of the CVE PoC scripts. They used to work, but now when I try running them I see the same "...must be a 32-bit dword!" error. Did something change about the pwnlib asm function to make the output no longer correct? I've been troubleshooting all day and I don't know what to do...
Indeed, it's an issue with pwntools
. Using version 4.3.1 it works, but version 4.6.0 breaks it. I added a patch, it should work again. Details below.
Output looked as follows on pwntools
version 4.3.1:
$ python3 CVE_2018_5383_Invalid_Curve_Attack_PoC.py
[*] Found multiple adb devices
[*] Connected to ...
[*] Chip identifier: 0x6109 (003.001.009)
[*] Using fw_0x6109.py
[*] Loaded firmware information for BCM4335C0.
[*] Try to enable debugging on H4 (warning if not supported)...
[*] Writing hooks to 0xd7800...
[*] Installing hook patches...
[*] - Hook public key receive path to replace y-coordinate with zero
[*] patchRom: Choosing next free slot: 113
[*] - Hook public key send path to replace y-coordinate with zero
[*] patchRom: Choosing next free slot: 114
[*] - Hook private key generation function to always produce even private key
[*] patchRom: Choosing next free slot: 115
[*] patchRom: Choosing next free slot: 116
[*] Send HCI_Write_Simple_Pairing_Mode command to force generation of new key pair
[*] Done. The device is now ready.
[*] Steps to verify if another BT device is vulnerable to CVE-2018-5383:
[*] 1. Start InternalBlue CLI for Nexus 5 and activate the LMP monitor.
[*] 2. Pair the Nexus 5 with the other BT device.
[*] 3. If pairing fails with message 'Incorrect PIN', repeat step 2.
[*] If the other device is vulnerable, pairing succeeds with 50% probability.
[*] If the other device is NOT vulnerable, pairing never succeeds.
[*] 4. After pairing was successful, check the LMP capture and verify that
[*] the Nexus 5 sent zero as y-coordinate in the 'encapsulated payload' packet
Afterwards, info patchram
looks as follows:
[*] [113] 0x0002FED8: a7f092fc (bl d7800 <.text+0xa7928>)
[*] [114] 0x00030098: a7f0b3fb (bl d7802 <.text+0xa776a>)
[*] [115] 0x00048EB8: 20a88ef0 (add r0, sp, #128 ; 0x80; Address 0x0000000000048eba is out of bounds.)
[*] [116] 0x00048EBC: a3fc2598 (vcmla.f16 d9, d3, d21, #90)
One can only install 4-byte patches to the Patchrom. The error message means that the pwntools
function asm
created a 6-byte assembly output for a branch instruction, which is wrong for ARM, where a branch instruction is always 4 bytes. The patch address is at not at a 4-byte offset, which is addressed by the Patchrom function by using two slots. Thus, the output for slot 115+116 looks messed up in the example above.
pwntools
seems to compensate for non 4-byte offsets in the latest version by padding with zeros. My patch checks if the assembly input is 6 bytes and if it has 2 leading zeros. If this applies, these zeros are removed. See commit https://github.com/seemoo-lab/internalblue/commit/5460f57275833ec91a12efc5771b8a6ae843d3a9 for details.
I gave it a shot and confirmed that the CVE 19860 and 5383 PoC scripts both work now! Thanks for making the change.
Thanks for testing :) Will close the issue now since my pwnlib workaround seems to work on other machines as well.
Hello. Thank you for creating many PoCs and releasing.
Executing the script on Nexus5(android6_0_1) as follows, it caught a critical log. What should I do? (python2 or 3?)
FYI, I installed internalblue as follows according to
doc/setup.md
and could execute KNOB.py/verifsec