TCP data ontcijferen Goodwe zonnepanelen omvormer

[ThinkPad]

Ik heb een omvormer voor mijn zonnepanelen van het merk Goodwe, type GW3000-XS.
Deze heeft een wifi-dongle waarmee hij elke minuut zijn data naar het Goodwe moederschip stuurt. Als je een account bij ze aanmaakt en je omvormer koppelt (serienummer + 'check code' van 6 cijfers invoeren) dan kun je je opwek en andere waardes (temperatuur omvormer e.d.) inzien.

Natuurlijk wil ik dit liever lokaal ook kunnen uitlezen zodat ik niet afhankelijk ben van de fabrikant en omdat het gewoon interessant is. Ik heb het verkeer van de omvormer een poos gelogd met Wireshark. Elke minuut wordt er via TCP data verstuurd naar tcp.goodwe-power.com op poort 20001.

Nu ben ik niet de eerste die hier mee bezig is. Op deze blog heeft iemand de data al eens uitgepluisd. En op Tweakers is er iemand die dit script heeft gemaakt.

Helaas is het protocol in de tussentijd schijnbaar gewijzigd/versleuteld, want ik vind de waardes van mijn omvormer niet terug in de capture data als ik een export van de portal ernaast houd (geprobeerd om een aantal waardes zoals Pac, temp, bedrijfsuren om te zetten naar hex en daar op te zoeken in de dump).
Bij de omvormers waar het blog/script over is geschreven ging het naar een andere URL en via poort 80 ipv 20001.

Ik heb hier een Wireshark capture online gezet (op de plek van XXXXXX stond het serienummer van de omvormer). En hier de Excel export vanuit de portal om ernaast te kunnen leggen.

Iemand tips hoe ik dit kan reverse engineeren? Is het wellicht 'versleuteld' met die 'check code' waar ik het eerder over had?

[Voor 4% gewijzigd door ThinkPad op 22-02-2021 13:05]

[Mr. HTTP]

Met deze repo was je al bekend of zeg ik nou iets doms? Laat maar ik zie je al als contributor staan.

Heb je al een 'social hack' gedaan?
M.a.w. contact opgenomen met GoodWe of developers van GoodWe (via LinkedIn)?

GoodWe (Netherlands)
Franciscusdreef 42C,
3565AC Utrecht, the Netherlands
T: [phone]
[e-mail]
[e-mail]

via

Niet geschoten is altijd mis

[Voor 88% gewijzigd door Mr. HTTP op 08-02-2021 00:27]

[ThinkPad]

De Nederlandse support heb ik al eens contact mee gehad voor een ander issue (firmware update van andere omvormer), ging vrij stroef. Heb nu een mail gestuurd naar het algemene wereldwijde support adres. Maar ik verwacht er niet teveel van eigenlijk. Via LinkedIn ook gezocht en wel o.a. een software engineer gevonden, maar geen mogelijkheid om hem/haar te kunnen contacten.

Ik hoop eigenlijk dat iemand mij op weg kan helpen hoe ik de Wireshark data moet analyseren, doordat iemand er een patroon/versleuteling-/husselmethode o.i.d. in weet te herkennen.

[Voor 19% gewijzigd door ThinkPad op 08-02-2021 09:09]

[RobIII]

ThinkPadd schreef op maandag 8 februari 2021 @ 09:06:
Ik hoop eigenlijk dat iemand mij op weg kan helpen hoe ik de Wireshark data moet analyseren, doordat iemand er een patroon/versleuteling-/husselmethode o.i.d. in weet te herkennen.

Ik snap dat je de data (deels) anonimiseert ('sanitized') maar in het geval dat je op zoek bent naar hoe iets 'versleuteld' is wil je die data eigenlijk zo origineel mogelijk laten. Wat nou als je serienummer een rol speelt bijvoorbeeld? (Niet dat ik zeg dat 't zo is, ik heb nog nooit iets met omvormerdata gedaan).

[No13]

Probleempje bij de goodwe omvormers is dat het serial + de 6 cijferige code alles is dat je nodig hebt om een "plant" over te nemen in je account

[ThinkPad]

RobIII schreef op maandag 8 februari 2021 @ 09:37:
[...]

Ik snap dat je de data (deels) anonimiseert ('sanitized') maar in het geval dat je op zoek bent naar hoe iets 'versleuteld' is wil je die data eigenlijk zo origineel mogelijk laten. Wat nou als je serienummer een rol speelt bijvoorbeeld? (Niet dat ik zeg dat 't zo is, ik heb nog nooit iets met omvormerdata gedaan).

Helemaal mee eens hoor. Maar in dit geval is het serienummer vrij gevoelige informatie omdat je daarmee (+nog een andere code) de omvormer aan je account kan hangen. Daarnaast zou het ook gelijk mijn identiteit onthullen bij de fabrikant, dat hoeft van mij ook niet zo nodig.

[RobIII]

No13 schreef op maandag 8 februari 2021 @ 09:39:
Probleempje bij de goodwe omvormers is dat het serial + de 6 cijferige code alles is dat je nodig hebt om een "plant" over te nemen in je account

Tja, daar doe je weinig aan...

[Mr. HTTP]

ThinkPadd schreef op maandag 8 februari 2021 @ 09:06:
De Nederlandse support heb ik al eens contact mee gehad voor een ander issue (firmware update van andere omvormer), ging vrij stroef. Heb nu een mail gestuurd naar het algemene wereldwijde support adres.
Maar ik verwacht er niet teveel van eigenlijk.

Iedereen bellen en e-mailen waarbij je iemands taak (zoals support) respecteert. Je moet support niet lastig vallen met diepe tech vragen maar gewoon kort uitleggen waar je tegenaan loopt (zelf je data uit kunnen lezen zonder GW server) en of ze je bericht intern willen doorsturen naar iemand met meer verstand ervan.

Via LinkedIn ook gezocht en wel o.a. een software engineer gevonden, maar geen mogelijkheid om hem/haar te kunnen contacten.

Kan je via LinkedIn geen berichten sturen dan? Verder kun je altijd het e-mailadres patroon proberen te achterhalen van GoodWe en koud emailen. Dus Jantje Klaas heeft bijvoorbeeld [e-mail]

Ik hoop eigenlijk dat iemand mij op weg kan helpen hoe ik de Wireshark data moet analyseren, doordat iemand er een patroon/versleuteling-/husselmethode o.i.d. in weet te herkennen.

Deze kennis is niet zo eenvoudig over te brengen natuurlijk. Ik heb de data even ingeladen in WireShark en er zitten wel duidelijke TCP messaging patronen in: POSTGW header, data fields met leading NULL byte (zodat je de lengte kan achterhalen per field) en daarna waarschijnlijk een versleuteld data field.

Serieuze analyse doe ik liever op onaangetaste data en met de sleutels (serienummer, check code) tot mijn beschikking zodat ik ook echt wat decrypt tests zou kunnen doen.


UPDATE:
Je kunt ook eens kijken of je de firmware kan uitlezen/decompilen voor meer inzicht in het communicatieprotocol..

[Voor 3% gewijzigd door Mr. HTTP op 08-02-2021 13:50]

[The Eagle]

Misschien een hele voro de hand liggende opmerking, maar wat als je met een netcat commando de datastream van die omvormer uitleest? Dan zou je volgens mij gewoon de ruwe data moeten krijgen. Worth a shot lijkt me

[Mr. HTTP]

The Eagle schreef op maandag 8 februari 2021 @ 13:58:
Misschien een hele voro de hand liggende opmerking, maar wat als je met een netcat commando de datastream van die omvormer uitleest? Dan zou je volgens mij gewoon de ruwe data moeten krijgen. Worth a shot lijkt me

TS heeft toch een Wireshark capture gemaakt...

[ThinkPad]

Mr. HTTP schreef op maandag 8 februari 2021 @ 13:48:
[...]

Iedereen bellen en e-mailen waarbij je iemands taak (zoals support) respecteert. Je moet support niet lastig vallen met diepe tech vragen maar gewoon kort uitleggen waar je tegenaan loopt (zelf je data uit kunnen lezen zonder GW server) en of ze je bericht intern willen doorsturen naar iemand met meer verstand ervan.
[...]

Goodwe is een Chinees bedrijf, ik ga niet random nummers van medewerkers in China bellen

Kan je via LinkedIn geen berichten sturen dan? Verder kun je altijd het e-mailadres patroon proberen te achterhalen van GoodWe en koud emailen. Dus Jantje Klaas heeft bijvoorbeeld [e-mail]

Normaal wel, maar van de twee software engineers die ik vond staat de functie om ze een bericht te kunnen sturen uit. Heb nu geprobeerd om het mailadres te raden en heb een bericht (Engels + Chinees) naar die twee gemaild. Ben benieuwd

Deze kennis is niet zo eenvoudig over te brengen natuurlijk. Ik heb de data even ingeladen in WireShark en er zitten wel duidelijke TCP messaging patronen in: POSTGW header, data fields met leading NULL byte (zodat je de lengte kan achterhalen per field) en daarna waarschijnlijk een versleuteld data field.

Serieuze analyse doe ik liever op onaangetaste data en met de sleutels (serienummer, check code) tot mijn beschikking zodat ik ook echt wat decrypt tests zou kunnen doen.

Snap ik, maar die sleutels ga ik niet aan een wildvreemde op internet geven helaas
Het serienummer ziet er als volgt uit: x3000SSxaaaWxxxx
x = geen idee
3000 = vermogen van de omvormer, 3kW
aaa = vermoedelijk het bouwjaar+maand van de omvormer, als ik kijk naar een andere Goodwe omvormer (e.g. 181 = januari 2018 ?)
De W mogelijk dat het een model met wifi-module betreft

Het SSID wat de omvormer zelf uitzend heet 'Solar-WiFixxxxxxxx' waarbij de xxxxxxxx de laatste 8 karakters van het serienummer zijn. Deze module is overigens een serial naar TCP bridge is al uitgevonden, dus daar kom ik ook niet verder mee. Het verkeer wordt in de omvormer zelf al gecompressed/versleuteld. Anders kon ik het verkeer tussen omvormer en de wifi-module afluisteren. Maar dat is dus al gedaan door @No13 en dan zie je dus dezelfde data als in de Wireshark capture. Dat bevestigd dus dat de wifi-module zelf gewoon een doorgeefluik is.

UPDATE:
Je kunt ook eens kijken of je de firmware kan uitlezen/decompilen voor meer inzicht in het communicatieprotocol..

De firmware is helaas niet publiekelijk te downloaden. Heb voor een andere omvormer van ze wel de files gekregen zodat ik via USB kon updaten. Maar dat betrof een ouder model met een ander type wifi-module. Daar heb ik voor dit project dus niks aan. Deze omvormer heeft geen USB dus ik zou ook niet weten hoe je hem van buitenaf zou moeten programmeren. Normaal is het zo dat je een support request kunt inschieten en dan kunnen ze het updaten vanaf afstand doen. Maar zonder goede reden doen ze dat ook niet zomaar.

[Voor 18% gewijzigd door ThinkPad op 08-02-2021 14:58]

[raxon]

Wellicht is het zipped, als je het unzipped wat zie je dan?

[Mr. HTTP]

raxon schreef op maandag 8 februari 2021 @ 21:31:
Wellicht is het zipped, als je het unzipped wat zie je dan?

De magic numbers van het gzip en zip formaat heeft het iig niet.

[The Eagle]

Mr. HTTP schreef op maandag 8 februari 2021 @ 14:03:
[...]

TS heeft toch een Wireshark capture gemaakt...

Jawel, maar das een wireshark capture en daar moet je (denk ik) nog een hoop headers uitslopen. Netcat pen je zo naar file, kun je daemonizen etc.
En hij moet de waarde omzetten naar hex om te zoeken zegt ie..dan liever in text houden en gewoon regel voor regel opslaan lijkt me

Iig benieuwd naar de netcat output

[ThinkPad]

Ik heb nog even flink lopen zoeken, wat mij opvalt is dat e.e.a. wel overeen lijkt te komen met hoe een omvormer van het merk 'Omnik' kan worden uitgelezen.

Als ik de app 'SolarGo' van Goodwe opstart, dan doet deze een UDP broadcast op poort 48899 met de waarde WIFIKIT-214028-READ en vervolgens wordt mijn omvormer/de wifi-module ook gevonden. Het is dus niet alleen éénrichtingsverkeer richting het moederschip. Helaas kan ik hem niet uitlezen (app ondersteund hem niet, alleen voor omvormers zonder display zegt ie). Maar geeft dus wel aan dat die poort 48899 een mogelijke invalshoek is. Dit terwijl nmap deze niet vond.

Ook de app 'SolarMan' van Omnik geïnstalleerd en die lokaal laten zoeken. Ook die doet een broadcast naar UDP 48899 met precies diezelfde waarde. Ik ben heel benieuwd of deze mijn omvormer ook vind, maar kan dat nu helaas niet testen (zonder daglicht is de omvormer uit). Ik had eigenlijk gehoopt dat die Goodwe app de data lokaal kon uitlezen, in dat geval kon ik mij richten op het reverse engineeren van die app. Misschien dat het uitlezen met de Omnik app wel lukt

Heb nu verder gezocht op die waarde die ik hierboven noemde. Die wordt ook wel gebruikt in slimme lampen e.d. Ik vond ook nog deze interessante blog: https://www.secura.com/nl...ckle-down-vulnerabilities (let op, ik heb een HF-LPB100 wifi-module, ietsje anders dan waarover ze op dat blog schrijven).

Ik wil morgen zodra het weer licht is eerst eens dit proberen: https://github.com/XtheOne/Inverter-Data-Logger Die heeft twee mogelijkheden: connecten naar de omvormer door een soort 'magic packet' te sturen naar 8899 / 48899, of als luisterend oor optreden wanneer je het verkeer van je omvormer erheen leid.

Nog meer interessant leesvoer: https://github.com/XtheOn...lopment/Communication.txt
Opbouw van het 'magic packet': https://github.com/Woutrr...aster/OmnikExport.py#L145

Ik ben heel benieuwd of het morgen gaat lukken!

De discussie over netcat volg ik niet helemaal. Ik waardeer het meedenken, maar zie niet helemaal in wat mij dat meer gaat vertellen dan wat er al in die Wireshark dump staat.

[Voor 56% gewijzigd door ThinkPad op 08-02-2021 22:36]

[ThinkPad]

Helaas.

De Omnik app vind hem niet en het Python script vind hem wel (puur de reactie op een UDP-broadcast denk ik, gezien het een vrij algemene wifi-module is), maar geeft een connection refused.

Heb ook reactie terug van Goodwe op mijn support ticket: het protocol is niet openbaar en kunnen ze daarom niet verstrekken.

Frustrerend dat de data gewoon in je huis is, maar je er niet bij kan

[Voor 71% gewijzigd door ThinkPad op 09-02-2021 14:03]

[bwerg]

The Eagle schreef op maandag 8 februari 2021 @ 22:04:
[...]

Jawel, maar das een wireshark capture en daar moet je (denk ik) nog een hoop headers uitslopen. Netcat pen je zo naar file, kun je daemonizen etc.
En hij moet de waarde omzetten naar hex om te zoeken zegt ie..dan liever in text houden en gewoon regel voor regel opslaan lijkt me

Iig benieuwd naar de netcat output

Het is al weer een tijdje geleden dat ik wireshark heb gebruikt, maar ik weet toch vrij zeker dat daarin ook een veldje voor de TCP payload te vinden moet zijn, en daar zal je precies hetzelfde zien als in netcat. Wireshark ontleedt gangbare protocollen voor je.

Verder is het protocol waarschijnlijk tweerichtingsverkeer, en dan loopt het gesprek tussen de omvormer en netcat vrij snel dood. Als het lukt om de responses van de server na te spelen niet, en dan wordt het interessant, want dan kun je die hele Goodwe-servers vervangen door die van jezelf. Ben je ook gelijk van wat beveiligings-issues af. Maar dat is wel even wat meer reverse-engineering dan alleen afluisteren.

[Voor 8% gewijzigd door bwerg op 09-02-2021 15:59]

[Ben(V)]

Je beschrijft niet hoe je die wireshark caputure gemaakt heb, maar om dit soort communicatie te kunnen analyseren kun je niet zomaar je PC aan die goodwe gaan hangen en een capture doen.
Dan krijg je zoals je ziet helemaal niets.

Om dit te doen hebt je een managed switch nodig, die de mogelijkheid tot een port mirror heeft.
Configureer die switch zodanig dat de port die aan die goodwe hangt gemirrored wordt naar een andere port en hang daar je PC aan.
Daarna kun je met wireshark de communicatie tussen die goodwe en de central goodwe servers zien in wireshark.

Een alternatief is ergens een ouderwetse hub op de kop tikken, die mirroren alles op alle ports.

Zie:
https://wiki.wireshark.org/CaptureSetup/Ethernet

[ThinkPad]

@Ben(V) Ik heb een Edgerouter X en heb een tcpdump gestart die het via SSH piped naar Wireshark. Werkt prima en geen gedoe met kabels ompluggen of een hub o.i.d. ertussen hangen. Op deze manier kan ik ook alles in m'n netwerk meeluisteren.

ssh username@192.168.1.1 "sudo tcpdump -f -i switch0.6 -w -" | "C:\Program Files\Wireshark\Wireshark.exe" -k -i -

switch0.6 is het VLAN waar m'n IOT meuk in zit.

Medetweaker @No13 had nog uitgevonden dat je vanuit de Android app 'SEMS Portal' ook remote control van de omvormer hebt. Je kunt wat settings (landcode, power factor e.d.) aanpassen en ook de omvormer pauzeren (geen opwek meer) en weer aanzetten. Dit werkt prima, maar zoals verwacht is ook dit verkeer versleuteld. No13 heeft dit seriële verkeer tussen wifi-module en omvormer ook gesniffed, maar is ook hier nog encrypted. Het versleutelen/ontsleutelen gebeurt dus door de CPU van de omvormer zelf.

[Voor 26% gewijzigd door ThinkPad op 15-02-2021 11:29]

[Gomez12]

ThinkPadd schreef op maandag 15 februari 2021 @ 11:13:
Medetweaker @No13 had nog uitgevonden dat je vanuit de Android app 'SEMS Portal' ook remote control van de omvormer hebt. Je kunt wat settings (landcode, power factor e.d.) aanpassen en ook de omvormer pauzeren (geen opwek meer) en weer aanzetten. Dit werkt prima, maar zoals verwacht is ook dit verkeer versleuteld. No13 heeft dit seriële verkeer tussen wifi-module en omvormer ook gesniffed, maar is ook hier nog encrypted. Het versleutelen/ontsleutelen gebeurt dus door de CPU van de omvormer zelf.

En als je nu eens die 'SEMS Portal' decompiled? Tref je daarin dan niet de versleuteling aan?

[ThinkPad]

Nee, ik verwacht daarin hooguit bijv. wat JSON endpoints te vinden die de data in de app tonen (en dat is al bekend, uitleesscripts die de fabrikant portal scrapen (zoals 'gw2pvo') gebruiken dit).

Er is ook geen rechtstreekse communicatie van de app naar de omvormer (of andersom), daar heb ik al eerder naar gezocht met andere apps. De omvormer wordt dan wel gevonden (reageert op een UDP Broadcast), maar mijn omvormer is niet ondersteund in die apps. Het verkeer van de officiële app gaat via de cloud van Goodwe die als tussenpersoon fungeert.

Een andere optie zou zijn om firmware van de omvormer te decompilen, maar deze is helaas niet publiekelijk te downloaden. En deze omvormer heeft geen USB-aansluiting dus het is de vraag of ik überhaupt firmware files kan krijgen. Mijn vorige Goodwe omvormer had wel een toegankelijke USB-poort en kreeg ik van support ook files + utility voor toen ik vroeg om een firmware udpate. Maar die omvormer heeft weer een heel ander protocol, dus die firmware reverse engineeren ga ik niks aan hebben.

Heb nog geprobeerd om deksel van omvormer te verwijderen om eens binnenin te kijken, maar er zit een rottige 'warranty void' sticker op die ik er met warm maken (föhn) niet zonder beschadigingen af krijg (klein stukje geprobeerd).

[Voor 46% gewijzigd door ThinkPad op 15-02-2021 12:14]

[bwerg]

ThinkPadd schreef op maandag 15 februari 2021 @ 12:02:
Heb nog geprobeerd om deksel van omvormer te verwijderen om eens binnenin te kijken, maar er zit een rottige 'warranty void' sticker op die ik er met warm maken (föhn) niet zonder beschadigingen af krijg (klein stukje geprobeerd).

Met een stanleymesje misschien? In zo'n houdertje met de vorm van een ijskrabber, waarmee je dus het de hele snijkant onder de sticker kan schuiven.

Zo heb ik de sticker van een Zwitsers wegenvignet onbeschadigd van mijn vooruit weten te krijgen, terwijl die dingen zijn gemaakt om te scheuren als je ze er vanaf trekt. Had ik helemaal niks aan want het jaar was al voorbij. Maar toch leuk voor in het plakboek.

[ThinkPad]

bwerg schreef op maandag 15 februari 2021 @ 17:22:
[...]

Met een stanleymesje misschien? In zo'n houdertje met de vorm van een ijskrabber, waarmee je dus het de hele snijkant onder de sticker kan schuiven.

Zo heb ik de sticker van een Zwitsers wegenvignet onbeschadigd van mijn vooruit weten te krijgen, terwijl die dingen zijn gemaakt om te scheuren als je ze er vanaf trekt. Had ik helemaal niks aan want het jaar was al voorbij. Maar toch leuk voor in het plakboek.

Ik heb de sticker warm gemaakt en toen dit geprobeerd:

Maar het is een sticker waarbij er van die rondjes achterblijven. Heb een heeel klein stukje geprobeerd en zag toen al dat het niet ging lukken.

[dirksenrdh]

ThinkPadd schreef op maandag 8 februari 2021 @ 09:06:
De Nederlandse support heb ik al eens contact mee gehad voor een ander issue (firmware update van andere omvormer), ging vrij stroef. Heb nu een mail gestuurd naar het algemene wereldwijde support adres. Maar ik verwacht er niet teveel van eigenlijk. Via LinkedIn ook gezocht en wel o.a. een software engineer gevonden, maar geen mogelijkheid om hem/haar te kunnen contacten.

Ik hoop eigenlijk dat iemand mij op weg kan helpen hoe ik de Wireshark data moet analyseren, doordat iemand er een patroon/versleuteling-/husselmethode o.i.d. in weet te herkennen.

*snip*

[Voor 8% gewijzigd door Creepy op 18-02-2021 17:46. Reden: Persoonsgegevens verwijderd...]

[ThinkPad]

@dirksenrdh Ja ik heb inmiddels al antwoord van Goodwe dat ze het protocol niet willen vrijgeven.
RS485 heb ik naar gevraagd, ze verwijzen naar de connector op mijn omvormer. Maar waar volgens de handleiding pins voor RS485 zouden moeten zitten zijn die openingen bij mij leeg.

Ik meen te herinneren van een eerdere post dat jij een Goodwe naar Ethernet module hebt? Misschien dat daarmee Modbus over TCP mogelijk is?

[dirksenrdh]

ThinkPadd schreef op donderdag 18 februari 2021 @ 13:37:
@dirksenrdh Ja ik heb inmiddels al antwoord van Goodwe dat ze het protocol niet willen vrijgeven.
RS485 heb ik naar gevraagd, ze verwijzen naar de connector op mijn omvormer. Maar waar volgens de handleiding pins voor RS485 zouden moeten zitten zijn die openingen bij mij leeg.

Ik meen te herinneren van een eerdere post dat jij een Goodwe naar Ethernet module hebt? Misschien dat daarmee Modbus over TCP mogelijk is?

tja als je geen echte 485 poort hebt is mijn route voor jouw niet haalbaar.
Goodwe levert 2 types communicatiemodules die in de "USB" connector passen. Beide worden geproduceerd door HiFly electronics in ShangHigh.
Ik kreeg mijn omvormer met een wifi module maar omdat daar de security ver onder het nulpunt zat heb ik mijn PV leverancier gevraagd om een bekabelde module te leveren.
Eerlijk gezegd verwacht ik dat die hetzelfde doet als de wifi module: transparant doorgeven wat de omvormer zegt. en daar heb jij niets aan als de informatie versleuteld is...
https://www.winkelman-zon...g-play-module-voor-s.html
dit is hem en ook voor jouw omvormer geschikt.
maar nogmaals, ik haal hier geen informatie uit. Ik heb (gelukkig) een aparte 485 connector die ik kan gebruiken.

[ThinkPad]

Heb je de mogelijkheid om met nmap een portscan te draaien over die Goodwe LAN module?
Ik verwacht inderdaad ook dat het gewoon een doorgeefluik is, maar je weet het maar nooit

[dirksenrdh]

ik heb 100 jaar geleden wel eens wat met nmap gedaan maar dat is volledig weggezakt.
Laatste keer dat ik iets intelligents heb gedaan met mijn netwerk was een portmirroring instellen op mijn router en daar een laptop met wireshark aan hangen en dan gaan dataminen...
en dan nog, zelf als het verkeer tussen mijn SDT-inverter en het SEMS portal onvercijferd zou zijn lijkt me dat geen garantie dat het op jou XS ook zo werkt. Ik kan me nl niet goed voorstellen dat Goodwe zijn vercijfering onderbrengt in een externe module.
Maar als je me een paar hints geeft over nmap wil ik wel een poging wagen dit weekend. (kan helaas alleen als de zon schijnt, maar dat schreef jij ook al :-) )

[ThinkPad]

Lijkt mij ook sterk dat ze de versleuteling onderbrengen in externe module, maarja zonder dat we het testen komen we er niet achter Als er bij de LAN module meer poorten open staan dan bij de wifi-module (alleen poort 80), dan is dat wellicht een nieuwe ingang waar ik mij op kan focussen.

Als je Domoticz op een Raspberry Pi hebt draaien (en dus een linux device beschikbaar hebt, op Windows is het wat lastiger) dan is het vrij makkelijk. Als je via SSH op je Pi inlogt dan is het een kwestie van:

TCP-poorten scannen:

nmap -p- 192.168.1.10

UDP-poorten scannen:

nmap -p- 192.168.1.10 -sU

IP-adres even vervangen door het IP-adres van de originele Goodwe LAN-module bij jou. Als je de output van die beide scans hier zou willen posten?

[Voor 22% gewijzigd door ThinkPad op 18-02-2021 15:44]

[dirksenrdh]

ja hoor en dan wel eerst nmap installeren via een apt-get :-|

code:

pi@PiTest136:~ $ nmap 172.17.116.135
Starting Nmap 7.70 ( https://nmap.org ) at 2021-02-18 14:41 CET
Nmap scan report for EportGoodweInverter.fritz.box (172.17.116.135)
Host is up (0.031s latency).
Not shown: 999 closed ports
PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 3.55 seconds

heb je hier iets aan?

en poort 80 is de admin poort voor de ethernet module. daar kom je zeker niet mee bij inverter data.

[Voor 10% gewijzigd door dirksenrdh op 18-02-2021 14:45]

[ThinkPad]

Dank je. Dat is hetzelfde als bij mijn wifi-module. Zou je ook nog de UDP-poorten scan kunnen doen? Wellicht zit daar nog verschil in.

[Gomez12]

Let er wel op dat

code:

nmap 192.168.1.10

afaik slechts de 1000 meest gebruikte ports scant en niet de 65535 beschikbare.

Daarvoor heb je nodig

code:

nmap -p- 192.168.1.10

En ik schat dat dat bij udp gelijk is.

[ThinkPad]

Ja, goed punt. Heb de commando's in mijn vorige post bijgewerkt. Scan duurt ook aanzienlijk langer nu. Met de TCP-scan was hij bijna 10 min. bezig, overigens nog steeds alleen 80/tcp gevonden (van de webinterface waar geen bruikbare info op staat). De UDP-scan loopt bij mij nu nog, is inmiddels al 40 min. bezig.

@dirksenrdh Zou je ze beiden nog eens willen draaien maar dan met parameters zoals in m'n vorige post?
De UDP-scan kan best wel lang duren vermoed ik. Wellicht is het beter om deze in de ochtend te doen, zodat de omvormer niet uitvalt omdat het donker is geworden.

[Voor 55% gewijzigd door ThinkPad op 18-02-2021 16:22]

[dirksenrdh]

nmap -p- is onderweg. Maar wel de volgende vraag.
nmap scant toch op welke poorten een applicatie luistert.
maar als de inverter een tcp sessie start naar het SEMS platform dan kan er daarna 2 richting communicatie zijn zonder dat er een poort open staat.
Als je geen open poorten vindt wil dat alleen zeggen dat jij niet als source de communicatie naar de inverter kan starten.
maar heb blijft mogelijk om de communicatie tussen inverter en sems af te luisteren en daar de betreffende informatie uit te halen (tenzij vercijferd).
en helaas

code:

pi@PiTest136:~ $ nmap -p- 172.17.116.135
Starting Nmap 7.70 ( https://nmap.org ) at 2021-02-18 17:35 CET
Nmap scan report for EportGoodweInverter.fritz.box (172.17.116.135)
Host is up (0.00099s latency).
Not shown: 65534 closed ports
PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 196.19 seconds

[ThinkPad]

nmap scant de poorten die open staan bij een device. Beetje vergelijkbaar met kloppen op een muur en dan ineens een deur/holle ruimte tegenkomen, dat klinkt 'anders'

Bij oudere modellen Goodwe bleek er op poort UDP 8899 communicatie mogelijk te zijn. Helaas reageert mijn 3000XS via de wifi-module daar niet op (connection refused).

Zou je zodra het weer licht is, nog eens een nmap willen uitvoeren, maar dan op UDP?

nmap -p- 192.168.1.10 -sU --stats-every 1m

Het is aan te raden dit in de ochtend te starten, ik denk dat deze best wel lang nodig gaat hebben (port scan op UDP duurt veel langer dan TCP). Ik ben heel benieuwd of er op de Ethernet module andere poorten open staan dan op de wifi-module. Ik zal de scan van mijn wifi-module morgen ook even doen, tot nu toe had ik het nog niet over alle poorten laten lopen.

[Voor 1% gewijzigd door ThinkPad op 18-02-2021 18:04. Reden: stats toegevoegd aan commando om progress te kunnen volgen]

[dirksenrdh]

oh nee, ik vergis me natuurlijk. de ethernet interface van de goodwe is offline omdat hier de zon uit is gegaan en de regen op vol vermogen staat

[Voor 58% gewijzigd door dirksenrdh op 18-02-2021 18:01]

[dirksenrdh]

Ik zal de -sU morgen ergen in de loop van de ochtend starten (niet al zodra het licht is)

[dirksenrdh]

duurt idd ff. gestart om 08:43 en nog niet klaar

maar de volgende dag was dit het resultaat

code:

pi@PiTest136:~ $ sudo nmap -p- 172.17.116.135 -sU
Starting Nmap 7.70 ( https://nmap.org ) at 2021-02-19 08:43 CET
Nmap scan report for EportGoodweInverter.fritz.box (172.17.116.135)
Host is up (0.0013s latency).
Not shown: 65533 closed ports
PORT      STATE         SERVICE
8899/udp  open|filtered ospf-lite
48899/udp open|filtered unknown
MAC Address: deleted (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 13765.24 seconds
pi@PiTest136:~ $

[Voor 86% gewijzigd door dirksenrdh op 20-02-2021 17:24]

[Ben(V)]

Als er zo'n standaard module in zit zou hij moeten reageren als je een UDP datagram naar poort 48899 met daarin "WIFIKIT-214028-READ" naar heb verstuurt en dan de response leest.

Source:
https://www.secura.com/nl...ckle-down-vulnerabilities

[ThinkPad]

Ik heb de UDP scan ook nog even weer gedaan op mijn wifi-module:

nmap -p- 192.168.6.15 -sU --stats-every 1m 
Starting Nmap 7.91 ( https://nmap.org ) at 2021-02-19 13:24 CET
Nmap scan report for hflpb100.removed (192.168.6.15)
Host is up (0.018s latency).
Not shown: 65531 closed ports
PORT      STATE         SERVICE
53/udp    open|filtered domain
67/udp    open|filtered dhcps
8899/udp  open|filtered ospf-lite
48899/udp open|filtered tc_ads_discovery
MAC Address: removed (Shanghai High-Flying Electronics Technology)

Nmap done: 1 IP address (1 host up) scanned in 2996.39 seconds

@Ben(V) Dat heb ik al geprobeerd, op zowel 8899 als 48899 met een testscript van deze repository en ook nog dit script. Maar met beiden geen reactie van de omvormer.
Ik denk ook dat dat gewoon het 'algemene' configuratieprotocol van de module zelf is en los staat van de omvormer. Dat de module reageert op die poorten hoeft nog niet te betekenen dat de omvormer er ook wat mee doet.

[Voor 26% gewijzigd door ThinkPad op 19-02-2021 15:10]

[dirksenrdh]

@ThinkPad

code:

pi@PiTest136:~ $ sudo nmap -p- 172.17.116.135 -sU
Starting Nmap 7.70 ( https://nmap.org ) at 2021-02-19 08:43 CET
Nmap scan report for EportGoodweInverter.fritz.box (172.17.116.135)
Host is up (0.0013s latency).
Not shown: 65533 closed ports
PORT      STATE         SERVICE
8899/udp  open|filtered ospf-lite
48899/udp open|filtered unknown
MAC Address: deleted (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 13765.24 seconds
pi@PiTest136:~ $

dus mijn ethernet module heeft dezelfde poorten open als jouw wifi module.
die 8899 is wel heel populair want ik heb nog 2 andere devices van dezelfde fabrikant (HiFly electronics) en die hebben 8899/tcp open als standaard port.
als je wilt dat ik nog wat testjes doe, laat maar weten. Als het binnen mijn comfort zone past zal ik proberen je te helpen.

[Voor 39% gewijzigd door dirksenrdh op 20-02-2021 17:29]

[ThinkPad]

@dirksenrdh Bedankt voor het testen en je aanbod. Helaas zit ik vast, die openstaande UDP poorten reageert hij niet op als ik probeer met scripts die ik kan vinden. En het TCP bericht wat de originele module naar Goodwe stuurt is versleuteld.

[ThinkPad]

Ik heb nog wat interessants gevonden, een download met hierin firmware bestanden, flashtools en handleidingen hoe te updaten voor diverse typen omvormers. Ook die van mijn omvormer (XS-series) zit erbij. Downloadlink

Ik herken die firmware bestanden (.out files) van toen ik mijn andere omvormer ging updaten. Misschien heeft iemand zin om eens in die firmware files te neuzen? Ik heb al eens geprobeerd met Ghidra het te openen, maar heb eigenlijk geen idee hoe dat werkt

@Icekiller2k6 Jij misschien? Gezien je er al eerder om vroeg ?

Bij die andere omvormer van mij (NS-series) kon ik met een USB-A naar USB-A kabel de firmware updaten, maar bij deze omvormer (XS-series) werkt dat anders. De USB3-aansluiting die erop zit heeft namelijk wat pins omgedraaid/gebruikt voor ander doeleinde en is dus zeker geen standaard USB. Als ik de file Local Upgrade for XS Method.pdf bekijk dan zou er dus wel degelijk een RS485 connectie op moeten zitten, via de USB-connector.... hmmm maarja wat is de pinout. Als ik kijk naar de pinbezetting van de originele wifi-stick dan blijven er 4 lege pins over waar RS485 op zou kunnen leven...

[Voor 81% gewijzigd door ThinkPad op 22-02-2021 07:52]

[No13]

Door een simpele 'strings' search op die firmware kom je veel functienamen (denk ik?) tegen maar nog geen directe aanknopingspunten over of/welke encryptie men toepast. Wel verwijzingen naar Wifi, rs-485 enz...

De kabel om de inverter mee te flashen is nog wel interessant; zal vandaag eens in de datasheet kijken hoe het flash proces er normaal uit ziet en of dit eventueel pinnen zijn die daarnaast ook voor seriele comm gebruikt kunnen worden... (rs-485??)

[ThinkPad]

Vanochtend nog wat geprobeerd met de vrije pins op de USB3 connector, maar op geen enkele manier krijg ik er data uit of ook maar reactie van de omvormer. Heb het ook nog met Modbus RTU software geprobeerd, niks Goodwe geeft aan dat ze aan het serienummer zien dat mijn omvormer geen RS485 heeft, maar alleen TTL. En TTL is geen protocolbeschrijving publiekelijk van beschikbaar. Dit seriële verkeer tussen omvormer en wifi-module is ook al bekeken door @No13 en is dan al encrypted.

Ben nog even verder gegaan n.a.v. bovenstaande opmerking. Als ik met 'Ghidra' (schijnt dé tool te zijn om te decompilen/reverse engineeren ) een .bin uit de bovengenoemde download kijk en zoek op strings dan zie ik o.a. 'POST' en het adres 'tcp.goodwe-power.com' voorbijkomen (het adres waar de wifi-module naar upload en ik eerder al een Wireshark capture van had gemaakt). Ik heb alleen nul kennis van Ghidra/reverse engineering/decompiling dus zou niet weten waar ik moet beginnen De .bin heb ik geïmporteerd en tegen Ghidra gezegd dat het 'ARM' is (gezien de bestandsnaam van de file). Ik zie dan allerlei functies met duidelijk leesbare code 'if then' e.d., maar de functies/vars hebben willekeurige namen, dus ondanks dat de code leesbaar is zegt het mij eigenlijk ook weer helemaal niks.

@Mr. HTTP Heb jij wellicht meer kennis van Ghidra (of soortgelijke tools)?

[Voor 28% gewijzigd door ThinkPad op 23-02-2021 14:32]

[No13]

@ThinkPad Dat kan op zich wel boeiende informatie zijn; kan je eens aangeven welke opties je exact hebt geselecteerd? Dan zou je theoretisch kunnen traceren waar de tcp call gemaakt wordt en welke info erin is gestopt

[appieroos]

ThinkPadd schreef op maandag 15 februari 2021 @ 11:13:
@Ben(V) Ik heb een Edgerouter X en heb een tcpdump gestart die het via SSH piped naar Wireshark. Werkt prima en geen gedoe met kabels ompluggen of een hub o.i.d. ertussen hangen. Op deze manier kan ik ook alles in m'n netwerk meeluisteren.

ssh username@192.168.1.1 "sudo tcpdump -f -i switch0.6 -w -" | "C:\Program Files\Wireshark\Wireshark.exe" -k -i -

switch0.6 is het VLAN waar m'n IOT meuk in zit.

Ik heb toevallig dezelfde router en heb met de portable versie van wireshark een ssh connectie gemaakt, dit zit standaard in wireshark waarmee de output van tcpdump van de router live in wireshark binnenkomt, zal op de achtergrond ongeveer hetzelfde werken inderdaad.

[frickY]

Als het voorheen een reguliere HTTP POST was maar nu plots encrypted, en in de firmware vond je nog steeds de string POST terug, dan zijn ze misschien simpelweg overgegaan naar een HTTPS-adres?
Wireshark zou daarvan de handshake moeten herkennen.
Als ze geen certificate pinning en verificatie hebben toepast, zou je er in dat geval een proxy met een self-signed certificaat (bijv Fiddler) tussen kunnen zetten om het verkeer te zien.

Al noem je ook "POSTGW" ipv "POST"...

//edit Beetje zitten Googlen.. zou ook zomaar kunnen dat ze gewoon ruwe modbus naar buiten gooien

[Voor 18% gewijzigd door frickY op 23-02-2021 22:21]

[ThinkPad]

Het is bij mijn variant nooit plaintext geweest, met een ouder model omvormer wel als ik zo rondkijk op internet.
Wireshark ziet het als ruwe TCP data (zie capture in de TS, mocht je zelf willen kijken).

Modbus lijkt mij onwaarschijnlijk, wat ik daarvan begreep is dat je master/slave situatie hebt waarbij de master een 'pull' doet van de slaves. Maar in de Wireshark capture zie ik duidelijk dat de eerste connectie altijd door de wifi-module gedaan wordt. En ook met Modbus zou ik, als het unencrypted was een patroon verwachten. Zaken zoals de temperatuur of de totale opwek wijzigen vrij langzaam, dus ik zou dan op bepaalde plekken dezelfde waardes verwachten.

De .bin waar @No13 en ik naar hebben gekeken is vermoedelijk de firmware van de wifi-module. Aangezien het verkeer al encrypted bij de wifi-module aankomt gaan we daar niks in vinden vermoed ik. De .out files (master & slave) zijn voor de CPU in de omvormer. Maar in de datasheet van TI (het is een chip uit de TMS320 familie denken we, te zien aan de strings die in de firmware staan) staat ook dat deze beveiligd kan zijn tegen reverse engineering.

[Voor 45% gewijzigd door ThinkPad op 24-02-2021 09:48]

[bwerg]

dirksenrdh schreef op donderdag 18 februari 2021 @ 17:41:
nmap scant toch op welke poorten een applicatie luistert.
maar als de inverter een tcp sessie start naar het SEMS platform dan kan er daarna 2 richting communicatie zijn zonder dat er een poort open staat.
Als je geen open poorten vindt wil dat alleen zeggen dat jij niet als source de communicatie naar de inverter kan starten.

Beetje laat, maar volgens mij heeft niemand het gezegd, dus: ja. nmap vindt alleen TCP servers, geen clients.

[dirksenrdh]

ThinkPadd schreef op woensdag 24 februari 2021 @ 08:55:

Modbus lijkt mij onwaarschijnlijk, wat ik daarvan begreep is dat je master/slave situatie hebt waarbij de master een 'pull' doet van de slaves. Maar in de Wireshark capture zie ik duidelijk dat de eerste connectie altijd door de wifi-module gedaan wordt. En ook met Modbus zou ik, als het unencrypted was een patroon verwachten. Zaken zoals de temperatuur of de totale opwek wijzigen vrij langzaam, dus ik zou dan op bepaalde plekken dezelfde waardes verwachten.

Modbus is idd een master-slave protocol. Ik heb dat werkend op mijn omgeving waar een Pi (modbus master) een request doet naar mijn inverter (gw8k-dt modbus slave) die dan met een hele set registerwaarden antwoordt waar alle gewenste data in staat. Randvoorwaarde is dat de inverter een RS485 bus heeft en dat is bij de XS unit van @ThinkPadd niet zo. dus dat gaat hem niet worden.

de Ethernet of Wifi route kan alleen maar de andere kant op werken, nl dat de inverter zelf het initiatief neemt voor contact met het SEMS portal.
Als het SEMS portal contact zou maken met de inverter zou je ergens in je installatie moeten NATten om de gebruikte poort bereikbaar te maken voor het SEMS portal. Bij mijn vorige inverter (SolarMax) moest ik poort 12345 natten naar het interne IP adres van de inverter. Bij Goodwe is dat niet zo dus het initiatief moet altijd bij de inverter vandaan komen.
Als Goodwe nu overgestapt is naar https (en daar lijkt het op) is er geen andere optie dan te doen wat @frickY schrijft en dat is er een proxy tussen zetten en het verkeer van de inverter naar de proxy bekijken.

[ThinkPad]

Maar dan gaan jullie @frickY @dirksenrdh er al vanuit dat het HTTPS is (omdat het encrypted is). Het zou net zo goed een zelfbedacht protocol van Goodwe kunnen zijn. Ik dacht namelijk dat Wireshark HTTPS wel herkent.

Edit:
Docker container (mitmproxy) opgezet en met een DNAT regel in de router het verkeer omgebogen:

code:

::ffff:192.168.6.15:10152: request
  -> HTTP protocol error in client request: Bad HTTP request line: b'POSTGW\x00\x00\x01\t\x01\x04\x00\xknipjehierstondserienummer\x15\x02\x18\x10\x0b7\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x15\x02\x18\x10\x0b7\xb6\xf6f\x86\x94\x90\xaa:\xf1\x1ew\x87\xef\xb5u\x97\xcb]%4\xd3& \xabar\xc7Jh\xcf'
192.168.6.15:10152: clientdisconnect

Dat is dezelfde (onleesbare) output als wat ik met Wireshark opvang. Elk request heeft ook hier totaal verschillende data. Was ook wel te makkelijk geweest anders

[Voor 55% gewijzigd door ThinkPad op 24-02-2021 15:19]

[frickY]

Staar je niet blind op de totaal verschillende data. Als ze bijvoorbeeld 7bit ASCII gebruiken en je kijkt naar de hex encoding daarvan veranderd er al snel van alles. Heb je ook een binaire encoding vergeleken?
Ik begrijp dat je consequent je serienummer herkent?

[ThinkPad]

Ja het serienummer staat er gewoon plaintext in, niet in hex. Als je nog meer dingen weet die ik kan proberen dan hoor ik het graag

@DataGhost Ik zie dat jij in een ander topic ook iets dergelijks hebt uitgepluisd. Zie jij misschien iets in deze data?

code:

0000   f0 9f c2 df 54 7b 98 d8 63 70 d3 46 81 00 00 06   ....T{..cp.F....
0010   08 00 45 00 01 3e 02 28 00 00 ff 06 32 03 c0 a8   ..E..>.(....2...
0020   06 0f 2f fe 8f d9 2c e1 4e 21 00 05 10 a5 9a 18   ../...,.N!......
0030   8f bc 50 18 05 dc ec 65 00 00 50 4f 53 54 47 57   ..P....e..POSTGW
0040   00 00 01 09 01 04 00 00 58 58 58 58 58 58 58 58   ........XXXXXXXX
0050   58 58 58 58 58 58 58 58 15 02 07 0d 1d 3a 00 00   XXXXXXXX.....:..
0060   00 00 00 00 00 00 00 00 15 02 07 0d 1d 3a 0d 77   .............:.w
0070   af bb 74 b0 fe 5b 16 db 01 8f 69 bd 0a 38 cf 5d   ..t..[....i..8.]
0080   78 7f d8 9a 7e ce 66 13 ad eb ff bb 19 bd dd 33   x...~.f........3
0090   00 8c 74 2a 6b 99 b0 e0 30 4a aa ef 55 8e f6 e7   ..t*k...0J..U...
00a0   8b 2d b5 1b ce df 5e d4 0d d3 33 1a 46 92 80 c7   .-....^...3.F...
00b0   02 d7 2c 8e 88 c7 fe 8f f1 e7 62 e3 37 02 ef 78   ..,.......b.7..x
00c0   fd 25 5e 7d 73 4f db a0 54 7c 6f 2d f1 ed 66 ac   .%^}sO..T|o-..f.
00d0   3b 79 e8 f0 2e 64 02 9f d9 b0 54 16 5c 42 53 5b   ;y...d....T.\BS[
00e0   a3 4b 86 e0 91 a9 9a 6a 84 9c fc ce 7f 2a bd 4b   .K.....j.....*.K
00f0   b4 be 57 09 af c3 70 e2 be 27 ca 85 43 eb 58 9a   ..W...p..'..C.X.
0100   05 74 4a f2 65 c9 09 62 89 25 cb c7 30 86 a5 dc   .tJ.e..b.%..0...
0110   9d 21 65 03 ad ca fb 6d 30 f1 c5 89 d1 bb 53 7e   .!e....m0.....S~
0120   d8 e3 2b d0 73 f2 1a d9 3a 60 ea bf b7 1f 9d 6b   ..+.s...:`.....k
0130   87 24 60 eb 61 ca 98 29 95 7c 2c cc 8a 45 5c 48   .$`.a..).|,..E\H
0140   54 5f c9 ab 51 c4 68 78 58 28 60 c6 5f be 0d b9   T_..Q.hxX(`._...

XXXXXXXX = normaal gesproken het serienummer.

En hier hetzelfde packet maar dan alleen de hex stream:

code:

f09fc2df547b98d86370d3468100000608004500013e02280000ff063203c0a8060f2ffe8fd92ce14e21000510a59a188fbc501805dcec650000504f535447570000010901040000585858585858585858585858585858581502070d1d3a000000000000000000001502070d1d3a0d77afbb74b0fe5b16db018f69bd0a38cf5d787fd89a7ece6613adebffbb19bddd33008c742a6b99b0e0304aaaef558ef6e78b2db51bcedf5ed40dd3331a469280c702d72c8e88c7fe8ff1e762e33702ef78fd255e7d734fdba0547c6f2df1ed66ac3b79e8f02e64029fd9b054165c42535ba34b86e091a99a6a849cfcce7f2abd4bb4be5709afc370e2be27ca8543eb589a05744af265c909628925cbc73086a5dc9d216503adcafb6d30f1c589d1bb537ed8e32bd073f21ad93a60eabfb71f9d6b872460eb61ca9829957c2ccc8a455c48545fc9ab51c46878582860c65fbe0db9

Complete Wireshark capture met meerdere requests is evt. beschikbaar in de topicstart.

Heb het net nog even door CyberChef gehaald, die tool vond ik net en ziet er wel bruikbaar uit. Maar die kan er helaas ook niks mee.

[Voor 179% gewijzigd door ThinkPad op 24-02-2021 22:12]

[DataGhost]

ThinkPadd schreef op woensdag 24 februari 2021 @ 20:14:
@DataGhost Ik zie dat jij in een ander topic ook iets dergelijks hebt uitgepluisd. Zie jij misschien iets in deze data?

Ik had het topic een paar dagen geleden al gezien en even kort gekeken (echt maar een paar minuutjes), het ziet er op het eerste gezicht inderdaad uit alsof het op de een of andere manier versleuteld is, aangezien de payload van elk packet heftig verschillend was van de vorige, terwijl je tabel voor een behoorlijk deel hetzelfde blijft. Alleen het ontbreken van het serienummer + check code hebben ervoor gezorgd dat mijn aandacht ook direct weer weg was. Dat zijn namelijk prima dingen om te gebruiken als key, en zonder key kan je nou eenmaal niets. Een static key in de firmware lijkt me ook een logische mogelijkheid, dus als je een firmware-image hebt kan ik daar misschien eens naar kijken.

Een sessie-key in plaats van een static key is ook een mogelijkheid, maar die moet wel afgesproken worden (en dit gaat als het goed is op een manier die niet lekker af te luisteren is). Dit zie ik niet in je dump terug dus dat zal wel periodiek gebeuren (in ieder geval bij het starten gok ik), dus een dump terwijl je de omvormer reboot zou ook nog nuttig kunnen zijn. Daarmee is niet gezegd dat zoiets op dat moment gebeurt, kan best met een expiration opgeslagen zijn en elk uur, dag, week, maand of jaar ververst worden.

Ook kan er public-key encryptie gebruikt worden waar bovenstaande codes waarschijnlijk juist niet boeiend voor zijn. Maar dan ga je het in ieder geval niet (zomaar) ontsleuteld krijgen.

Ik zal morgen eens kijken of ik wat tijd kan vinden voor een poging.

Edit: toch even kort gekeken: de firmware is niet versleuteld en wel behoorlijk leesbaar, top. Maar ik kan de hostname bijvoorbeeld al niet vinden, "POSTGW" of "POST" ook niet. Alleen SBP en ES hebben misschien aanknopingspunten maar ik weet niet wat dat voor apparaten zijn, misschien is het legacy. Je hebt het over een wifi-dongle, dus ik verwacht eigenlijk dat de logica daar in zit.

[Voor 9% gewijzigd door DataGhost op 25-02-2021 01:06]

[ThinkPad]

Hey @DataGhost dank voor je reactie

Ik heb net de omvormer even helemaal uitgezet, daarna een Wireshark capture gestart en de omvormer weer aangezet.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Dit is het opstarten vanaf dat de omvormer stroomloos was. Je ziet dat hij eerst DHCP en DNS doet en vervolgens begint met data versturen. Dit heb ik nog een aantal minuten laten lopen.

De check code wil ik niet geven, met serienummer + check code kun je mijn omvormer aan je account hangen en vanaf afstand herstarten/opwek pauzeren Dit heb ik al getest via de app en kan ook daadwerkelijk. Er is dus ook verkeer terug mogelijk (komt van zelfde IP-range (of adres, weet het niet zeker meer) vanaf de fabrikant. Deze check code bestaat uit 6 cijfers en lijkt (van de twee andere omvormers die ik weet) altijd met een nul te beginnen. Dus bijvoorbeeld 040525, 018925 of 080316 (random gegenereerd). Als je een vermoeden hebt dan kan ik wellicht met die CyberChef testen?

SBP en ES zijn toch wel heel verschillende omvormers, deze zijn voor off-grid/hybride situaties waarbij je er een accupakket aan hangt. Die zullen qua firmware wel verschillen met mijn omvormer. Het gaat bij die omvormers vaak ook om grote opstellingen van een paar kW. Het is dan al wat industriëler waardoor het mij aannemelijker lijkt dat de boel dan met RS485 wordt uitgelezen.

De firmware is hier te vinden. In mijn geval gaat het dus om de XS serie.
Er zit twee keer (master en slave, volgens mij is het ene deel voor de DC-kant en de andere voor de AC-kant) een TMS320 CPU van TI in. Ze spreken in de datasheet over 128-bit encryptie om reverse engineering van de firmware tegen te gaan, maar ik heb zelf met 'strings' ook al gezien dat er toch best wat leesbare strings in staan inderdaad. In de master.out bijv. aantal hits op RS485.

Daarnaast staan er in die download bij andere modellen nog .bin files, dit is vermoedelijk de ARM-firmware voor de wifi-stick. Er heeft echter al iemand het seriële verkeer tussen omvormer en wifi-module gesniffed. Dit zijn AT-commando's, maar ook hier is de data payload gelijk aan wat je met Wireshark ziet en dus versleuteld (wifi-module is gewoon een doorgeefluik, ik heb niet het idee dat die weet heeft van de encryptie). In de .bin van de SMT vind ik wel een string tcp.goodwe-power.com

In dit Github issue is ook nog e.e.a. aan foto's te vinden van de wifi-module en de binnenkant van de omvormer.

[Voor 7% gewijzigd door ThinkPad op 25-02-2021 10:52]

[DataGhost]

Ok, gezien het verkeer tussen omvormer en wifi-module lijkt het er inderdaad op dat de module zelf niks doet en dat alles in de omvormer moet gebeuren. Ik kan alleen op geen enkele manier "POSTGW" of iets dergelijks vinden. Het adres "tcp.goodwe-power.com" zie ik alleen maar in een paar .bin-files terugkomen die suggereren dat het iets met ARM te maken heeft, alleen herken ik in de hex-view zo gauw geen ARM-instructies. Even verder gekeken en het blijkt Thumb te zijn, tenminste, ik zie nu assembly die er logischer uitziet dan random prut, alleen ik weet nog niet op welke adressen de boel geladen hoort te zijn.
Alsnog, het ontbreken van een string die in elk packet voorkomt geeft me het vermoeden dat de firmwares in die dump niet volledig zijn, dus dat is een lastig startpunt.

[ThinkPad]

Met bijv. Ghidra zijn de .bin files wel te lezen als je zegt dat het bijv ARM v7 (?) is. Je ziet dan duidelijk instructies als 'if', 'while' e.d. Maar alle variabelen en functienamen kan hij niet bepalen(?), dus dat is allemaal generated (FUNCxxxxx, varXXXX) waardoor het eigenlijk nog steeds onleesbaar is (naast dat er gigantisch veel functies in staan).

Ik denk dat de .bin van de wifi-module niet zo interessant is. Ik heb ook geprobeerd om de .out files van de (master en slave CPU's) met Ghidra te openen, maar heb geen idee hoe. Ik weet uit de datasheet dat het 32-bit is en little endian, maar wat voor architectuur is die CPU ? Heb nu de enige processor van TI gekozen die Ghidra beschikbaar heeft, de MSP430. Ik krijg dan een hele lijst met strings (lijken variabelen, namen als 'GridVoltage' e.d.) terug als ik Ghidra daar naar laat zoeken, maar verder is de code onleesbaar.

Moet ook eerlijk zeggen dat ik totaal geen kennis heb van reverse engineeren op deze manier, dus zou niet weten hoe ik verder moet.

[Voor 13% gewijzigd door ThinkPad op 25-02-2021 11:52]

[DataGhost]

Je had zelf al gevonden dat het een chip uit de TMS320-familie is, en daarmee kan ik ook de boel disassemblen tot iets wat er logisch uitziet. Die .out-files zitten vol met debug-info (in ieder geval functienamen, strings, e.d.) maar ik zie in de master vooral dingen gebeuren die intern aan de omvormer zijn, geen communicatie naar buiten, geen AT-commando's, geen POSTGW, niks. De slave-out lijkt een flasher als ik even superkort naar de herkende functienamen kijk. Ik krijg dus het gevoel (mede door de naam) dat dit test-firmware betreft waarin een hoop zaken ontbreken. Wat de .bin-files precies zijn ben ik nog niet helemaal over uit maar het lijkt op een header die ik niet ken, een ARM interrupt table en daarna gestripte/optimized ARM Thumb-code. Het gevolg daarvan is dat je inderdaad geen houvast hebt aan functienamen e.d. omdat die eruit gehaald zijn. Dan moet je echt op de die-hard manier gaan proberen of je basisfuncties kan identificeren vanuit een of andere gecompileerde standard library (of je moet het zelf doen) en op die manier voor steeds meer functies in gaan vullen wat ze doen en ze een naam geven. Dat is een rotklus, zeker op embedded waar vaak niet veel met strings gedaan wordt maar juist met I/O-poorten waarvan je de functie maar moet afleiden (of eigenlijk testen) als je het PCB en alle datasheets er niet bij hebt.

Als je weet waar je naar op zoek bent kan je redelijk snel in de goede richting geholpen worden zonder dat je de hele code uit hoeft te pluizen. Anders ben je gemakkelijk weken of maanden bezig met zooi uitzoeken. De aanknopingspunten waar ik naar op zoek ben kan ik op de makkelijke manieren niet snel vinden, dus dan houdt het voor een hobby-ding al snel op voor me als ik niet eens zeker weet of ik naar de juiste code zit te kijken

[ThinkPad]

Klinkt alsof we daar niet verder mee gaan komen dus Wat test-firmware betreft: dat zou best kunnen kloppen. Dit is een download met firmwares voor certificering in Italië o.i.d. heb ik het idee (CEI = Italiaanse variant van wat wij qu NEN1010 hebben ). Zou best kunnen dat daar het één en ander uit is gehaald. Heb helaas geen andere firmware(s) om naar te kijken, Goodwe heeft deze niet op de website staan.

De module die in de wifi-dongle gebruikt wordt is de HF-LPB100
Specs:
Processor: Cortex-M3 MTK
Operating System FreeRTOS (en LWIP voor communicatie zag ik ergens genoemd staan)

Maar toch denk ik dat de wifi-module ons niks wijzer gaat maken, omdat de payload daar al encrypted binnenkomt: https://github.com/janten...28#issuecomment-633589429

[Voor 26% gewijzigd door ThinkPad op 25-02-2021 13:58]

[danslo]

Denk dat je sowieso aan zoiets moet denken:

code:

50 4f 53 54 47 57 00 00                                 POSTGW
00 a9                                                   0xa9 = 169
01 03                                                   ?
[len(169)
    00 00
    35 33 30 30 30 53 53 58 32 30 31 57 30 30 34 34 
    15 02 19 0a 1a 15 
    00 00 00 00 00 00 00 00 00 00
    15 02 19 0a 1a 15 
    
    eb 61 8d 21 46 2c a6 20 bc 67 24 76 45 b6 b0 3a
    7b 48 aa 26 64 1e 0c bf ee fa 1a 66 6d af 7a eb
    cb ad e8 0c de 86 67 ac e0 19 75 69 2d cd 14 e5
    9d de 7d b4 67 4d 65 af 48 91 2e 4e 0c c0 45 ab
    cc d4 d1 58 4e fd 38 00 5f 5a f7 fe 7e 45 f0 92
    7b 3e a0 95 67 fd 10 bc b7 63 a5 ff c0 77 18 22
    96 a3 f4 fd 93 78 07 42 e1 d2 8a 03 c5 7b 4a 7f
    6d c0 bc 24 8b 7c 2b e6 13 06 f2 d5 94 f6 30 40 
    26
]
ee                                                      CRC?

code:

47 57 00 00                                             GW
00 31                                                   0x31 = 49
01 03                                                   ?
[len(49)
    35 33 30 30 30 53 53 58 32 30 31 57 30 30 34 34
    35 19 10 19 02 15 00 00 00 00 00 00 00 00 00 00 
    
    38 f6 54 2a f8 e4 81 d1 3e 14 80 55 53 db 22 ae
    55
]
61                                                      CRC?

Vrij duidelijk hoe de header ongeveer in elkaar zit en waar het stukje met hogere entropie (waarschijnlijk encrypted) zit.

Ik gok op een CRC byte op het eind, want zo komt dat het beste uit met de size in de header. Tevens is hij bij je eerste pcap "ef" en bij de tweede "ee". Dat is me iets te toevallig Zeker weten doe ik het niet.

Ik zou toch even inzetten op het bemachtigen van de firmware (desnoods zelf vanaf de fysieke hardware dumpen, wel wat tools voor nodig), want puur vanuit data analyse gaan we voor het belangrijkste deel niet veel verder komen.

Vanaf daar wordt het makkelijker

[ThinkPad]

Hey @danslo, dank voor je uitzoekwerk

De laatste twee bytes is inderdaad CRC (CRC-16/MODBUS om precies te zijn). Zie ook deze analyse op Github.

De enige firmware files die ik beschikbaar heb zijn deze. Op deze download na is de firmware niet publiekelijk beschikbaar op de website helaas. Fysiek dumpen is geen optie voor mij, dan moet ik de omvormer openen waarvoor ik de 'warranty void' sticker moet verbreken. Daarnaast vraag ik mij af in hoeverre dat zin gaat hebben, de datasheet van de TI TMS320 geeft aan dat er beveiliging op zit tegen reverse engineeren.

Is er iets anders dat ik kan doen dat je helpt hiermee?

[Voor 3% gewijzigd door ThinkPad op 27-02-2021 10:52]

[Luc45]

Ik heb ook even naar die firmware gekeken, maar het ziet er inderdaad een beetje uit als een test firmware, zoals al eerder benoemd is.

Ergens heb ik het vermoeden dat de data versleuteld is, wellicht dat dit met het serienummer en het andere nummer als key/iv gedaan wordt. Ik dacht dat het andere nummer in de laatste pcap ook verwijderd was, dus kan daar niet zo veel mee proberen.

[ThinkPad]

Luc45 schreef op zaterdag 27 februari 2021 @ 12:26:
Ik heb ook even naar die firmware gekeken, maar het ziet er inderdaad een beetje uit als een test firmware, zoals al eerder benoemd is.

Ergens heb ik het vermoeden dat de data versleuteld is, wellicht dat dit met het serienummer en het andere nummer als key/iv gedaan wordt. Ik dacht dat het andere nummer in de laatste pcap ook verwijderd was, dus kan daar niet zo veel mee proberen.

In de laatste pcap (die binnen de mo-tags) is niks door mij verwijderd/gestript.

Het zou kunnen dat er een versleuteling is gedaan met de 'check code' (6 cijfers, begint altijd met 0 vziw) maar die kan ik je niet geven, aangezien je daarmee mijn omvormer kunt opnemen in je account (en ook productie kunt stopzetten/hervatten)

Aan 'goede' firmware komen is lastig denk ik, gezien je een speciale kabel nodig hebt om te flashen. Ik denk niet dat de fabrikant mij de files gaat sturen als ik zeg dat ik zelf wel even een kabeltje in elkaar flans

[Voor 12% gewijzigd door ThinkPad op 27-02-2021 12:35]

[MarcoC]

Lang topic, maar ligt het nou aan mij of zie ik nergens de bytestring in kwestie die we moeten ontcijferen ?

[ThinkPad]

MarcoC schreef op zaterdag 27 februari 2021 @ 12:37:
Lang topic, maar ligt het nou aan mij of zie ik nergens de bytestring in kwestie die we moeten ontcijferen ?

Ik heb hier een pcap dump van Wireshark neergezet waarin ik de omvormer aanzet (zodat een evt. uitwisseling van een key er ook tussen zit) en waar meerdere uploads naar het moederschip in zitten. Heb die post ook even gepinned.

Voor de mensen zonder Wireshark, twee keer een upload:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Voor 4% gewijzigd door ThinkPad op 27-02-2021 12:44]

[MarcoC]

ThinkPadd schreef op zaterdag 27 februari 2021 @ 12:42:
[...]

Ik heb hier een pcap dump van Wireshark neergezet waarin ik de omvormer aanzet (zodat een evt. uitwisseling van een key er ook tussen zit) en waar meerdere uploads naar het moederschip in zitten. Heb die post ook even gepinned.

Voor de mensen zonder Wireshark, twee keer een upload:


***members only***

Thanks, dit hebben we nodig. Ik ken Wireshark niet, het lijkt me het handigst om het probleem zo klein mogelijk te maken. Het probleem is dat we een bytestring hebben waar we de juiste getallen in moeten zien te vinden. Dus het beginpunt moet zijn een bytestring zoals je hier plaatst, de rest leidt alleen maar af van de discussie .

Het probleem dat je wilt oplossen is als volgt: de getallen zitten in deze bytestring verstopt maar je weet niet hoe. Vragen die beantwoord moeten worden zijn:

• Zijn de getallen little endian of big endian opgeslagen? Heel simpel komt het er op neer of de getallen achterstevoren of niet in je bytestring verstopt zitten.
• Vervolgens is de vraag hoeveel bits er per getal gebruikt worden. 8-bit, 16-bit of 32-bit? Integer of float?
• Als laatste wil je een mapping hebben welke offset correspondeert met welk getal. Op deze manier kan je een "map" maken met welke getal op welke positie in je bytestring opgeslagen zit.

Bovenstaande weet ik omdat ik exact hetzelfde heb gedaan met de bytestring uit mijn omvormer. Bij mijn bytestring waren de getallen opgeslagen als "big endian" 16-bit integers. Een voorbeeld met een bytestring uit mijn omvormer:


Je ziet hier dus dat ik links de "big endian" inspector heb uitgeklapt en de "little endian" inspector heb ingeklapt. Als ik dan de cursor op positie 0x00000033 zet, dan zie je dat als je vanaf deze positie de data die daarop volgt als 16-bit integer uitleest als resultaat "2305" oplevert, wat overeenkomt met 230,5V. Op deze manier kan je de bytestring reverse engineeren. Reverse engineeren betekent in dit geval dat je een lijstje maakt met welke positie in de bytestring correspondeert met welke waarde en opschrijft welk datatype het is (ik vermoed dat alle getallen hetzelfde datatype hebben).

Wat je dus moet doen is het volgende:
1. De bytestring in hexed.it plakken
2. De big endian inspector openen (aanname dat alle Chinese apparatuur in de basis hetzelfde werkt en er dus ook big endian gebruikt wordt).
3. Alle posities afgaan in de bytestring totdat je een getalletje in de inspector tegenkomt wat er bekend uitziet.

In jouw geval kan ik weinig terugvinden in de bytestring. Weet je zeker dat dit de juiste bytestring is? En in je OP staat een hele reeks met waardes die hierin zouden kunnen zitten, kan je het niet meer pinpointen? Het zou mooi zijn als je met enige zekerheid weet welke getallen in de bytestring terug zouden moeten komen.

Bij mijn omvormer kan ik instellen dat de data gedumpt wordt naar een lokaal IP-adres. Kan jij dat ook? Ik denk het wel omdat de web interface van jouw omvormer heel veel lijkt op de mijne (afgaande van de link uit OP). Dan kan je op die poort luisteren naar de bytestring die verstuurd wordt. Ik zou persoonlijk een hexadecimale bytestring verwachten met relatief veel nullen erin namelijk en dat zie ik niet terug in jouw bytestring. Dit is bij de bytestring van mijn omvormer zo en ook het voorbeeld uit het linkje uit jouw OP heeft een hexadecimale bytestring met relatief veel nullen.

[Voor 16% gewijzigd door MarcoC op 27-02-2021 13:23]

[DataGhost]

MarcoC schreef op zaterdag 27 februari 2021 @ 12:58:
[...]

<bytestrings>

Als je het topic gelezen had had je je redelijk wat moeite kunnen besparen, dit was allemaal al geprobeerd en het sterke vermoeden is dat er encryptie in het spel is maar er zijn nog geen aanknopingspunten wat betreft algoritme en keys.

[Voor 4% gewijzigd door DataGhost op 27-02-2021 13:25]

[MarcoC]

DataGhost schreef op zaterdag 27 februari 2021 @ 13:23:
[...]

Als je het topic gelezen had had je je redelijk wat moeite kunnen besparen, dit was allemaal al geprobeerd en het sterke vermoeden is dat er encryptie in het spel is maar er zijn nog geen aanknopingspunten wat betreft algoritme en keys.

Ik beschrijf in mijn post hoe je data waarschijnlijk kan laten dumpen naar een lokaal IP-adres. Dan hoef je niet moeilijk te doen met algoritmes en keys. Ik lees nergens dat OP dit al geprobeerd heeft.

[Voor 29% gewijzigd door MarcoC op 27-02-2021 13:36]

[ThinkPad]

Laten we het gezellig houden op deze zonnige () dag

De post van @MarcoC is zeker interessant. Geen idee of het ook voor mijn situatie gaat werken, maar het ziet er zeker bruikbaar uit om een dergelijk protocol te ontcijferen. Wat voor omvormer ging het in jouw geval om?

Ik zal even zorgen dat ik een nieuw stukje logging verzamel en dan de data uit de portal ook erbij heb, zodat we kunnen zoeken.

Dumpen naar een andere server/lokaal IP-adres is bij mij niet mogelijk. In de webinterface van de module kan ik hem joinen aan m'n netwerk, een firmware file uploaden of de module resetten/herstarten. Maar voor het onderscheppen heb ik dus Wireshark om live mee te lezen.

Het datapakket is overigens telkens 278 bytes, wellicht nog het vermelden waard.
Deze post is ook erg interessant: https://brnrd.eu/misc/201...the-internet-of-shit.html maar bij mij is het minder leesbaar. Toch zou het kunnen dat het protocol hier wellicht op lijkt?

[Voor 44% gewijzigd door ThinkPad op 27-02-2021 13:50]

[danslo]

Op basis van de bovenstaande firmware lijkt het me idd TMS320, en daar zit geen support voor in Ghidra.

Welke dat wel heeft is radare2, maar die decompiled hem niet bepaald lekker als je de architecture op tms320 zet. Weet ook niet of het de moeite waard is als je niet zeker weet dat dat de firmware is die op je apparaat zit.

[danslo]

Kan ook niet echt POSTGW/GW constants in die firmware vinden. Compressie/encryptie is mogelijk maar binwalk geeft daar geen signalen voor.

[ThinkPad]

Hierbij drie nieuwe dumps. Tijdstip in Wireshark kwam precies overeen met tijdstip in export.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Dikgedrukt is de waarde 'POSTGW' vanaf waar de interessante data zit (het stuk ervoor is de TCP header).

Daar horen dan de volgende waardes bij:


Eens kijken of ik met die Hexed.it iets kan herleiden.

[Voor 10% gewijzigd door ThinkPad op 27-02-2021 17:58]

[1337aldi]

Ik heb mij nog niet helemaal ingelezen, maar bij het speuren door de firmware files kom ik een PDF tegen waarin de app "PV master" genoemd wordt, werkt dit ook met jouw inverter? Als deze app direct met de inverter kan praten, praat hij wellicht hetzelfde protocol, en zou een decompile van de app wellicht wat opleveren.

Ik heb de app al even door een online decompiler gehaald, maar heb zelf geen verstand van android, dus weet niet waar ik moet zoeken.

[ThinkPad]

1337aldi schreef op zaterdag 27 februari 2021 @ 14:36:
Ik heb mij nog niet helemaal ingelezen, maar bij het speuren door de firmware files kom ik een PDF tegen waarin de app "PV master" genoemd wordt, werkt dit ook met jouw inverter? Als deze app direct met de inverter kan praten, praat hij wellicht hetzelfde protocol, en zou een decompile van de app wellicht wat opleveren.

Ik heb de app al even door een online decompiler gehaald, maar heb zelf geen verstand van android, dus weet niet waar ik moet zoeken.

Al geprobeerd (en gesniffed met Wireshark), werkt niet. Geen ondersteuning voor mijn omvormer
Er wordt een UDP-broadcast gedaan door de app, de wifi-module stuurt dan een bericht terug. Maar daarna niks meer. En dat bericht terugsturen is standaardfunctionaliteit van de chip (HF-LPB100) in de wifi-module. Die wordt o.a. ook in Mi-light gebruikt zag ik waar ze dat zelfde broadcast bericht gebruiken.

---

Tot nu toe nog niet heel veel kunnen ontdekken, alleen een timestamp die twee keer in het datapakket terugkomt. UTC+2 zo te zien: 15021b0f0804 == 21-2-27 15 8 4 (yy-m-dd hh m s). Met dit 'recept' getest.

Verder zit er in de laatste 2 bytes een CRC (niet zelf uitgevonden, was op Github al uitgeplozen ) over het deel vanaf 'POSTGW'. Te berekenen door de output uit dit recept in deze CRC-calculator (CRC-16/MODBUS) te zetten (input even op hex zetten bij die calculator).

De eigenlijke payload is eigenlijk de output die hiermee overblijft (als ik daar een hele hexstream uit Wireshark in stop).

Heb die payload met https://hexed.it/ bekeken, maar geen herkenbare waardes tegengekomen (niet in little en big endian). Denk toch dat er nog een bepaald sausje overheen zit @MarcoC @danslo @DataGhost

[Voor 63% gewijzigd door ThinkPad op 27-02-2021 18:35]

[DataGhost]

Daarom ook de suggestie dat het versleuteld was. Ik heb ondertussen genoeg ervaring met hexdumps lezen dat ik in Wireshark al zag dat er weinig structuur in zat. Als je door je eerste sanitized-bestandje heenscrollt zie je dat elk packet een compleet andere payload heeft vanaf 0x6E. Dat is niet erg logisch als je ziet dat in je tabel-vormige resultaat toch behoorlijk wat identieke of slechts weinig verschillende waarden stonden, dan verwacht je dat ook in de payload terug te zien. Omdat eigenlijk alle bytes elk packet anders zijn is de eerste verdenking dus ook encryptie. Als de laatste twee bytes een CRC zijn is de payload dus een veelvoud van 16 bytes lang, ofwel 128 bits. Dat is ook een aanwijzing voor encryptie. Enkel compressie is niet heel waarschijnlijk, dan zou je verwachten dat de packets verschillende lengtes hebben. Als het toch gedaan is zal dat nog voor de encryptie-stap gebeurd zijn, dat zie je dan niet terug vanwege padding die gebruikt wordt om met hele blokken van 16 bytes te kunnen werken. Maar ook dan verwacht je zo nu en dan een afwijkend aantal blokken, als het data is waarbij compressie lonend is.

Deze analyse heb ik in m'n eerdere reacties niet getypt, deels omdat het mij vanzelfsprekend leek en ook omdat ik daar gewoon niet aan gedacht heb.

[danslo]

Ga mee in bovenstaande, en daarom ook zo belangrijk om de juiste firmware met een werkende disassembler te hebben. Zou daar de focus op leggen, al ben ik zelf niet heel ver (in korte tijd) gekomen

[dirksenrdh]

Verder zit er in de laatste 2 bytes een CRC (niet zelf uitgevonden, was op Github al uitgeplozen ) over het deel vanaf 'POSTGW'. Te berekenen door de output uit dit recept in deze CRC-calculator (CRC-16/MODBUS) te zetten (input even op hex zetten bij die calculator).

De eigenlijke payload is eigenlijk de output die hiermee overblijft (als ik daar een hele hexstream uit Wireshark in stop).

Heb die payload met https://hexed.it/ bekeken, maar geen herkenbare waardes tegengekomen (niet in little en big endian). Denk toch dat er nog een bepaald sausje overheen zit @MarcoC @danslo @DataGhost

Hoewel aannames in dit traject gevaarlijk zijn doe ik er een paar.
Het klopt idd dat er modbus crc16 wordt gebruikt voor de checksum. Gebeurt ook bij mijn inverter.
Het modbus protocol is register gebaseerd. Geef je start register en het aantal registers dat je wilt lezen een je krijgt een byte object terug. Daar zit niets leesbaars in.
Neem nu aan dat ze in veel van de software een vergelijkbare structuur kiezen.
Het merendeel van de registers is dan unsigned short BigEndian.
In mijn inverter beginnen de register banken op 0x0200 en 0x0300
Zou je nu uit die bytestream een blokje van 2 bytes kunnen filteren wat je kunt koppelen aan een waarde die geen factor 10 te groot is. Het merendeel van de registers moet je achteraf delen door 10..
Pak bijvoorbeeld het totaal aantal uren dat de inverter in bedrijf is. Dat kun je uitlezen op SEMS of uit het display, zet om naar unsigned short big endian en gebruik dat als zoekstring in je wire shark of andere dump.
Dan heb je een startpunt..
En het sausje kan zomaar een factor 10 zijn.

[ThinkPad]

@dirksenrdh Maar dan zou je een patroon moeten herkennen in de data, de waardes zitten in jouw geval immers op een vaste plek en zaken als de bedrijfsurenteller veranderen maar langzaam. Een terugkomend patroon blijkt niet het geval (datapakket is telkens compleet anders), dus er zit iets van encryptie overheen

[Voor 4% gewijzigd door ThinkPad op 28-02-2021 20:20]

[dirksenrdh]

@ThinkPad Ik probeer alleen mee te denken, er is een hypothese dat je data vercijferd is. Ik probeer te verzinnen of je metingen ook kunnen ontstaan zonder encryptie.
Als GW voor bepaalde units encryptie toepast en voor andere niet maakt dat het onderhoud van het SEMS portal onnodig ingewikkeld en ik zie de toegevoegde waarde voor GW niet.
Ja bij mij is het eenvoudig, de data zit altijd op dezelfde plek en idd de urenteller is een langzaam varierende waarde.
zit er helemaal geen patroon in, ik las iets dat het type en serienummer wel in plain voorbij komen en vanaf daar is het volledig random?
stel dat je van 10 of 100 pakketten de payload onder elkaar zou kunnen zetten, bijvoorbeeld uitgelijnd op het serienummer of iets anders dat vast en leesbaar is, en er verschijnt dan geen enkel patroon dan moet ik toegeven dat encryptie waarschijnlijker wordt. maar als je 100 pakketten uitgelijnd onder elkaar zet zou het ook kunnen dat elk zoveelste pakket wel een patroon oplevert. en dan heb je een haakje om verder te zoeken.
Als ik komend weekend tijd heb zal ik eens kijken of ik een mirror kan maken van mijn switchpoort waar de inverter op babbelt. en dan een wireshark op die mirror hangen. omdat ik verwacht dat GW wel degelijk https gebruikt denk ik niet dat ik die payload kan ontcijferen. En helaas heb ik niet de kennis (noch de spulleboel) om een proxy op te zetten en daar te meten.

[DataGhost]

dirksenrdh schreef op dinsdag 2 maart 2021 @ 16:45:
@ThinkPad Ik probeer alleen mee te denken, er is een hypothese dat je data vercijferd is. Ik probeer te verzinnen of je metingen ook kunnen ontstaan zonder encryptie.
Als GW voor bepaalde units encryptie toepast en voor andere niet maakt dat het onderhoud van het SEMS portal onnodig ingewikkeld en ik zie de toegevoegde waarde voor GW niet.
Ja bij mij is het eenvoudig, de data zit altijd op dezelfde plek en idd de urenteller is een langzaam varierende waarde.
zit er helemaal geen patroon in, ik las iets dat het type en serienummer wel in plain voorbij komen en vanaf daar is het volledig random?
stel dat je van 10 of 100 pakketten de payload onder elkaar zou kunnen zetten, bijvoorbeeld uitgelijnd op het serienummer of iets anders dat vast en leesbaar is, en er verschijnt dan geen enkel patroon dan moet ik toegeven dat encryptie waarschijnlijker wordt. maar als je 100 pakketten uitgelijnd onder elkaar zet zou het ook kunnen dat elk zoveelste pakket wel een patroon oplevert. en dan heb je een haakje om verder te zoeken.
Als ik komend weekend tijd heb zal ik eens kijken of ik een mirror kan maken van mijn switchpoort waar de inverter op babbelt. en dan een wireshark op die mirror hangen. omdat ik verwacht dat GW wel degelijk https gebruikt denk ik niet dat ik die payload kan ontcijferen. En helaas heb ik niet de kennis (noch de spulleboel) om een proxy op te zetten en daar te meten.

Omdat het toch een terugkerend thema lijkt zonder dat de data uberhaupt bekeken is: als je de netwerkdumps die zelfs in de TS al gepost zijn bekijkt met de packets en payloads netjes onder elkaar zie je dat er, zoals eerder gezegd, vanaf 0x6E geen enkel patroon meer in de data zit. Daarvoor zitten netwerkheaders en vanaf 0x3A is er de daadwerkelijke payload, met "POSTGW", statisch 0x00000109 0x01040000, het serienummer, 6 bytes met jaar (gewoon 21), maand, dag, uur, minuut, seconde, 10 nul-bytes en dan nogmaals jaar, maand, dag, uur, minuut en seconde. Daarna begint de payload. Ik verwacht, vanwege de herhaling, dat de datumtijd+nulls of nulls+datumtijd een IV is aangezien dit 16 bytes zijn (128 bits). Rest alleen nog de key en die verwacht ik niet in dit packet terug als ze wel de moeite hebben genomen om encryptie toe te passen. Het kan ook zijn dat de IV toch volledig random is en aan het begin of het eind van de "encrypted payload" (vanaf 0x6E) zit. Maar goed, kijk er nog eens naar, wie weet zie je dingen die ik niet zie.

Dat het "onderhoud van de SEMS portal onnodig ingewikkeld" wordt valt best mee. Ik verwacht dat een van de fixed waarden in de packets (of zelfs afhankelijk van het serienummer/modelnummer) een protocol-versie betreft, dat is best gangbaar in een transitie van legacy naar nieuw. Zeker omdat er geen HTTPS gebruikt wordt gingen eerst namelijk alle waarden gewoon plaintext over de lijn en dat is om tig redenen onwenselijk. Zomaar je portal omgooien zodat alleen encrypted wordt toegestaan kan natuurlijk niet zonder dat alle bestaande apparaten een firmware-update krijgen en als dat niet remote OTA kan (zonder tussenkomst en blokkeringsmogelijkheid van de eindgebruiker) zal je die optie gewoon beschikbaar moeten houden. Voordeel is dat het oude, plaintext protocol nooit meer verandert, dus qua onderhoud heb je daar eigenlijk ook geen kind aan, dat is gewoon een endpoint wat ook nooit meer verandert.

[xh3adshotx]

DataGhost schreef op dinsdag 2 maart 2021 @ 18:58:
[...]

Omdat het toch een terugkerend thema lijkt zonder dat de data uberhaupt bekeken is: als je de netwerkdumps die zelfs in de TS al gepost zijn bekijkt met de packets en payloads netjes onder elkaar zie je dat er, zoals eerder gezegd, vanaf 0x6E geen enkel patroon meer in de data zit. Daarvoor zitten netwerkheaders en vanaf 0x3A is er de daadwerkelijke payload, met "POSTGW", statisch 0x00000109 0x01040000, het serienummer, 6 bytes met jaar (gewoon 21), maand, dag, uur, minuut, seconde, 10 nul-bytes en dan nogmaals jaar, maand, dag, uur, minuut en seconde. Daarna begint de payload. Ik verwacht, vanwege de herhaling, dat de datumtijd+nulls of nulls+datumtijd een IV is aangezien dit 16 bytes zijn (128 bits). Rest alleen nog de key en die verwacht ik niet in dit packet terug als ze wel de moeite hebben genomen om encryptie toe te passen. Het kan ook zijn dat de IV toch volledig random is en aan het begin of het eind van de "encrypted payload" (vanaf 0x6E) zit. Maar goed, kijk er nog eens naar, wie weet zie je dingen die ik niet zie.

Ik vermoed eigenlijk dat het serienummer server-side gekoppeld is aan de private key. Mocht AES o.i.d op een redelijke manier geïmplementeerd zijn denk ik niet dat dit goed te doen is zonder de originele firmware bestanden. Zelfs dan word het lastig want het apparaat bevat vermoedelijk een public key die niet gebruikt kan worden om de payload te decrypten.

Mocht de key niet in de “fabriek” gekoppeld zijn aan het serienummer zou het nog kunnen dat de exchange tijdens de allereerste request plaats vind. Bijvoorbeeld na het volledig resetten van de omvormer als dit mogelijk is.

@ThinkPad heb je al eens gekeken wat er gebeurd als je het endpoint blokkeert? Heeft het apparaat een fallback mechanisme?

[Voor 7% gewijzigd door xh3adshotx op 02-03-2021 23:03]

[ThinkPad]

xh3adshotx schreef op dinsdag 2 maart 2021 @ 22:58:
[...]
@ThinkPad heb je al eens gekeken wat er gebeurd als je het endpoint blokkeert? Heeft het apparaat een fallback mechanisme?

Niet geprobeerd om te blokkeren, maar wel redirecten (DNS + DNAT-rule in m'n router) naar een data parsing script in m'n eigen netwerk. Het geheel oogt dan vrij 'dom', want het gaat gewoon op dezelfde interval (elke minuut) door met data uitspugen.

Verder zou het prima zijn als hij een connector had om hem bijv. via RS485 uit te kunnen lezen. Maar die is er niet, dus helaas loopt ook dat spoor dood zoals het nu lijkt (zijn we op Github aan het uitzoeken).

[Voor 9% gewijzigd door ThinkPad op 03-03-2021 19:00]

[JeroenE]

xh3adshotx schreef op dinsdag 2 maart 2021 @ 22:58:
Ik vermoed eigenlijk dat het serienummer server-side gekoppeld is aan de private key.

Ik zou eerder verwachten dat er maar 1 public key is die door iedere omvormer wordt gebruikt. Waarom zou je het ingewikkeld maken met een key-pair per apparaat?

Blijkbaar kan men wel aan de omvormer laten weten als de firmware geupdate moet worden. Via hetzelfde / soortgelijk mechanisme kan je dan vast ook de public key laten update mocht dat nodig zijn.

Bij je portal is het veel makkelijker als iedereen dezelfde key gebruikt.

Als je meerdere omvormers hebt en je vind het niet erg om een keertje verkeerde data in je overzicht te hebben staan zou je dat nog uit kunnen testen door bij 2 omvormers de internet toegang te blokkeren. Als je dan wel de payload van omvormer 1 kan afvangen en die met het serienummer van omvormer 2 met de hand naar de portal kan sturen kan je zien of de gegevens daar verschijnen.

Als dat zo is dan is er geen relatie tussen de encryptie en het serienummer. Als het niet gebeurt kan het natuurlijk aan heel veel dingen liggen, al was het maar omdat het serienummer wellicht ook in de payload staat en bij een mismatch niet wordt geaccepteerd.

Wellicht kan je dit ook testen met data uit het verleden, maar dan kan het ook mislukken omdat de portal geen nieuwe data accepteert voor waardes die al een keer zijn opgeslagen.

[xh3adshotx]

JeroenE schreef op donderdag 4 maart 2021 @ 09:08:
[...]
Ik zou eerder verwachten dat er maar 1 public key is die door iedere omvormer wordt gebruikt. Waarom zou je het ingewikkeld maken met een key-pair per apparaat?

Blijkbaar kan men wel aan de omvormer laten weten als de firmware geupdate moet worden. Via hetzelfde / soortgelijk mechanisme kan je dan vast ook de public key laten update mocht dat nodig zijn.

Bij je portal is het veel makkelijker als iedereen dezelfde key gebruikt.

Klopt, behoort ook zeker tot de mogelijkheden dat het een gedeelde public key is. Ik snap dan alleen niet helemaal waarom iets als het serienummer dan unencrypted voor de encrypted payload staat. Als check zouden ze ook een random nummer kunnen genereren of iets anders kunnen gebruiken. Meestal bevat een encryptie algoritme al een checksum of iets dergelijks waarmee "temper" gedetecteerd kan worden.

Ben wel benieuwd of het inderdaad lukt om de data van een andere omvormer te uploaden door gebruik te maken van het serienummer van jouw omvormer.

[Douweegbertje]

Ik heb ook even gekeken, leuk vermaak Met name vanuit security oogpunt ben ik dan weer geïnteresseerd. Nog niet veel wijzer geworden maar ik heb toch even brutaal een mailtje gestuurd naar SegenSolar in zuid afrika om mij de firmware te sturen
Die hadden al eerder alles op dropbox gezet en waren toen waarschijnlijk terug gefloten. Worth a shot.

edit; toch even de bestaande firmware bekeken; dit is first glance de files

code:

../app/OSClock.asm
../app/variable.c
../cpu/CLEARRAM.ASM
../cpu/DSP2803x_CodeStartBranch.asm
../cpu/DSP2803x_GlobalVariableDefs.c
../cpu/DSP2803x_usDelay.asm
../kernel/ports/OS_CPU_A.asm
../kernel/source/OS_EVENT.C
../kernel/source/OS_EVENT.C
../source/DSP2803x_DBGIER.asm
../source/DSP2803x_DisInt.asm
../app/AutoTest.c
../app/Communication.c
../app/Iapflash.c
../app/LCDdisplay.c
../app/OSClock.asm
../app/SystemInitial.c
../app/Userisr.c
../app/buspvprotect.c
../app/eeprom_temp.c
../app/grid.c
../app/main.c
../app/spitask.c
../app/supervisor.c
../app/switchcheck.c
../cpu/CLEARRAM.ASM
../cpu/DSP2803x_CodeStartBranch.asm
../cpu/DSP2803x_DefaultIsr.c
../cpu/DSP2803x_usDelay.asm
../driver/CRC/CRC32.c
../driver/LCD/lcdinitial.c
../driver/RTC/PCF8563_driver.c
../driver/SCI/ports/FunLst.c
../driver/SCI/ports/Sci/ports/SciFunLst.c
../driver/SCI/source/SciDriver.c
../driver/SCI/source/queue.c
../kernel/ports/OS_CPU.c
../kernel/ports/OS_CPU_A.asm
../kernel/source/OS_CORE.c
../kernel/source/OS_EVENT.C
../kernel/source/OS_SHELL.c
../kernel/source/OS_TIMER.c
../module/boostmodule.c
../module/buspvmodule.c
../module/gridmodule.c
../module/invertermodule.c
../module/library.c
../module/mpptmodule.c
../module/protectmodule.c
../module/safetyconfig.c
../module/safetymodule.c
../source/DSP2803x_DBGIER.asm
../source/DSP2803x_DisInt.asm

Zie hier ook:

code:

\puchMsg
_puchMsg
PusDataLen
_usDataLen
~puchMsg
_puchMsg
}usDataLen
_usDataLen
|uchCRCHi
_uchCRCHi
{uchCRCLo
_uchCRCLo
zuIndex
_uIndex
ybTemp
_bTemp
sCheckSum
_sCheckSum

met

code:

\Packet
_Packet
PbLength
_bLength
~Packet
_Packet
}bLength
_bLength
|bCheckSum
_bCheckSum
{wCheckSumTemp
_wCheckSumTemp
sCalSerNum
_sCalSerNum

[Voor 77% gewijzigd door Douweegbertje op 05-03-2021 01:11]

[JeroenE]

xh3adshotx schreef op donderdag 4 maart 2021 @ 20:29:
Ik snap dan alleen niet helemaal waarom iets als het serienummer dan unencrypted voor de encrypted payload staat.

Wellicht omdat dit ook zo was voor het unencrypted protocol. De exacte reden weet ik natuurlijk ook niet, maar ik denk dat ze op deze manier de server hetzelfde konden houden voor zowel de encrypted als unencrypted variant.

Meestal bevat een encryptie algoritme al een checksum of iets dergelijks waarmee "temper" gedetecteerd kan worden.

Een CRC is al gevonden. Dat vind ik dan een beetje hetzelfde, dat zal denk ik ook zo zijn omdat het in het unencrypted gedeelte ook zo is. De server kan dan controleren of er een serienummer en CRC is ontvangen. Aan de hand daarvan een goede reactie geven; bijvoorbeeld data niet volledig ontvangen, CRC klopt niet etc. Allemaal zonder dat de payload zelf in detail bekeken moet worden.

Wellicht kunnen zij ook per serienummer bijhouden of een firmware update nodig is. Als de server dan gelijk het serienummer weet kan in de response gelijk een reactie gegeven worden als "hier is de downloadlink voor nieuwe firmware", wederom zonder dat er iets met de payload gedaan moet worden.

Dat sluit natuurlijk niet uit dat er in het gedeelte wat encrypted is niet ook een mogelijkheid is om te ontdekken dat er mogelijk geknoeid is.

De daadwerkelijke verwerking/ontsleuteling van de data kan dan door een ander proces/systeem gedaan worden.

Maar goed, mijn ervaring met systemen waar iedere minuut honderdduizenden apparaten data willen dumpen is ook niet bestaand. Dus wellicht klopt hier niets van.

[ThinkPad]

Haha leuk dat het mensen zo bezig houdt. Ik wist dat ik er goed aan deed om het hier te posten

@Douweegbertje vooral app/Communication.c klinkt erg interessant Met welke tool doe je dit? Ik zie wel dingen die ik ook voorbij heb zien komen door met ‘strings’ de file te laten doorzoeken, maar hoe je dan verder gaat geen idee...

[Douweegbertje]

ThinkPadd schreef op vrijdag 5 maart 2021 @ 08:01:
Haha leuk dat het mensen zo bezig houdt. Ik wist dat ik er goed aan deed om het hier te posten

@Douweegbertje vooral app/Communication.c klinkt erg interessant Met welke tool doe je dit? Ik zie wel dingen die ik ook voorbij heb zien komen door met ‘strings’ de file te laten doorzoeken, maar hoe je dan verder gaat geen idee...

Dit was gewoon met strings Er zit gewoon IMO allemaal debug data in. M.b.t. die file names; die zullen er wel niet zo in staan. Dat is gewoon ooit test/debug output geweest (denk ik...) wat er is in gekomen. Net zoals je nog wat meer meuk tegenkomt vanuit het dev process (I.e. een disk D en jenkins, etc.)

Alle .out files lijken ook nog eens anders en ik heb zelf het idee dat dit vooral hele erge test data is. De 'software' laat dat ook deels zien dat als je dat uitprobeerd en stopt dat het aangeeft 'stopping test!!!'.

IMO ook alles met binwalk zijn false positives en om eerlijk te zijn weet ik niet eens waar we nu naar kijken

----------------

Persoonlijk geloof ik niet dat we nu tegen iets aanlopen vanwege de een bepaalde vorm van security en geavanceerde meuk. Ik denk dat het gewoon zo ruk in elkaar zit dat je er voor nu nog niets mee kan. Zeg maar in plaats van security through obscurity is het nu iets van security through a tering zooi.

Dat baseer ik op het gebruik van port 80 en die vage tcp port (heb even mijn notes niet op de pc). Het gebruik van FTP welke ik was tegengekomen (ftp, niet sftp en de release daarvan was in Nov 2009), het feit dat er debug/test data in zit, en de kwaliteit van de documentatie met allerlei vage dingen.

Zoals ik aangaf zit ik hier meer voor de security en ik heb toch wat klamme handjes als ik bepaalde strings zie m.b.t. 'remote', 'exec', wat vage hosts en het zou mij ook niet verbazen als er ergens hardcoded passwords in zitten.


IMO ook reden dat ze niet heel eager zijn om de firmware te delen...

[DataGhost]

Douweegbertje schreef op zondag 7 maart 2021 @ 16:12:
[...]


Dit was gewoon met strings Er zit gewoon IMO allemaal debug data in. M.b.t. die file names; die zullen er wel niet zo in staan. Dat is gewoon ooit test/debug output geweest (denk ik...) wat er is in gekomen. Net zoals je nog wat meer meuk tegenkomt vanuit het dev process (I.e. een disk D en jenkins, etc.)

Alle .out files lijken ook nog eens anders en ik heb zelf het idee dat dit vooral hele erge test data is. De 'software' laat dat ook deels zien dat als je dat uitprobeerd en stopt dat het aangeeft 'stopping test!!!'.

IMO ook alles met binwalk zijn false positives en om eerlijk te zijn weet ik niet eens waar we nu naar kijken

Dit ziet er op alle manieren uit als een debug-build inderdaad. Veel functies hebben gewoon hun namen erbij waardoor de disassembly behoorlijk makkelijk te lezen is, er lijkt nergens in het firmware-bestand compressie/encryptie/obfuscation gebruikt te zijn, alles zit er gewoon plaintext in. Qua strings soms gewoon als ASCII, soms als Unicode. Het firmware-bestand is een COFF met verschillende secties, wat het ook makkelijker maakt er chocola van te maken. Die strings met bestandsnamen e.d. zitten voor zover ik kan zien in een sectie die niet in de "inhoudsopgave" staat en als je naar de hex-view ervan kijkt lijkt daar ook geen code tussen te zitten, dat zal dus ongetwijfeld puur voor de debugger zijn.

[ThinkPad]

Ik heb geen productie firmware voor handen, dus daar kan ik helaas niet in voorzien. Deze inverter is ook niet via USB te updaten (zoals mijn vorige Goodwe, daar kreeg ik op verzoek wel de firmware files) maar alleen met een speciale kabel. Ik vermoed dat ik als consument daarom niet zomaar de update files krijg, dat lijkt mij meer voorbehouden aan een dealership die ook de juiste update kabel heeft.

En stel dat ik de firmware wel zou krijgen, dan vraag ik mij af of het wel zo legaal is (copyright?) als ik een firmware (die niet publiekelijk te downloaden is) zou uploaden en dat men hem hier gaat ontleden?

[Voor 31% gewijzigd door ThinkPad op 07-03-2021 20:01]

[ThinkPad]

Er is positieve voortgang te melden! Helaas heb ik de data richting Goodwe nog steeds niet kunnen ontsleutelen (ook niet meer mee bezig geweest). Maar het blijkt dat na een firmware update van de ARM chip naar >= versie 13, de omvormer lokaal valt uit te lezen met de app 'SolarGo'.

Vervolgens kun je op poort 8899 UDP met de omvormer praten (is mogelijk Modbus RTU maar is mij niet duidelijk). Je krijgt een hexstring terug, hier zit de informatie in. Zie ook: msatter in "[GoodWe] Uitlezen inverters via USB"

Mijn GW3000XS omvormer draaide op v1.02.10. Ik vroeg Goodwe om een firmware update en ging naar v1.52.10. Toen nogmaals gevraagd of ze ook de ARM-processor konden updaten en toen ging ik naar v1.52.14 en vanaf toen was de omvormer uit te lezen met de 'SolarGo' app.

Ik denk dat ik de internettoegang van de omvormer nu kan dichtzetten en hem lekker lokaal ga uitlezen

[Voor 7% gewijzigd door ThinkPad op 04-05-2021 00:23]

[BjorntobeWild]

ThinkPadd schreef op maandag 3 mei 2021 @ 23:48:
Er is positieve voortgang te melden! Helaas heb ik de data richting Goodwe nog steeds niet kunnen ontsleutelen (ook niet meer mee bezig geweest). Maar het blijkt dat na een firmware update van de ARM chip naar >= versie 13, de omvormer lokaal valt uit te lezen met de app 'SolarGo'.

Vervolgens kun je op poort 8899 UDP met de omvormer praten (is mogelijk Modbus RTU maar is mij niet duidelijk). Je krijgt een hexstring terug, hier zit de informatie in. Zie ook: msatter in "[GoodWe] Uitlezen inverters via USB"

Mijn GW3000XS omvormer draaide op v1.02.10. Ik vroeg Goodwe om een firmware update en ging naar v1.52.10. Toen nogmaals gevraagd of ze ook de ARM-processor konden updaten en toen ging ik naar v1.52.14 en vanaf toen was de omvormer uit te lezen met de 'SolarGo' app.

Ik denk dat ik de internettoegang van de omvormer nu kan dichtzetten en hem lekker lokaal ga uitlezen

Hoi @ThinkPad,

Wie weet kun je hier nog wat nuttige info terugvinden om de data eruit te halen. Zal op ongeveer dezelfde manier werken denk ik zo.

[geerttttt]

Ik heb zojuist een tweede omvormer opgehangen van goodwe. De vorige had onversleutelde data, deze heeft in ieder geval een andere hostname zie ik, namelijk tcp.goodwe-power.com , net als jij. Ik verwacht dat ik tegen dezelfde encryptie ga aanlopen. I'll keep you posted:)