Gebruikte CRC achterhalen Philips koffiemachine

[bartbh]

In navolging van het andere topic waar ik bezig ben (met het slopen) van mijn Philips 1200 koffiemachine (bartbh in "Philips 1200 + esp8266 - display niet werkend te krijgen") ben ik bezig om een esp8266 in te richten als vervangend scherm voor het koffieapparaat.

Hierbij heb ik gebruik gemaakt van een bestaand github-project om met de machine te communiceren. Hierbij ontvangt de esp8266 de statuscodes van het apparaat om zo te bepalen wat de instellingen (aantal koffiie, water, bonen etc.) van de machine is. Hiervoor kijk ik naar een gedeelte van de statuscode. Probleem is echter dat deze communicatie niet stabiel genoeg is, waardoor er verstoring ontstaat en mijn webinterface op de esp8266 niet altijd de goede status weergeeft.

Nu wil ik de checksum achterhalen om zo te controleren of het ontvangen bericht correct is of niet. Echter is dit voor mij een geheel nieuw gebied en heb ik wat moeite om te achterhalen wat dit precies zou kunnen zijn.

Een aantal goede berichten zijn:

code:

d5550000003800003f07380700000000071d2b
d5550000003800003f07380700000000002437
d555000000380000000738070000000000312c
d5550000003800000007380700000000070830
d5550000003800003807380700000000073707
d5550000003800003807380700000000000e1b
d5550000000700000007380700000000070c22
d555000000070000000738070000000000353e
d5550038000000003f073f0700000000070e11
d5550007070707000000000007000000003232
d555000000030700000000000000000007081a
d5550000070003000000000000000000073c3d
d555000700000000003807000000000007100b

Waar het mis gaat

code:

d5550100000000000000000000000000000626  <- deze klopt, d555501 = machine staat uit
d5554000000000000000000000000000062675  <- deze klopt niet, maar daardoor lijkt het alsof de machine niet uit staat

Hieruit heb ik herleidt dat een bericht altijd begint met d5 55 (header?) en de laatste 4 karakters (2 hex getallen) zouden dan de checksum moeten zijn. Een CRC-16 als ik het goed heb.

Na wat zoek en speurwerk ben ik uiteindelijk uitgekomen op reveng voor het reverse engineren van de checksum. Alleen lukt het mij niet om de gebruikte checksum te achterhalen.

code:

.\reveng.exe -w 16 -s 0038000000003f073f0700000000070e11 000000030700000000000000000007081a 0000000000000000000000003800003816 0000070000000000070000000000071325
C:\temp\reveng-2.1.1\bin\win32\reveng.exe: no models found

Ik heb zowel complete statuscodes, als ook statuscodes zonder de leading d5 en ook zonder d5 55 geprobeerd. Echter het resultaat is stevast "no models found".

Zoek ik in de verkeerde hoek, of zie ik wat anders over het hoofd?

[Matis]

Ik heb een tijd terug ook gekeken of het mogelijk was mijn Saeco uit te lezen via serial. Daarvoor had ik toen een stuk software gevonden.

Ik zal eens kijken of ik dat terug kan vinden.

[Matis]

Ik kan de originele websites welke ik toen gevonden had, niet meer terugvinden. Ik had toen een Saeco (Philips) HD8751.
Echter hierbij wat linkdumps (sommige zijn op hetzelfde artikel gebaseerd, maar bevatten ook weer handige backlinks) Ogenschijnlijk gebaseerd op Jura:

• https://blog.q42.nl/hacking-the-coffee-machine-5802172b17c1/
• https://github.com/Q42/coffeehack
• https://hackaday.com/2019...aking-the-coffee-machine/
• http://protocoljura.wiki-...p/Protocol_to_coffeemaker
• https://hackaday.com/2016/01/28/hacking-a-coffee-machine/
• https://www.instructables.com/IoT-Enabled-Coffee-Machine/
• https://github.com/oliver...ob/master/EEPROM_tool.ino
• https://github.com/psct/sharespresso

Hierbij lijkt het "specifiek" over Philips te gaan:

• https://github.com/OpHaCo/smart_coffee_machine

Leuk project, zo reverse engineering!

[SPee]

Ik zou kijken of het bericht niet in meerdere onderdelen is gesplitst en wat daarvan wordt meegenomen.
Mogelijk door het zelf te berekenen.

Want is de 1e deel d5, d555 of d55500 volgens je eerste lijst?
Maar ook: is het gedeelte tot de checksum 1 geheel of bestaat dat uit meerdere? En wat wordt daarvan meegenomen?

Bijvoorbeeld:

code:

d5550100000000000000000000000000000626

d555
010
00000000000000000000000000006  <-- ?? is dit niet ook opgesplitst?
26

[bartbh]

Het is een hexadecimale weergave van de ontvangen bytes, dus 38 tekens / 19 bytes lang.

Op basis van de kennis die ik nu heb, geven de bytes het volgende weer:

code:

header | s |        message                                        | crc |

d5  55  00  00  00  38  00  00  3f  07  38  07  00  00  00  00  07  1d2b
d5  55  00  00  00  38  00  00  3f  07  38  07  00  00  00  00  00  2437
d5  55  00  38  00  00  00  00  3f  07  3f  07  00  00  00  00  07  0e11
d5  55  00  07  07  07  07  00  00  00  00  00  07  00  00  00  00  323d
d5  55  00  07  00  00  00  00  00  38  07  00  00  00  00  00  07  100b
d5  55  01  00  00  00  00  00  00  00  00  00  00  00  00  00  00  0626

d5  55  01  00  00  00  00  00  00  00  00  00  00  00  00  00  00  06  26
h       o   e   h   c   s   u   b   u   w   a           n   e   r   c   c
e       n   s   o   o   t   n   e   n   a   q           o   r   e   r   r
a       o   s   t   f   e   k   a   k   t   u           w   r   a   c   c
d       f   p   w   f   a   o   n   o   e   a           a   o   d       
        f   r   a   e   m   w   s   w   r   c           t   r   y       
            e   t   e       n       n       l           e               
            s   e                           e           r               
            s   r                           a                           
            o                               n

Dus de header + de verschillende bytes voor de statussen (07/38/3f) zijn duidelijk. Dus ik zou in ieder geval een controle kunnen doen:
0 = d5
1 = 55
2 = 00 / 01
3 t/m 16 = 07/38/3f
17/18 = crc, dus random

Alles wat dit dus niet is, is geen geldig bericht.

@Matis wat ik zo tegen kom in jouw stukken is dat deze code anders in elkaar steekt. De Jura code heeft de volgende indeling: A N : 0 2 CR LF

[Vaan Banaan]

Los van de CRC-code, of wat het ook moet voorstellen, lijkt dit me inderdaad een per byte sequence, met een sync header
11010101 01010101 (hex d555)
en dan per byte een waarde per 3 bits
00000000 = 0x00
00000111 = 0x07
00111000 = 0x38
00111111 = 0x3f
Dat lijkt iets van 0 t/m 3 (of andersom)

Enige uitzondering is dan de aan / uit bit na de header

[Matis]

Vaan Banaan schreef op zaterdag 6 februari 2021 @ 22:13:
Los van de CRC-code, of wat het ook moet voorstellen, lijkt dit me inderdaad een per byte sequence, met een sync header
11010101 01010101 (hex d555)
en dan per byte een waarde per 3 bits
00000000 = 0x00
00000111 = 0x07
00111000 = 0x38
00111111 = 0x3f
Dat lijkt iets van 0 t/m 3 (of andersom)

Enige uitzondering is dan de aan / uit bit na de header

Hebben die 4 waardes iets te maken met de sterkte van de drank? Zijn ze per type drank "mutually exclusive"?

[bartbh]

De vraag van @Matis was aan mij gericht denk ik. Maar met wat ik nu heb ik kunnen achterhalen is een byte in het bericht dus 00/07/38/3f. Ze zijn niet exclusive, want op het moment dat het apparaat klaar is voor input geeft deze "1 koffie 1 espresso 1 water 1 stoom" als statuscode terug.

Daarmee heb ik de (verwachte) checksum helaas nog niet kunnen achterhalen. Wel heb ik nu een aanvullende controle ingebouwd op de inhoud van het bericht.

0 = d5
1 = 55
2 = 00 / 01
3 t/m 16 = 07/38/3f
17/18 = crc, dus random

Daarmee kan ik in ieder geval het grootste deel van eventuele ongeldige berichten eruit filteren. Al het bericht dus niet aan bovenstaande condities voldoet gooi ik het weg en wacht ik op een nieuwe.

Daarmee is mijn probleem ondervangen.

Blijft openstaan dat ik liever de mate van verstoring nog wat wil beperken, zodat ik sneller de juiste berichten binnen krijg. Maar dat staat hier in principe los van.