These are some rough notes regarding the Orvibo Kepler
The Kepler uses a different protocol to the previous devices (S20, AllOne etc.), but once you get past the changes in protocol, the commands are very much the same.
The Kepler uses UDP on port 9999. The header of the packet is the same (e.g. 646400 ..., but the body is now encrypted JSON. The encryption is AES ECB and the decryption key is stored in the app. Simply decompile the app and look in com\orvibo\lib\kepler\core\AESCoder.java. Use something like http://aes.online-domain-tools.com/ to quickly decrypt and check data. The start of the encrypted data is denoted by 0x09 and runs right to the end of the packet (?).
As mentioned above, the protocol is rather similar to the other devices. Here's a sample packet from the Kepler app, showing discovery:
6864004a706be1d7b623202020202020202020202020202020202020202020202020202020202020202009411a140e9dc338948829f770b2e65d3f9c5e7eedfcb9e552aff1a74e7c6ca6
6864 is the "magic word" that identifies this as an Orvibo packet. 004a is the packet length (74). 706b is the data type (pk). Note that this isn't the COMMAND ID, as this is given in the JSON.
Not sure what the rest of the packet is just but, but if you start at 09 and decrypt the rest of that with the key you extracted from the app, you'll get this back:
{"Cmd":"qa","Serial":132528341}
I think serial is a random number to distinguish between a repeated packet and a new packet, but I'm not sure yet.
The "Cmd" seems to match similar commands from the AllOne and S20, such as hb for "hearbeet" [sic] and qa to discover devices.
Hi,
Following your steps I got the key but I did not manage to decode anything yet. I recorded the whole configuration sequence where the device gets the IP (that's the only part of the whole act that seems to be working for me) but I'm not sure anything is encrypted. I also tried with other transactions with the DEFAULT_TCP_HOST (the Chinese IP) which seems to be working (at least I get answers) but if I try decrypting I only get meaningless gibberish.
The most promising part I found in the code is the file CmdManage in
com/orvibo/lib/kepler/core. Indeed all commands needserial. This is what I can infer reading this file:tsis used to change the time zone, if you get a hold on this one you can make a lot of Kickstarters backers happyrkreads the device's hardware and software versionsmnis used to rename the deviceThere seems to be several commands that are not used by the app (they appear in the constant definitions but are never declared later in the code). Those might be more hardware related.
To be honest I think with the low level of functionality offered by my setup trying to reverse engineer the comms would be very difficult. Next week I'll try to spend some time thinking on how to exploit the hardware (that does not seem easy either but I might get an unexpected breakthrough).
Please keep sharing in case I can offer some help.