Welcome back my Bluetooth rookie hackers! In this tutorial, I am going to write about my findings with the CVE-2017-0785-Android information Leak vulnerability! Please note I did not write the original POC and all props go to the creator. The first POC code was originally located at

https://github.com/ojasookert/CVE-2017-0785 (that I am aware of.)

So let's get rolling!
First off, I have not had any experience messing with Bluetooth exploits before, so I learned a lot of how Bluetooth works during the vulnerabilities that were released by Armis. As a pen tester always in training, it is always a good thing to learn new protocols and explore new exploits and concepts. BTW the technical writeup for Blueborne is located here.


Let's get this popin! So the original code was written to only send 30 packets through the SDP protocol Bluetooth uses. I wondered if I could crank the packet numbers up and see what happens.

Note the original 30 packets in the script below. The original 30 packets dump looks something like this....


I started to crank the packets sending up to 100,200,300 etc, as much as I could, but the Bluetooth module kept crashing on the testing phone around 109 packets sent.

So while messing with the phone in all possible situations, turning Bluetooth off and on again, multiple times , restarting the phone, having Bluetooth and wifi on at the same time (for random reasons) etc, I was able to send up to 7280 packets! The first crash point was 109 packets, and then up to 7281 and crashed again, so I did not successfully go past 7280 packets sent. BUT!, the more packets that were sent the more memory that was dumped. Success!!!!?????


Now at this point, I am wondering if Armis left this information out of the white paper intentionally, if you send more packets to the device you can dump a lot more memory, and in this memory, you will see some interesting things. They say you can find "encryption key, address space and valuable pointers (of code and or data) that can be used to bypass ASLR while exploiting a separate memory corruption vulnerability", so let's see what I found!

In this first screenshot below we can see the words "BNDL(%android bluetooth.device.extra.device!anrdoid.bluetooth.device." and other random words in the little-endian Ascii format.


In this next section, we can see the Ascii in little-endian format of what I assume is a file extension path in Linux/Android. The text reads (/system/priv-app/SamsungVideoPlayer.apk).

In the next screenshot, we can see the strings
"#Test exceptions## Matched towards test casesed finedin iop_bd_test.c##Enforce Master Role
and KETDSADDR="22:22:22:*"22:22:23"*KEY_DIR_ALL="1"# SkipAuthenable KEY _BDADDR="44:44:33:33:11:11"# ".
I am assuming this can be useful as part of exploit code they later use after dumping the memory to start The BNEP (Bluetooth network encapsulation protocol) exploit they demonstrate in the exploit video. Or maybe not, Maybe it's located in another part of the memory offset, I'm not a RE expert........

And last but not least, the phone model number that I was testing on!

We can see in this picture that the phone model Samsung SM-G935a is Asci little-endian format and we can pretty much decode it by eye. Now you have information on the phone you are dumping the memory on! This model number can help you figure out what your targets service carrier is as well! (Good intel to have I'd assume right!?) Cool stuff brahhhhhhhh!

I have also made a script to reverse the ascii from little-endian format to readable information after you dump the memory. You can find the script here


Well, there you have it guys, my testing/findings with the CVE-2017-0785-Android information Leak vulnerability. As you can see there is a lot of information that can be dumped from the memory with this exploit. I am sure this exploit will shed new light on POC's for the exploits that were discovered recently for Bluetooth on Microsoft and Linux systems.

UPDATE 12.2.17

This memory dump is used to get the offset of libc and bluethooth libraries. If you want to read more about it and how it can be used in other phone exploits check out this article.


Happy memory dumping!