Reverse engineeren RF protocol

[lemming_nl]

Op het moment ben ik bezig met een poging om een set draadloze energiemeters aan te sluiten op de computer. De set (Voltcraft EnergyCount 3000) bestaat uit draadloze meters en een ontvanger. Deze ontvanger bestaat uit twee chips (blobs, uC en transciever) die via een SPI interface met elkaar praten. Deze interface heb ik afgetapt en wil ik gebruiken om het protocol te achterhalen om later de boel aan te kunnen sturen via de computer.

Het probleem zit hem in het decoderen van de communicatie. Waar ik zover achter gekomen ben:

De transciever wordt eerst ingesteld door de uC door het versturen van een reeks bytes. Deze bytes zijn gegroepeerd in paren. Aan de hand van de configuratiebytes ben ik er nog niet achter gekomen welke chip het kan zijn. Hier ben ik nog mee bezig. De configuratiebytes zijn als volgt: 8282 8283 91AC A0A1 A2A3 8694 9596 97A8 A9BF C0C1 C2C3 9088 BBBC B8B9 BAC4 C5C6 F2F3 FDC7 F8F9 FA92 FC8C AE82 82F4 AD2D 8205. Deze bytes zijn altijd hetzelfde.

Het grote probleem is de data; waar vind ik die? Als ik de data uit de transciever uitlees ontvang ik het data gebaseerd op '5' en op '7'. Waarbij de '5' data ook ontvangen wordt als er geen meters gevonden worden, daar zit dus geen echte data in. De data bestaat uit de volgende mogelijkheden:

0x50 (komt heel vaak voor, opvulling?)
0x51 0x0Y, met Y een waarde tussen 0 and 7. (Octale data?)
0x53 0xF0 (komt af te toe voor, iets van een terminator?)
0x58 (komt in groepen voor, maar niet altijd)
0x5B 0xF0 (terminator denk ik, komt alleen voor na 0x58)

0x70
0x71 0x0Y, met Y een waarde tussen 0 and 7. (Octale data?)
0x73 0xF0 (komt af te toe voor, iets van een terminator?)
0x78 (komt in groepen voor, maar niet altijd)
0x7B 0xF0 (terminator denk ik, komt alleen voor na 0x78)

Ik heb geprobeerd om logica te vinden in de waardes Y. Deze lijken echter compleet willekeurig te zijn. Wanneer ik een meter reset en deze uitlees, hem weer reset en weer uitlees krijg ik compleet andere data.

En nu zit ik vast, hoe ga ik nu verder? Wat kan ik doen om er achter te komen hoe ik met de chips kan communiceren?

[remco_k]

lemming_nl schreef op zondag 06 november 2011 @ 18:40:
0x50 (komt heel vaak voor, opvulling?)
0x51 0x0Y, met Y een waarde tussen 0 and 7. (Octale data?)
0x53 0xF0 (komt af te toe voor, iets van een terminator?)
0x58 (komt in groepen voor, maar niet altijd)
0x5B 0xF0 (terminator denk ik, komt alleen voor na 0x58)

Om te beginnen: hoe log je die data? Hexadecimaal? (daar lijkt het op)
Maar dan kan je natuurlijk NOOIT een 0x0Y krijgen.
Dus je logt niet hexadecimaal. Hoe log je wel?
Wat voor type is het?

Advies: ga hexadecimaal loggen.

[Fish]

remco_k schreef op zondag 06 november 2011 @ 18:43:
[...]

Om te beginnen: hoe log je die data? Hexadecimaal? (daar lijkt het op)
Maar dan kan je natuurlijk NOOIT een 0x0Y krijgen.
Dus je logt niet hexadecimaal. Hoe log je wel?
Wat voor type is het?

Advies: ga hexadecimaal loggen.

lezen ?
met Y een waarde tussen 0 and 7. (Octale data?)

[SA007]

Ik vraag me vooral af waarom je denkt dat het decoderen van de SPI data helpt met het decoderen van de RF data, waarom doe je niet direct de RF data?

Het zou mij sterk verbazen als de data (op de waardes zelf dan) vergelijkbaar is aan die over de SPI bus.

[Sprite_tm]

SA007 schreef op zondag 06 november 2011 @ 19:52:
Ik vraag me vooral af waarom je denkt dat het decoderen van de SPI data helpt met het decoderen van de RF data, waarom doe je niet direct de RF data?

Misschien omdat het handiger is om uit te vogelen wat er verstuurd word voordat het door de RF-chipset gescrambled/moduleert/whatever word? Lijkt me dat een plaintext attack makkelijker is dan 2 layered protocollen te proberen te achterhalen.

Is het misschien een idee om te kijken wat voor chipset onder die blob zit? Probeer eens uit te vogelen wat de frequentie is waarop het geheel uitzend (is vaak aan de antenne wel te zien) en daarna de SPI-commando's naast de chipsets van bekende RF-chip-makers (Chipcon, Nortel, ...) te leggen. Als je een datasheet hebt is het namelijk een stuk makkelijker om uit te vogelen wat die SPI-bytes betekenen

[SA007]

Ow w8, dat had ik gemist, dacht dat spi bus tussen de meetchip en de µC zat, verkeerd gelezen.

De SPI data tussen de µC en de wireless is wel zinnig inderdaad.

Is het trouwens echt een transceiver of alleen een transmitter, dat is natuurlijk een stuk eenvoudiger.

[DaWaN]

Hoe log je de SPI data ?

Ik denk dat het begrijpen van de data veel duidelijker zal worden wanneer je apart logt wat de transceiver in- en uitgaat
Wanneer de microcontroller leest is de kans groot dat hij bogus bytes verzend en daar naar zitten kijken is niet echt zinnig.

De meeste SPI chips zijn van binnen gewoon een stukje geheugen dus als je eenmaal door hebt op welke adressen de TX en de RX buffers zitten zou het opzoeken van de chip vrij eenvoudig moeten zijn.

[Sissors]

Eens met bovenstaande.

Het grote probleem is de data; waar vind ik die? Als ik de data uit de transciever uitlees ontvang ik het data gebaseerd op '5' en op '7'.

En als je hier zegt dat je de data uit de transciever uitleest, wat doe je dan? Lees je het echt zelf uit? En hoe dan? Of bedoel je het aftappen van verkeer tussen uC en transceiver? (En dus niet daadwerkelijk zelf de dat uit de transceiver uitlezen).

Belangrijkste lijkt mij uit te vogelen welke chip het is, of welke familie van chips, en daarvoor is waarschijnlijk makkelijkste om zend/ontvangst register adres uit de data te halen, wat redelijk goed te doen moet zijn, en dan datasheets bladeren. Als je dat hebt kan je al die configuratiedata opzoeken wat het betekend.

[lemming_nl]

Bij gebrek aan een logic analyser gebruik ik een PIC welke aan de SPI interface tussen de transciever en de uC hangt. De output van de PIC is niet aangesloten, en de PIC staat in slave mode. Hiermee kan ik dus de MISO of de MOSI (met de transciever slave, de uC master) uitlezen (maar niet tegelijkertijd). Deze dat wordt vervolgens direct doorgestuurd via RS232 naar mijn PC. De resultaten die ik uitlees heb ik met een scope gecontroleerd.

Het gaat hier naar mijn idee echt om een transciever. Je moet op een knop drukken om nieuwe data op te halen. De led op de meters gaat knipperen en de resultaten verschijnen op het scherm. Dit vereist bidirectionele communicatie.

De MOSI data is constant, de lengte is iedere keer hetzelfde, de MISO data is echter variabel in lengte.

Ik ben datasheets aan het afgaan maar ik heb nog geen match gevonden a.d.v. de configuratiereeks.

[Sissors]

En wat is de MOSI data dan?

Nog handiger zou het zijn om beide te hebben.

[ Voor 52% gewijzigd door Sissors op 06-11-2011 22:50 ]

[lemming_nl]

De eerste 50 bytes zijn constant, voor zowel MOSI als MISO. Deze heb ik hieronder gegeven. De data eindigt altijd op een vaste byte, 82 voor MOSI, 78 voor MISO.

MOSI:

8282 8283 91AC A0A1 A2A3 8694 9596 97A8 A9BF C0C1 C2C3 9088 BBBC B8B9 BAC4 C5C6 F2F3 FDC7 F8F9 FA92 FC8C AE82 82F4 AD2D 8205 0505 ... (af en toe 0500, maar vooral 05) ... 82

MISO:

3804 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 0404 4444 4444 5050 5050 .... (de dingen die ik al eerder besprak) ... 78

[Corn]

Het kan zijn dat de µC de data gegroepeerd in paren verstuurd naar de transceiver, maar dat hoeft niets te zeggen over de relatie van de data; kan gewoon zijn dat de µC het fijn vindt om de data per dubbel 8 bits blokje te versturen door optimalisatie. De µC mag eigenlijk de clock onbeperkt oprekken zonder dat het een probleem wordt voor de slave, dus het kan gewoon iets van code zijn, en niet iets waar je je mee bezig hoeft te houden. Heb je iets van een slave-select of chip-select lijntje gevonden? Daarmee kun je waarschijnlijk in combinatie met een reset uitvogelen wat voor initialisatie command's de transceiver krijgt. Kun je wellicht ook misschien wat mee. Je kunt eventueel ook nog wat rommelen met SPI modes (0 tm 3).

Je MISO lijn is al interessant in ieder geval; lijkt erop dat de µC data naar de transceiver stuurt (44 bytes?) Waarschijnlijk dumpt de transceiver eerst z'n status de lijn op, 0x38. Hij weet namelijk in de eerste byte nog niet wat de microcontroller van 'm wil. Daarna lijkt ie braaf bytes te copy'en oid.

Verder is een echte logic analyzer wel érg handig met dit soort dingen. Zelf gebruik ik sump, dat ding is goedkoop en voldoet eigenlijk wel voor alles.

Tevens om het rijtje van Sprite_tm nog even aan te vullen: HopeRF maakt ook veel epoxy blobs.

[Dmartino]

Het lijkt idd erg op de set die het ook mogelijk maakt om de gemeten apparaten meteen maar uit te schakelen: de Voltcraft energiekostenmeter met op afstand bedienbare stopcontactsensoren- set.
Hiervoor moet tweeweg communicatie mogelijk zijn.
Misschien moet je de mensen in de 433MHz-communicatie met microcontrollers draadje ook even informeren, want deze sets werken ook op die frequentie. Ik denk dat zij er veel van weten, en erg veel interesse hebben om deze set met een arduino de bedienen (ik iig wel).

Met de Voltcraft Cost Control ® 3000 Set kunt u het stroomverbruik vaststellen, zodat u passende maatregelen kunt treffen, zonder dat u installatie-kosten kwijt bent. Bij de Cost Control plaatst u eenvoudig de stekker tussen het stopcontact en de desbetreffende verbruiker. In aanvulling op het actief vermogen in W en de werking in kWh kunt u ook kosten per dag/maand/jaar voorspellen. Met de stopcontacten uit deze set kunt u verbruikers gewoon uitschakelen met de afstandsbediening. Een van de drie stopcontactsensoren is uitgerust met een dimmer functie.
Highlights
•Meet eerst, dan uitschakelen
•Set bestaat uit een energiekostenmeter incl. 2 stopcontactsensoren, 1 stopcontact dimmer en afstandsbediening
Prijs € 24.99

[ Voor 11% gewijzigd door Dmartino op 07-11-2011 11:47 . Reden: info over 433MHz-communicatie met microcontrollers toegevoegd. ]

[DaWaN]

De HopeRF RF70 heeft als Write TX payload wel het commando 0xA0, als je daar precies 1 bit naast zit met je PIC krijg je de waarde 0x50.... Zou dus een goede kandidaat kunnen zijn ?

Edit:
Zoals eerder al vermeld: wat voor antenne wordt er gebruikt ? Dan weet je iig al in wat voor frequentieband je moet zoeken qua transceivers

[ Voor 29% gewijzigd door DaWaN op 07-11-2011 11:56 ]

[Avar]

Kennelijk wordt alle data weggeschreven in EEPROM, en zo te zien is iemand al redelijk ver in het uitpluizen hiervan. Als je dat wegschrijven afluistert dan heb je uiteraard ook wat je wil weten:

http://www.elektronikforu...viewtopic.php?f=3&t=47546

Met Google Translate kom je een heel eind...

[lemming_nl]

De frequentie zou 868Mhz moeten zijn, dus de RF70 valt af.

Avar schreef op maandag 07 november 2011 @ 12:39:
Kennelijk wordt alle data weggeschreven in EEPROM, en zo te zien is iemand al redelijk ver in het uitpluizen hiervan. Als je dat wegschrijven afluistert dan heb je uiteraard ook wat je wil weten:

http://www.elektronikforu...viewtopic.php?f=3&t=47546

Met Google Translate kom je een heel eind...

Zoeken in andere talen heb ik wel geprobeerd (Duits, Frans) maar deze had ik niet gevonden. Het is een andere insteek maar zeker een die de moeite waard is om te bekijken. Wat me wel duidelijk wordt is dat de data niet op een extreem logische manier naar de EEPROM wordt geschreven, dat zelfde zou ook wel eens aan de hand kunnen zijn bij de SPI interface.

DaWaN schreef op maandag 07 november 2011 @ 11:52:
[...] als je daar precies 1 bit naast zit met je PIC krijg je de waarde 0x50.... Zou dus een goede kandidaat kunnen zijn ?

Met een scope heb ik gemeten en wat er uit de PIC komt lijkt te kloppen. Wat mogelijkerwijs niet klopt is het inverteren van de data maar ook met inverse data heb ik nog geen chip kunnen matchen.

-edit-
ik zal zo een scope beeld uploaden

CH1 = CLK, CH2 = MOSI.

-edit2-

Dmartino schreef op maandag 07 november 2011 @ 11:24:
Het lijkt idd erg op de set die het ook mogelijk maakt om de gemeten apparaten meteen maar uit te schakelen: de Voltcraft energiekostenmeter met op afstand bedienbare stopcontactsensoren- set.
Hiervoor moet tweeweg communicatie mogelijk zijn.[...]

Die set bestaat een energiemeter en een set draadloze schakelaars, de schakelaars kunnen niet meten.

Dmartino schreef op maandag 07 november 2011 @ 13:52:
[...]

Je hebt gelijk, verdomd jammer want het leek zo mooi...

Inderdaad, PlugWise heeft dingen die dat doen, maar die zijn gelijk een stuk duurder.

[ Voor 24% gewijzigd door lemming_nl op 07-11-2011 13:54 ]

[Dmartino]

Die set bestaat een energiemeter en een set draadloze schakelaars, de schakelaars kunnen niet meten.

Je hebt gelijk, verdomd jammer want het leek zo mooi...

[lemming_nl]

Blijkbaar werkte mijn uC-code niet optimaal waardoor hij na een paar bytes de mist in ging. Van de site waar Avar naar linkt heb ik een set data gedownload en daarmee mijn uC-code kunnen verbeteren. Het lijkt erop dat er enorm veel onzin ontvangen wordt (30kbits totaal). Echter heb ik nu een aantal sets data waarbij ik consequent de ID van de meter terug kan vinden met daarachter min of meer dezelfde data. Nu nog even uitvogelen wat de data voorstelt.

-edit-

De volgende drie sets data heb ik gedestilleerd uit alles wat ik ontvang, de bovenste getallen zijn zoals ze op het schermpje staan. Daaronder een lange hex string die ik geknipt heb op (naar mijn idee) relevante plekken. Waar de Wh en de hon (hours on) staan in de data weet ik nog niet.

24.6W
86.9Wmax
557.3Wh
144.63hon

5EAA - device id
383B0000D7670000000292A9E6
00F6 - current load
0365 - max load
3136E46642442A2450E301100000000000C018


1.7W
86.9Wmax
557.8Wh
144.87hon

5EAA - device id
3B9C0000DAC80000000292B104
0011 - current load
0365 - max load
31A8D46642442A2450E301100000000000C018


85.7W
86.9Wmax
557.9Wh
144.89hon

5EAA - device id
3BE20000DB0E0000000292B375
0359 - current load
0365 - max load
31CFE46642442A2450E301100000000000C018

[ Voor 46% gewijzigd door lemming_nl op 10-11-2011 22:35 ]

[TheBlasphemer]

Misschien een heel raar idee, maar is het geen idee om uit te vinden met welke pinnetjes die PIC geprogrammeerd wordt, het huidige programma eraf te trekken, en die even door een disassembler te gooien? kun je in ieder geval zien wat constant is en wat niet, en wat bijvoorbeeld meer een CRC check is oid.

[Sissors]

Als ze ook maar een heel klein beetje competent zijn hebben ze dat geblokkeerd, iig op Atmels kan je gewoon het in software uitschakelen, en ik neem aan in PICs ook.

[WVL_KsZeN]

Je totaal Wh en Hon nemen allebei maar erg weinig toe tijdens je metingen. Daarom is het lastig onderscheid te maken tussen wat Wh en Hon data is..

Ik zou eens een meting doen waar je Hon groot is en Wh laag en eentje met juist een lage Hon en een groot verbruik.

(ik heb al je data even doorgenomen, en gek genoeg kan ik nergens een match vinden met je Wh of Hon, en al helemaal niet als ik ga zoeken naar de relatieve of procentuele veranderingen..) maf.

(voorbeeld wat ik bedoel : je Wh neemt in totaal met een factor 1,0010 toe en je Hon met een factor 1,00179. erg weinig verschil, zeker als je de afronding meeneemt... beide factoren kun je ook nergens vinden in de rest van de data. Dat lijkt erop te wijzen dat de tijd niet in bvb seconden wordt opgeslagen, maar als tekstwaarde misschien? (of 144,63 uur = 14463, wat de factoren door de war gooit..))

[ Voor 56% gewijzigd door WVL_KsZeN op 11-11-2011 10:47 ]

[JaWi]

Qua verhoudingsgetallen heb ik wel mogelijk "iets" ontdekt wat iets van tijd suggereert:
0x383b, 0x3b9c & 0x3be2 (= 1e word na device ID) en
0xd767, 0xdac8 & 0xdb0e (= 3e word na device ID)
lopen gelijk op (865 resp 70; het verschil is constant: 40748), wat iets op "hon" lijkt (als je deze omschrijft van uren naar seconden)...

Verder zie ik een zelfde patroon in:
0x2a9e6, 0x2b104 & 0x2b375 vs
0x3136e, 0x31a8d & 0x31cfe;
deze beide getallen lopen ook vrijwel in de pas (1822 resp 625), maar wat dit voor een relatie heeft met de gegeven waarden ben ik nog niet achter...

[ Voor 3% gewijzigd door JaWi op 11-11-2011 13:44 . Reden: 2e patroon klopte niet... ]

[lemming_nl]

Zoiets had ik ook bedacht. Als ik de meter reset dan geeft hij Wh en hon aan als 0.000. Als deze waarden zonder komma opgeslagen worden en in seconden dan... kom ik nog niet uit...

De ontvanger berekend de totale kosten, de kosten per maand en de 'totale hon' (wat dat dan ook mag zijn want naar mijn idee zou dat gelijk moeten zijn aan hon, wat het ook is op het schempje). Hiervoor zijn meer gegevens nodig waarvan ik verwacht dat deze ook meegestuurd worden.

Ik ben iets verder met hoe de data verstuurd wordt. Data komt binnen in twee bytes. Eerst een 0x70 (ik denk als reactie op het commando van de uC om de data te sturen) en daarna de data. De data heeft echter een offset van een nibble. 5EAA3B9C komt binnen als x5,EA,A3,B9,Cx.

Aan het gedrag van de meters leid ik af dat de ontvanger een broadcast doet waarna alle meters binnen bereik reageren. Ook meters waar de ontvanger niets vanaf weet, reageren. Dit is best interessant want dan kunnen er onbeperkt meters aangesloten worden ipv de 9 die de set ondersteunt.

@TheBlasphemer, ik heb geen idee welke uC er in de ontvanger gebruikt wordt, het zou zo maar een of ander obscuur merk kunnen zijn. Er zitten (zover ik kan zien) geen programmeerpinnen aan (geen loze pads ofzo) waardoor ik verwacht dat hij voorgeprogrammeerd geplaatst wordt.

-edit2-
nog een, met wat meer info:

0W
48.3Wmax
62.75Wh
2.054hon
0.018 total cost (ingesteld op 0.3/kWh, te berekenen uit Wh)
3.025 cost/month (dit zou 10083Wh/m zijn)
36.30 cost/year (simpelweg cost/month * 12)
4.541 htot


5F70 - device id
0F57000014A0000000003A789A
0000
01E3
37276000000000000000006000000000001010

Avar schreef op vrijdag 11 november 2011 @ 15:00:
Zou het zo kunnen zijn dat de ontvanger de Wh en hon zelf bij houdt?

Nee, als ik de batterijen uit de ontvanger haal, de contacten kortsluit en vervolgens de batterijen erin stop is hij alles kwijt. Haal ik vervolgens de gegevens op dan weet hij Wh en hon weer.

[ Voor 33% gewijzigd door lemming_nl op 11-11-2011 15:33 ]

[Avar]

Zou het zo kunnen zijn dat de ontvanger de Wh en hon zelf bij houdt?

[WVL_KsZeN]

Als je nou eens je kosten per uur op 0 zet? Zijn er dan waarden die niet meer oplopen en constant blijven?

[Avar]

Nee, als ik de batterijen uit de ontvanger haal, de contacten kortsluit en vervolgens de batterijen erin stop is hij alles kwijt. Haal ik vervolgens de gegevens op dan weet hij Wh en hon weer.

En toch leeg je daar geen EEPROM mee, het zou net zo goed kunnen zijn dat hij dan de 'actieve' zenders kwijt is en na het ophalen dit wel weer weet. Het zou in ieder geval kunnen verklaren waarom je de gegevens niet terug vindt in de overgestuurde data.

[lemming_nl]

Avar schreef op vrijdag 11 november 2011 @ 16:22:
[...]

En toch leeg je daar geen EEPROM mee, het zou net zo goed kunnen zijn dat hij dan de 'actieve' zenders kwijt is en na het ophalen dit wel weer weet. Het zou in ieder geval kunnen verklaren waarom je de gegevens niet terug vindt in de overgestuurde data.

Als ik de ontvanger aan laat staan zonder batterijen in de ontvanger maar met de meter in het stopcontact (en daarna met de ontvanger weer gegevens ophaal) dan loopt de tijd hoor.

WVL_KsZeN schreef op vrijdag 11 november 2011 @ 15:47:
Als je nou eens je kosten per uur op 0 zet? Zijn er dan waarden die niet meer oplopen en constant blijven?

Dat doet niets, die kosten worden dus niet meegestuurd.

Ik heb een meter gereset en vervolgens een aantal keer achter elkaar gemeten en dan kom ik op het volgende uit:

timestamp: 22:23:59.747:
05F70001900000000000000000000000000000000000000000000000000000000000000000030000

0x19 = 0d25

timestamp: 22:24:44.660:
05F70004600000000000000000000000000000000000000000000000000000000000000000030000

0x46 = 0d70

timestamp: 22:24:59.535:
05F70005500000000000000000000000000000000000000000000000000000000000000000030000

0x55 = 0d85

timestamp: 22:27:03.980:
05F7000D200000000000000000000000000000000000000000000000000000000000000000030000

0xD2 = 0d210

Het lijkt er dus op dat de waarde in seconden gemeten wordt. Dit klopt echter niet met de waarden van mijn metingen hierboven. Er zit dus nog ergens een correctiefactor tussen die veranderd wanneer de waarde groter wordt.

-edit-

Voor kleine waarden is onderstaande correct:

11:49:27.892:
5F70 - device id
0113 - time on_tot (s)
0000004C - time on (s)
00000000020122 - Ws
0000 - current load
47F7 - max load
20122 - Ws
000000000000000000000000000000050000 - overig

Voor grotere waarden klopt het niet, in 'overig' moeten dus nog wat correctiefactoren zitten.

[ Voor 9% gewijzigd door lemming_nl op 12-11-2011 16:07 ]

[franssie]

kick - op basis van een SDR oplossing om de meter/zender uit te lezen (en omdat zowel ThinkPad als ik dit topic nog niet kenden) willen we graag een nieuwe poging ondernemen in ThinkPadd in "Data van Conrad EnergyCount 3000 ontvangen (868.3Mhz)"

Daar staat wat links in, o.a. naar deze Code die gebruikt is om het signaal te decoden in combinate met SDR https://github.com/avian2/ec3k

Dus er lijkt toch iets van voortgang te zijn.