1) If I'm understanding the pcap correctly, it's correct and expected that I should see two LMP_encryption_key_size_req packets, one after the other, the first with size 16, and the second with size 1 - because the 16 is never actually sent over the air, it's intercepted and rewritten to 1, and that's what goes over the air. If I'm correct about this, then my question is about the assessment accuracy of the test. Specifically, it treats a system as vulnerable if it sees an LMP_accepted come back, in response to the LMP_encryption_key_size_req. However in [the original writeup]() of the KNOB PoC, it says:
Android (tested only on a Pixel 2): If the target device sends first an LMP_accept
(in response to an LMP_start_encryption_req) and then an LMP_detach message
due to security reasons then the target device is patched against the KNOB attack.
My interpretation of that statement is that even on a patched machine, it is expected to see an LMP_accepted first, and only after that's seen, a patched system may end up tearing down the connection with an LMP_detach. (But that this is vendor-specific behavior, and he's just describing the Android behavior.)
If I'm interpreting this correctly, then isn't it necessary to remove the preemptive teardown in the knob.cpp (the m->stop = 1;), and also add some sort of check for LMP_detach temporarily proximate to the accept? (I don't know how to do that temporally proximate check, otherwise I'd propose a PR. But I did remove the m->stop = 1; so I could just eyeball it.) Because basically as it is right now it seems like it will have some false positives on systems that behave like the mentioned Android.
2) If one removes the m->stop = 1; as above, and lets the connection proceed, one will be seeing encrypted packets after that, right? Is it possible to use the KNOB e0 1-byte-key brute force decryption on the packets stored in the BrakTooth output pcapng file? (I.e. have you ever tried that and succeeded? I'm currently getting an error in the existing decryption tests which I posted about before I can do any tests.)
Aside: I know you don't officially support Ubuntu 22.04 right now, but in order to get the knob.cpp customization to compile there, I had to edit src/ModulesInclude.hpp and change "extern" to "static" under all the "Main API (declarations)", otherwise it would error out.
1) If I'm understanding the pcap correctly, it's correct and expected that I should see two
LMP_encryption_key_size_reqpackets, one after the other, the first with size 16, and the second with size 1 - because the 16 is never actually sent over the air, it's intercepted and rewritten to 1, and that's what goes over the air. If I'm correct about this, then my question is about the assessment accuracy of the test. Specifically, it treats a system as vulnerable if it sees anLMP_acceptedcome back, in response to theLMP_encryption_key_size_req. However in [the original writeup]() of the KNOB PoC, it says:My interpretation of that statement is that even on a patched machine, it is expected to see an LMP_accepted first, and only after that's seen, a patched system may end up tearing down the connection with an LMP_detach. (But that this is vendor-specific behavior, and he's just describing the Android behavior.)
If I'm interpreting this correctly, then isn't it necessary to remove the preemptive teardown in the knob.cpp (the
m->stop = 1;), and also add some sort of check forLMP_detachtemporarily proximate to the accept? (I don't know how to do that temporally proximate check, otherwise I'd propose a PR. But I did remove them->stop = 1;so I could just eyeball it.) Because basically as it is right now it seems like it will have some false positives on systems that behave like the mentioned Android.2) If one removes the
m->stop = 1;as above, and lets the connection proceed, one will be seeing encrypted packets after that, right? Is it possible to use the KNOB e0 1-byte-key brute force decryption on the packets stored in the BrakTooth output pcapng file? (I.e. have you ever tried that and succeeded? I'm currently getting an error in the existing decryption tests which I posted about before I can do any tests.)Aside: I know you don't officially support Ubuntu 22.04 right now, but in order to get the knob.cpp customization to compile there, I had to edit
src/ModulesInclude.hppand change "extern" to "static" under all the "Main API (declarations)", otherwise it would error out.p.s. this tool is good stuff!