Nice article! About the coffee machine toy!
Tristan79 opened this issue · comments
I have a couple of questions:
Looking at the picture on your article "close-up of cluster of WiFi related functions" and your github command list. You listed CMD 0x69 as wifi power? Does that means in the firmware it actually sets more power to the wifi (maybe using a AT command to the esp)? And does that command have a parameter? I got a lot of people complaining, about kettles and coffee machines loosing connection and reseting them to access points. Would be nice to add a feature to have more power to the wifi using iBrew. I knew the command did something :-)
These commands did not show up when I run "ibrew sweep". But are in the firmware? CMD 0x0B and CMD 0x3F.
Since those both return StatusInvalid (0x69). Could I have a copy of the annotated (I can't image, the names where there before in the firmware, like pin_carafe_test) ida files? I can read and write assembler, but I have no experience in IDA. But I want to have a looksee for al the unknown things I encountered, mapping the protocol.
Can if I place a copy of your article, on the ibrew github page? So people can use it as further reference.
Tristan
Hi Tristan,
thanks for reaching out, the annotated IDA DB should be in IDA directory in repo. You are right that 0x69 is setting directly power through AT command of ESP8266 (AT+RFPOWER=) from what I've seen in firmware the maximum value should be 82. And the format of the command is <0x69> <RFPOWER 0-82> <0x7e>. Regarding the frequent disconnection, I believe the ESP8266 and the way how the firmware is done are guilty. I noticed if you DE-AUTH the coffee maker from the network it never comes back online until you reset it, so there is obviously no reconnection logic. I was thinking of creating a patched firmware to solve a few issues. Regarding the article, sure I would be more than happy. Let's stay in touch.
Well, if you want to improve the firmware:
- reconnection logic (iKettle as well :-)
- stronger coffee, people complain about this a lot (including me)
Like (weak, medium, strong) is adjusted to (medium, strong, extra strong). There is probably a loop or timing which can be adjusted when grinding. Or maybe fancier, extra command to adjust (-1,+1) the overal strength of (weak,medium,strong)
-
zero out or scramble the history data from the history command (the phone app uses that to send back your coffee making history) I do not want that leaked. None of their business.
-
extra command to display an image/text on the screen (like an alert)
-
command to make the coffee machine "beep"
I can also tell you which commands are not used/useless/legacy.
If you do definitely choose a version unique enough so I can detect it in iBrew,
If you implement new commands, I will implement them into iBrew.
I assume. If I zeroed out the firmware file, and upload it to my coffee machine. It does not override the update function. But it will brick the coffeemachine, since there is no way to trigger the second bootloader by writing that special thingy to the eeprom? Can you unbrick it with the debug ports and programming interface?
Since I definitely want to play around with the firmware. But not at the cost of an expensive machine I can not unbrick.
If not, should I dump the eeprom when it is in update mode? With that special thingy enabled. I think I have a clip which you can put over de eeprom to read and write to it. So I at least can but it back in update mode? Will that work?
Looking at your photo of the board, I can see the type number in the reflection of the flat-cable of the display (JLX12864G-660), are you sure it is a i2c interface and not a spi serial interface? I can not find any 12864G display module with i2c.
Not really important, but my first thought was just to emulate the hardware using a dev board, display, eeprom, esp and knobs, switches and buttons to emulate the machine on a breadboard. just to be save. But that option is probably a lot of trouble, since I have no experience with st chips, or how to extract bootloaders from it, only esp and avr)
Going to play with ida this weekend. Checking all the unknown commands :-) Very, very happy with the Wifi command. Only a couple of mysteries left!
Also I am going to use your (code/reversed engineered protocol) to build an emulated upload firmware function into iBrew. Which I can test with your code. And then incorporate the update function from your code into iBrew. Which I can test with the emulated firmware function :-) Without the risk of bricking any machine. I definitely will incorporate some hashes on known firmwares for the different machines. And make a triple "are you really sure, you can brick the device?" check such that the user knows it is dangerous if the firmware is not known.
Tristan
Regarding bricking the device, it's safe, there is a special key combo to trigger the update during the bootloader, by pressing Start + Beans simultaneously when powering on. Regarding display, yeah you are right it's SPI, not I2C, I gotta fix it in the diagram. I made an experiment with WiFi set power and it seems to be working:
I implemented the wifi strength in iBrew, and set it at start up to max. Busy implementing the update commands. :-)
Another patch which I could think of is having a much larger value for the hotplate like one hour or more.
now it is in the range of 5..40 minutes (firmware 22). And the last two cups (which is one cup for me) is always cold.
Couple of question:
I can not extract the correct responses from your protocol update description (eg. the picture on your blog). You only describe the sending part.
So i thought I could extract it from your piece of code, but... (see comments in code belowe)
if len(res)==3 and res[2]==0x7E:
major = res[0]
# aargh!!!! status message 0x03 0x?? 0x7E so what is in 0x?? one?
if major==3:
result = res[1]
else:
# aargh!!! no, can not decode... there are multiple input for res[0] & res[1] which makes result == 1
result = res[0]<<4 & res[1]
# aargh the above if statement, either branches could result into 1. Response codes not clear!!!
# Aaarghh!! Need coffee...
if result==1:
...
Do you have a list of the different response codes send by the coffee machine as reply to: the init update, begin update, 256 block write and end update message send? or a pcap file which captures the responses? I implemented half of the protocol now :-)
The last block you send to the device is not 256 bytes but shorter (44 bytes, according to my notes, 256 - (48084 mod 256) = 44 bytes of extra padded zeroos, where 48084 is size of filmware file) and you just padded 0 (which does not affect the crc). Which raises the question how much flash memory is there vs the firmware occupies... maybe there is more room for code? if there is: did you try sending another extra block with code into it?
Maybe there is more room for writing extra code?
- Assuming its 64k memory total
- Assuming the boatloader occupies 0x4000 (16k) due to (0x08004000 vs 0x08000000 starting point)
- Firmware file is 48084 bytes
- unused flash memory 4 blocks extra of 256 bytes extra and the extra zeroos you appended, could fit the game snakes :-)
I notice that the newer versions firmware of the v3 of the kettle and v2 of the coffee machine is the same size. This probably (assumption) means the hardware is the same. Only the software changed.
Did not played with the firmware and ida yet. Found 50 bugs or more in iBrew decided to fix them first :-)
Hi, we can maybe talk directly, to make it a bit faster (on twitter @thinkcz ), regarding the occupied size, you are right there is an extra space at the end, that's actually the space I put the "ransomware" thing for demo. The whole memory is really 64K. About padding by 0, let me check, but I think there is an issue that even though each block has the size in its header, it accepts only blocks of 256 bytes.
Send you an email, I will have a temporary twitter account in a few days for dm.