@lupyuen
Curious too. Willing both to suck it in and to contribute to it.
@lupyuen sdkappble.apk?
@lupyuen Sorry, my brain hit a kernel panic. One of the elf's in that app. I only had 3 errors.
@lupyuen My HumanComs.asm is really buggy today.
@lupyuen I got sdk_app_ble_sync.elf mostly to C code. It would likely not take much work on my end to get it to work. I have the source for the android app that is associated with it. I have no code to submit, I don't know how to github, I learned more about RE as I'm using different tools now. It is much different than malware RE and optimizing binaries that have the DRM trash.
@lupyuen I'm an old man at 29. These college students keep talking about using VMs to RE malware. It's like an elevator full of vibrators. It's funny on many different levels.
@AmpBenzScientist Haha I'm an ancient man at 51! 🙂
Isn't the sdk_app_ble_sync source code here?
https://github.com/bouffalolab/bl_iot_sdk/tree/master/customer_app/sdk_app_ble_sync
@lupyuen I inquired about what was left of the RE effort and I was directed to bl602-re-master as the remaining portion.
@AmpBenzScientist Sorry for the confusion, what we need is actually to reverse engineer the blobs for BLE and WiFi.
Here's what we know so far, we haven't actually decompiled and recompiled the RF stack (which might be based on RivieraWaves)...
https://github.com/pine64/bl602-docs/tree/main/hardware_notes#rf-ip
@lupyuen Thank you sir. Are these libraries that are included in the C code for building an image? I will get to work on this as soon as I find it.
@AmpBenzScientist The WiFi Blob to be reverse-engineered is here...
https://github.com/pine64/bl602-re/tree/master/blobs
Look for libbl602_wifi.a
This is the WiFi library that gets linked into the BL602 Firmware.
I wrote about it here...
https://lupyuen.github.io/articles/pinecone#reverse-engineer-the-bluetooth-le-and-wifi-drivers
@AmpBenzScientist Here's the dump of the WiFi library to assembly...
https://github.com/pine64/bl602-re/tree/master/libbl602_wifi
@lupyuen It's a green light and I'm going Oscar Mike.
@lupyuen it seems as if most of it has been completed. I guess all that remains is to do some simple analysis and then get the code packaged together. I'll talk to the Nuts about this.
@AmpBenzScientist Well the reverse engineering is not quite complete... Let's understand the objective of this reverse engineering...
(1) Ideally we want all code inside BL602 to be open source. We would like to look at all parts of the code that control BL602, tweak it, replace if necessary.
(2) This means we should be able to replace the WiFi and BLE stack inside BL602 with open source ones.
(3) But the WiFi and BLE parts of BL602 are a Black Box right now. Yes we have the API for calling the WiFi and BLE functions. But we don't know how the API actually calls the WiFi and BLE controller. This is the libbl602_wifi.a WiFi Library that we need to reverse engineer: how the WiFi API is implemented.
(4) Then INSIDE the WiFi Controller we have a WiFi Blob. Likely based on RivieraWaves...
https://github.com/pine64/bl602-docs/tree/main/hardware_notes#rf-ip
(5) This WiFi Blob is another Black Box. The WiFi Blob contains some code running inside the controller that does the RF stuff. Not sure if this code is running on RISC-V.
(ESP32 has it's own WiFi Blob that we can't touch either)
(6) Is RivieraWaves code inside libbl602_wifi.a? Not sure, I don't think anybody has checked.
So to say that "BL602 WiFi and BLE" have been reverse engineered, we need to be sure that we understand all the BL602 WiFi and BLE stuff, and possibly overwrite by our own open source version. Right down to the code that controls the RF controller.
@AmpBenzScientist Maybe I should also clarify... Is it really a priority right now to reverse-engineer the BL602 WiFi/BLE stuff?
Well there are already commercial users of the Black Box BL602 WiFi/BLE... Like the MagicHome BL602 WiFi LED Controller.
So we can live perfectly without reverse-engineering the BL602 WiFi and BLE. Unless somebody has an open-source WiFi/BLE stack that they would like to run on BL602. (Which will be substantial porting effort)
Since the BL602 WiFi/BLE is working fine, and people are using it, I'm filling the the docs for the other parts that we don't know how to use: I2C, SPI, ...
That's why I'm not doing anything on WiFi/BLE right now, it's not a priority right now, we got other fires to fight (e.g. LoRa, Rust)
@lupyuen I have to go back and reconfigure something but I'm getting almost perfect C code as a result already. I should write a script and just get the nearly perfect C code. Ghidra is one of the few examples of Java being useful. I have never seen a RE tool this versatile and accurate. It's almost as if the brightest of minds crafted this tool with no real budget limit or limitation of any type.
@lupyuen I'm sorry sir, I don't know anything about this. I only work here.
@lupyuen I think most of the code is already available for the ble portion. I kept seeing UART and other interesting things come up in the code. I'm too tired to continue right now but I will try to find that information and relay it in a Kosher way.
@lupyuen currently doing the disassembly step. Will keep you posted. Maybe I will make a mapping of the code so that it isn't violating any laws but can be used for Clean Room.
@lupyuen I don't have access to internet on the workhorse. Currently working through the blob. I don't have a way to reference the (suspected) code yet but I will check for it.
@lupyuen currently working through wifilib and getting the code for analysis. I'm going to be doing this for a while.
@AmpBenzScientist no worries take your time :-)
@lupyuen I used to RE malware and firmware for fun. This is like putting on socks for me.
@lupyuen 2 of the a blobs done.
@lupyuen All three a types are down.
@AmpBenzScientist that's great!
@lupyuen All three are C now. Just ask about it and it will be my pleasure to answer.
@AmpBenzScientist will you be uploading the files here?
@AmpBenzScientist I'm in the middle of doing Rust and LoRaWAN on BL602 now so sorry I might not have the time to look at them right now. But I'll share them with the BL602 community
@lupyuen I love the idea of Rust but it's not C. LoraWAN is really cool but not really free as in freedom.
@lupyuen Legally I don't know if I can do that. I have the source code rn. Just query my database for information pertaining to GPIO (for example) and I will share what I have found about it.
@AmpBenzScientist yep yep thanks!
@lupyuen BTW the compiled binaries used SiFive GCC 8.5.0 with arch=rv32imfc on a Linux box. The code will take time to analyze as it is now over 25MiB of pure C code.
@lupyuen I really don't have much of a life outside of Research. I can just drown in a ocean of code. No TV, no video games or anything else distracting.
@lupyuen what I did was very easy. I tried to RE the .map but I didn't get far. I assume that I will need to do a good searx search and gather information on this. BTW I didn't use the listed Risc-v type but a three letter version that seemed to be compatible with the BL602. The obscure extensions don't seem to matter.
@AmpBenzScientist
On riscv? Respect. I wanna help. I can give great x86 and decent arm skills.
@AmpBenzScientist you might wanna share your reverse engineered code here: https://github.com/pine64/bl602-re
@AmpBenzScientist haha that's great, what blobs did you reverse engineer?