Posted by Rick F on July 7, 2007, 12:36 am
My email address on this post should work if my spam filter doesn't
kick you out.. (8->
Rings.. We've got something like that at work using fiber.. Ok..
[ ... ]
I figured it would be too easy if the protocol might be too close..
I'd be surprised if they messed w/ floating point values -- they're
This way they can sell another piece of hardware that does a subset
of the data that actually flows across the interface..
Notice that ALL of these reply packets end in "32" which is an ASCII
space (not sure that is note worthy or not).. Seems like an
data point to me..
I think the "31 10 01" is probably some sort of fixed
string that is unit specific..
Cool.. Some of the work is done here (8->
I *think* that each response probably has the sender's details
embedded in it (see my comment above about the first 3 bytes)..
How many inverters do you have installed? My guess is that you've
got only one? My setup will have two inverters and I'd assume that
if there were multiple inverters, that you'd see another 3 byte
pattern in there -- perhaps something like : 31 10 02...?
Interestingly enough, the text string encoding is what the Pascal
language uses to encode strings -- back from my TurboPascal
days.. (8->.. They put a single byte in front of the string to
how long the string was.. Of course, C/C++ use null (zero) terminated
[ ... ]
The "2e" above may be a command field perhaps?
The boxes may be setup to echo their input commands I guess
perhaps in a slightly more terse manner..
I guess we don't know if it's a truncated CRC, checksum
or something else..
I think it would be interesting if you could unplug the USB cable and
programmatically (or via a serial program) generate commands by hand
to their software.. You could feed it slightly different data blocks
see how the software responds.. I'll have to stare at some
of the data some more to see if something jumps out at me..
Posted by Rick F on July 7, 2007, 12:42 am
Also notice that the 5-6 byte appears to have a sequence
about it for multi-line responses..I guess that allows
the PC to determine if something was dropped..
Posted by Christian Kaiser on July 7, 2007, 9:13 pm
pop the champagne! ;)
Big breakthrough today. I have found the checksum calculation
function!!! ;-) In disassembly, it's a horrendous complicated function,
but when deobfuscated (yes, they use an obfuscator!) it's quite trivial.
So now I can respond to the messages, and at the moment (my test
routine) I can query the configuration.
Enough of this phantastic feeling, back to the earth... I still have a
lot to find out, decipher, guess, ... but now I can start testing!
Of course I did notice that ;-) What remains unclear how the PC knows
that a sequence is finished.
Posted by Rick F on July 9, 2007, 7:03 pm
Excellent news! I guess being patient and staring incessantly at bits
pays off sometimes.. (8->
They may either suck up data until some very short timeout occurs
a handful of milliseconds?) or perhaps they embed a value before they
sending the "bunch" which tells the PC how many replies to expect
increasing sequence #'s in each record sent.. I'd be tempted to lean
the embedded side.. Let me know if you want some help staring at the
Posted by Christian Kaiser on July 10, 2007, 8:48 pm
Sorry, it takes loger than I would like it to, as I can only work in the
evenings during the week (and most weekends too, last saturday was an
exception that I will not repeat too often due to family restraints...)
This unfortunately means that I have at most half an hour to log the
data exchange, correct and verify the code that communicates with the
inverter, after that time it's getting dark and the inverter does not
respond any more. I will improve the code reliability and the logger
interface, meaning historical data for example.
I can now also get and set the date and time in the inverter. I know a
bit of the "current inverter state" data, but it's a rather strange byte
stream, so when I have enough data - I guess it will be friday evening I
have time again early enough to commmunicate with the inverter - I might
ask you for some ideas about the internal data structure of the
"inverter display" state.
I'm glad I'm not in the US and I need not care about DCMA - here in
Germany it's even explicitly allowed to reverse-engineer code if it's
for the purpose of data exchange and interoperability, which is exactly
what I do it for.
Fronius should have read some security books first before relying on
code obfuscation. "Security by obscurity does not work". If the only way
to get the data is reverse-engineering, someone will do it. If they
would have offered an acceptable way to get at the data (current data as
well as historical), no one would care about their "proprietary" protocol.