Mouldking module not working, possibly wrong device address? about espruinodocs HOT 3 OPEN

Hi - not sure what to suggest I'm afraid - the modules themselves do look the same, but the controller is different, so perhaps it's a different protocol. As you can see from the module the code is extremely cryptic, and I only figured out what was needed by disassembling compiled code inside an Android app.

I'm also not sure whether the ESP32 will advertise the data correctly - it should, but I've only tested the module on nRF52-based Espruino boards.

Perhaps as you can scan the bluetooth data, you can see if the data the app is broadcasting is easier to decipher.

Worth noting that if you're using something like NRF.findDevices it'll be aggregating all the services it finds during the scan (it looks like the app is changing the service each time - maybe some of the data is included in that). So probably you want to use NRF.setScan and output each individual packet it finds.

... but there's not much I can really do from this side without hardware to test it on.

also - just moving this to the EspruinoDocs project as that's where the modules are...

from espruinodocs.

Thanks for your reply.

I used the Mould King iOS app and both the "4.0 Module" and "4.0 Module (old)" work for mine:

Are either of these devices ones that you looked at in the disassembled android app?

I have an nRF52840 BLE sniffer, so I will try if I can sniff useful info using Wireshark, but I'm not experienced with this.

from espruinodocs.

Well, you can see in the picture on https://www.espruino.com/LEGO+Power+Functions+Clone the module I tested with - it's the M-0006 kit - it sure looks like the "4.0 Module (old)" is the same one.

Looking again at the disassembled code, the only advertising it ever does is with manufacturerID as 65280 (not services) so it looks like it's just not compatible with the same protocol. In my disassembled version the advertising is set in the BluetoothAdvertiseThread class so maybe if you downloaded the Android app that matches your device, then disassembled it (there are online disassemblers) you might be lucky and find a BluetoothAdvertiseThread class that matches and shows how data is encoded.

Looking at the 'data' in what you posted, there's:

2, 1,  // header, standard bluetooth advertising flags
26,  // flags
27, 3, // header, 16 bit service list
249, 8,  // 16 bit services...
73, 34,  // ...
71, 186, 
196, 188, 
19, 10, 
219, 130, 
101, 177, 
189, 11, 
37, 9, 
125, 210, 
18, 19, 
20, 21, 
22, 23

So it looks like they're just encoding the data as a list of service UUIDs (which is totally not supposed to be allowed in the BLE spec). It's possible they're doing that because you're on iOS and maybe iOS doesn't let you advertise manufacturer data? So it'd be interesting if you have an Android device to see what that advertises instead.

You shouldn't really need the BLE sniffer (although you could use it) - assuming there is no actual BLE connection (it's all done with advertising) you can just use Espruino to keep scanning for advertising packets and dumping as you have been - and see if there are any noticeable patterns when you try and do different things in the app.

If you do something, then return to doing nothing and the advertising data stays the same as it was the last time, there's a good chance it'll be easy to decode (if only by replaying the patterns).

But judging by how my one worked, they went well out of their way to obfuscate the data - so it may be it's not trivial to decode (unless they used the exact same algorithm and just dumped the data in as service data rather than manufacturer data)

from espruinodocs.