ELV Max! Hardware & Cube firmware

Forum about the home automation suites by ELV etc

Moderator: jrkalf

matthijskooijman
Member
Member
Posts: 62
Joined: Tue Oct 18, 2011 10:07 am

ELV Max! Hardware & Cube firmware

Post by matthijskooijman »

I haven't actually started using my Max! system yet, but I thought I'd take some components apart to see what's inside. I started with the cube. The cube opens easily using a flathead screwdriver to wedge the bottom out of the case (no screws, it just clicks in place). The casing is mostly empty: there is square PCB at the bottom, with a wire antenna stick out vertically, it seems the only reason the case is as high as it is is because of the antenna. There is a module with three transparent plastic tubes to get the LEDs on the PCB light up at the top of the casing. The PCB is attached to the casing using two Torx T6 screws.

The cube is powered by a Atmel at91sam7x512 ARM processor [info] [datasheet]. I suspect it is running at 18.432Mhz, since there is a crystal next to it labeled "H18.432A1".

There is a second chip, the Davicom dm9161aep [info], which is a 10/100 ethernet PHY. There is a crystel labeld "H25.000A1" next to it.

There is a third, tiny (8 pin) IC labeled "Atmel 1039 / 4508041d / 5V", for which I couldn't find any documentation (but I suspect this is a voltage regulator?).

There is a second small PCB soldered directly on to the main PCB, which probably contains all RF hardware. This second PCB also contains a wire antenna. The entire PCB is covered in a metal casing, so I don't know what is in there. On the main PCB, there is a label "TRX1"

There are quite some unconnected areas on the PCB. In particular, there is an area labeled "TRX2", with a two dozen soldering pads around it. This suggests that the PCB was designed with a second RF stack in mind (perhaps because the PCB is reused from another design?)

Here and there on the PCB there are copper pads labeled "MPx" (e.g., "MP1", "MP2", etc.). I suspect these pads are used for post-production QA and testing, but I'm not sure. It's hard to tell what they connect to and they're layed out seemingly random on the PCB. The Atmel processor also doesn't seem to have any pins labeled "MPx".

There is a port labeled "J1" (just two holes, no pins soldered on), whose function is unclear (no surface traces to follow, it's probably connected on a middle level of the PCB).

There is a port labeled "ST1" (just four holes, no pins soldered on). Following the traces from the middle two pads to the Atmel processor doesn't show where they're connected (they end up under the processor). However, assuming no pins are connected twice and no traces cross, it's likely they're connected to pins 81 and 82, which are PA0/RXD0 and PA1/TXD0 respectively. These pins are the data pins of the USART (serial port) on the processor, so that makes sense. I think the pads are connected as follows: VDD / TXD0 / RXD0 / GND (left-to-right, keeping the square pad at the left).

There is a port labeled "ST2" (just four holes, no pins soldered on). Following the traces from the middle two pads to the Atmel processor shows they're connected to pin 73 and 74, which are PA27/DRXD and PA28/DTXD respectively. These pins are some kind of debug port on the processor. I think the pads are connected as follows: VDD / DTXD / DRXD / GND (left-to-right, keeping the square pad at the left).

I have taken some pictures from both sides of the PCB, I'll try posting those later this week. Update: After over a year, I finally uploaded these pictures

The availability of a serial port is nice: If we can somehow manage to get a custom firmware onto the cube, that one can probably be used to connect a relais or opentherm module for controlling a kettle :-D
Cube PCB top.jpg
Cube PCB top.jpg (276.27 KiB) Viewed 24170 times
Cube PCB bottom.jpg
Cube PCB bottom.jpg (285.35 KiB) Viewed 24170 times
Radiator PCB top.jpg
Radiator PCB top.jpg (174.85 KiB) Viewed 24170 times
Radiator PCB bottom.jpg
Radiator PCB bottom.jpg (92.48 KiB) Viewed 24170 times
Radiator PCB RF.jpg
Radiator PCB RF.jpg (45.05 KiB) Viewed 24170 times
Last edited by matthijskooijman on Mon Jan 21, 2013 2:35 pm, edited 6 times in total.
Digit
Global Moderator
Global Moderator
Posts: 3388
Joined: Sat Mar 25, 2006 10:23 am
Location: Netherlands
Contact:

Re: ELV Max! Hardware

Post by Digit »

Nice job!
But knowing this, I think the first thing to do is understanding what the standard firmware does. How does it interact with the devices and where can this fw be modified to add the extras we'd like. Grabbing an encrypted fw image is only the first in a large number of milestones to accomplishing that goal.
I'm not trying to be pessimistic here, but only realistic. And love the challenge. I already have some ideas, like connecting the Cube to this; that would be the ultimate solution for me :)
matthijskooijman
Member
Member
Posts: 62
Joined: Tue Oct 18, 2011 10:07 am

Re: ELV Max! Hardware

Post by matthijskooijman »

Yeah, I know there is a lot to do before actually being able to change the firmware (if at all). But, at least the hardware seems to be present, so that's a start :-)

I'll see if I can solder on some pins onto those two serial ports later this week and see if anything shows up there.

Also, I noticed some QR-code stickers on the bottom of the print, labeled "MAC", "KEY", "RF" and "SN". Perhaps the "KEY" label is some kind of encryption key that might be useful later on. I assume the others are the mac address, serial number and RF address or something.
Digit wrote:I already have some ideas, like connecting the Cube to this; that would be the ultimate solution for me :)
That's something I have in mind for the longer term as well (I'll probably settle for a simple on/off relais at first, but I'm thinking about replacing my kettle to something that talks OpenTherm or whatever to be able to really talk to it ;-)
matthijskooijman
Member
Member
Posts: 62
Joined: Tue Oct 18, 2011 10:07 am

Re: ELV Max! Hardware

Post by matthijskooijman »

Small update on the debugging pins (see page 135 and onwards of the Atmel datasheet): Apparently the debug unit is enabled when:
1. An USB signal is detected on the USB device port. It should then expose a serial port, on which commands can be ran. I'm doubtful this will work, I half expect only the USB power pins to be connected and not the datapins.
2. "AutoBaudrate" detection works on the debug port (ST2 on the PCB). This is a normal UART, defaulting to 115200 8n1 settings. There is some handshake involving sending 0x80 twice and then "#" and receiving ">", but I haven't figured out how that is supposed to work. After this detection, this is a normal UART to the debug unit, that acccepts debugging commands.

Debugging commands include reading and writing the device's SRAM and starting executing. I suspect this is the main device's SRAM, not specific to the debug unit, but I'm not completely sure. Also, it seems you can't write to the flash from the debug unit, but you can probably upload a program that writes to the flash, I expect. The same probably goes for reading the flash.

No time to actually try the above, just wanted to share the stuff I theorized so far.
KidE
Member
Member
Posts: 61
Joined: Thu Jun 11, 2009 12:20 pm
Location: Netherlands

Re: ELV Max! Hardware

Post by KidE »

I just got the new ELV newsletter and i noticed that teh MAX cube is now also available in DIY format

elv.de/output/controller.aspx?cid=74&am ... fid=1201K1

The big advantage here is that the complete PCB layout and schematic are available.
matthijskooijman
Member
Member
Posts: 62
Joined: Tue Oct 18, 2011 10:07 am

Re: ELV Max! Hardware

Post by matthijskooijman »

Thanks for the tip! In addition to a DIY version of the cube (you get the parts and have to solder and assemble it yourself, though all SMD components are already soldered, just leaving two capacitors, the RF unit and the UTP connector), there's also a ELV Journal article about it. I went ahead and paid €0,99 to get the article, which includes a nice PDF version of the schematic. The article itself offers some insight in the scematic, but does not talk about stuff like the firmware or protocols used.

Things I've learned:
- My previous observations are all confirmed by the schematic or article.
- IC1 is really labeled "AT45DB041B-SI" (I misread DB for 08) and is a 4Mbit flash chip (not a voltage regulator, that's IC4).
- The USB data pins are connected, so you should be able to access the debug unit through the USB port, without having to solder on pins for the serial debug connection. The article actually mentions that there is hardware for an USB connection, which might become useful in later firmware updates (though there is a chance that the connection must actually be enabled from the firmware, there is some transistor connected to one of the data pins...).
- The solder pads labeled ST3 are connected to the microcontroller's JTAG port, for maximum debugging control.
- Neither the article or the schematic offers real insight in what the type of RF unit is used exactly. The name that looks the most like a model name is "TRX868", but I can't find anything with that model name that actually looks like the component itself. ELV doesn't seem to offer the TRX module either.
- The pins for programming the Flash memory directly are not connected (so they probably programmed the chip before soldering it on, or perhaps using the JTAG or debug ports?
- The J1 port can be used as a jumper: By connecting both pins, the ERASE signal of the internal Flash chip in the microcontroller is pulled high, causing the internal flash and some "NVM bits" to be erased.
- There is a chance that the microcontroller is configured to boot from Flash directly, bypassing the builtin ROM bootloader / debug stuff. So it might be needed to do a Flash erase before the debug port can be used (but that would prevent reading the current firmware, which would suck...).
KidE
Member
Member
Posts: 61
Joined: Thu Jun 11, 2009 12:20 pm
Location: Netherlands

Re: ELV Max! Hardware

Post by KidE »

Eyy i know that TRX868. I think this is the same tranceiver unit used in the Homematic devices from ELV . MAybe this hint will help

You cen get such a unit by buying a Homematic device and remove the TRX unit
robin26
Starting Member
Starting Member
Posts: 2
Joined: Tue Mar 06, 2012 3:01 pm

Re: ELV Max! Hardware

Post by robin26 »

Hi,
I'm new here and I wondered if anyone has captured a firmware upgrade via wireshark. So maybe it is possible to:
- extract firmware image from dump
- find out more about flashing mechanism
Finding out how the original software operates is sure a very important first step, but then before flashing a totaly different firmware on the device it would be nice to know a way back to the original firmware.
Do they do sth. like a tftp boot for flashing the device?
My cube (DIY kit) is still somewhere in production... have to wait to get my fingers on it.

robin
matthijskooijman
Member
Member
Posts: 62
Joined: Tue Oct 18, 2011 10:07 am

Re: ELV Max! Hardware

Post by matthijskooijman »

I'm still planning to get that tcpdump, but so far, I've had no time to really play with my gear yet...
matthijskooijman
Member
Member
Posts: 62
Joined: Tue Oct 18, 2011 10:07 am

Re: ELV Max! Hardware

Post by matthijskooijman »

I managed to get a dump of the firmware update process. Unfortunately, it is an update to the most recent version, so I can't capture any subsequent updates (I wanted to do an update with an old version of the software, but that didn't work because of, what became clear later, my network setup).

In any case, I have a full dump here, I can share it if anyone is interested. Some first observations:

All communication happens over UDP, using source and dest port 23272. This same protocol is used for device discovery. According to the UI (and the application log file), firmware update happens in steps: Entering the bootloader, Writing firmware, rebooting. I suspect that entering the bootloader means to make the Cube reboot and then send packets at it that puts the bootloader in a special "receive firmware" mode.

The discovery request packet is sent to 255.255.255.255 first, then to
240.0.0.1. After the discovery reply is received, the software sends networksocket.inet_ntoa
info discovery packets to 240.0.0.1, all other packets directly to the Cube
IP. The Cube sends all packets to 255.255.255.255.

Discovery
As for the actual packets, they're mostly small. The discovery request packet is 19 bytes long and looks like this:

Code: Select all

0000   65 51 33 4d 61 78 2a 00 2a 2a 2a 2a 2a 2a 2a 2a  eQ3Max*.********
0010   2a 2a 49                                         **I

6  bytes "eQ3Max"     Magic fixed string?
2  bytes "*\00"       Sender: *
10 bytes "**********" Serial number? ********** means "any"?
1  byte  49           Request / Reply type (matches the reply)
The reply is 26 bytes long. Before the upgrade, it looks like this:

Code: Select all

0000   65 51 33 4d 61 78 41 70 49 45 51 30 31 31 33 31  eQ3MaxApIEQ01131
0010   38 30 3e 49 00 00 b8 25 01 00                    80>I...%..
After the upgrade, it looks like this:

Code: Select all

0000   65 51 33 4d 61 78 41 70 49 45 51 30 31 31 33 31  eQ3MaxApIEQ01131
0010   38 30 3e 49 00 00 b8 25 01 11                    80>I...%..
Looking at the H response in the TCP protocol, we can already deduce some
parts of this reply packet:

Code: Select all

H:IEQ0113180,00b825,0111,00000000,7afb8834,05,32,0d0112,1507,03,0000
The log entry from the application also helps a bit:

Code: Select all

[CubeInfo(firmwareVersion=256, ipAddress=192.168.10.162, serialNumber=IEQ0113180, inBootLoader=false)]
It seems my firmware version is 0111, so the last two bytes must be the
firmware version.

Code: Select all

6  bytes "eQ3Max"     Magic fixed string?
2  bytes "Ap"         Sender: application
10 bytes "IEQ0113180" Serial number
2  bytes 3e           ?? All replies have this
1  byte  49           Request / Reply type (matches the request)
1  byte  00           ?? (inbootloader?)
3  bytes 00b825       RF address
2  bytes 0111         Firmware version
It seems the software sends another discovery request:

Code: Select all

0000   65 51 33 4d 61 78 2a 00 49 45 51 30 31 31 33 31  eQ3Max*.IEQ01131
0010   38 30 4e                                         80N
This request is a request for the Cube's network info (looking at the reply).
The software now knows the Cube's serial number, so that one is put in all
requests from this one.

The reply to this contains a lot of information.

Code: Select all

0000   65 51 33 4d 61 78 41 70 49 45 51 30 31 31 33 31  eQ3MaxApIEQ01131
0010   38 30 3e 4e c0 a8 0a a2 c0 a8 0a 01 ff ff ff 00  80>N............
0020   c0 a8 0a 01 00 00 00 00                          ........

6  bytes "eQ3Max"     Magic fixed string?
2  bytes "Ap"         Sender: application
10 bytes "IEQ0113180" Serial number
2  bytes 3e           ?? All replies have this
1  byte  4e           Request / Reply type (matches the request)
4  bytes c0a80aa2     Cube's IP (192.168.10.162)
4  bytes c0a80a01     Cube's gateway (192.168.10.1)
4  bytes ffffff00     Cube's netmask (255.255.255.0)
4  bytes c0a80a01     Cube's primary DNS (192.168.10.1)
4  bytes 00000000     Cube's secondary DNS
A third request is sent, now to the IP of the Cube instead of a broadcast.
This request is identical to the first request, except that the serial number
is now filled in. The reply is identical to the first reply. Presumably the
software does this to verify that the Cube is actually reachable on the IP
address it advertised.

Enter bootloader

The next request is probably the "enter bootloader" request.

Code: Select all

0000   65 51 33 4d 61 78 2a 00 49 45 51 30 31 31 33 31  eQ3Max*.IEQ01131
0010   38 30 42                                         80B

6  bytes "eQ3Max"     Magic fixed string?
2  bytes "*\00"       Sender: *
10 bytes "IEQ0113180" Serial number
1  byte  42           Request / Reply type (matches the reply)
And the reply:

Code: Select all

0000   65 51 33 4d 61 78 41 70 49 45 51 30 31 31 33 31  eQ3MaxApIEQ01131
0010   38 30 3e 42 02                                   80>B.

6  bytes "eQ3Max"     Magic fixed string?
2  bytes "Ap"         Sender: application
10 bytes "IEQ0113180" Serial number
2  bytes 3e           ?? All replies have this
1  byte  42           Request / Reply type (matches the request)
1  byte  02           Result code?
After this, the software sends another request that remains unanswered. It
repeats the request, the fifth request (after 8 seconds) gets answered.

The request is identical to the the second request (get network info), but the reply is subtly different:

Code: Select all

0000   65 51 33 4d 61 78 42 6c 49 45 51 30 31 31 33 31  eQ3MaxBlIEQ01131
0010   38 30 3e 4e c0 a8 0a a2 c0 a8 0a 01 ff ff ff 00  80>N............
0020   c0 a8 0a 01 00 00 00 00                          ........

6  bytes "eQ3Max"     Magic fixed string?
2  bytes "Bl"         Sender: bootloader
10 bytes "IEQ0113180" Serial number
2  bytes 3e           ?? All replies have this
1  byte  4e           Request / Reply type (matches the request)
4  bytes c0a80aa2     Cube IP (192.168.10.162)
4  bytes c0a80a01     Cube's gateway or DNS IP (192.168.10.1)
4  bytes ffffff00     Cube's netmask (255.255.255.0)
4  bytes c0a80a01     Cube's gateway or DNS IP (192.168.10.1)
4  bytes 00000000     ?? (Secondary DNS?)
The software sends another identical request (shortly) after this, with the
same reply again, probably the request and reply crossed each other.

Then, it sends one more request:

Code: Select all

0000   65 51 33 4d 61 78 2a 00 49 45 51 30 31 31 33 31  eQ3Max*.IEQ01131
0010   38 30 55                                         80U

6  bytes "eQ3Max"     Magic fixed string?
2  bytes "*\00"       Sender: *
10 bytes "IEQ0113180" Serial number
1  byte  55           Request / Reply type (matches the reply)

Code: Select all

0000   65 51 33 4d 61 78 42 6c 49 45 51 30 31 31 33 31  eQ3MaxBlIEQ01131
0010   38 30 3e 55 01                                   80>U.

6  bytes "eQ3Max"     Magic fixed string?
2  bytes "Bl"         Sender: bootloader
10 bytes "IEQ0113180" Serial number
2  bytes 3e           ?? All replies have this
1  byte  55           Request / Reply type (matches the request)
1  byte  01           Result code?
Sending data

Looking at packet sizes, this is where the actual data transfer starts. There
are a lot of similar packets, still in request/reply pairs. The requests seem
to alternate between a big packet (297 bytes) and a smaller packet (41 bytes,
except for the last one, which is 57 bytes).
The replies are all 23 bytes.

Here's the first four pairs:

Code: Select all

0000   65 51 33 4d 61 78 2a 00 49 45 51 30 31 31 33 31  eQ3Max*.IEQ01131
0010   38 30 57 00 00 01 12 1e d3 68 43 f6 fd c5 ae 9c  80W......hC.....
0020   a1 db 2a 37 0c 9b 15 86 78 9c b7 30 9c 0d 6d d6  ..*7....x..0..m.
0030   43 5f 1e 70 6c af 42 62 33 af bd b2 4a 94 f1 28  C_.pl.Bb3...J..(
0040   eb fd b8 96 74 8e 3a e4 bf b3 b6 fb bb 40 53 13  ....t.:......@S.
0050   0a ed 2b f3 1b f3 f5 3e 22 69 12 16 17 f8 be 76  ..+....>"i.....v
0060   37 09 9c 45 59 8b 0b eb a8 16 63 8c f1 72 9e db  7..EY.....c..r..
0070   ca 08 69 5b d7 a6 ae ed 45 db fb cb 2d a6 c1 f5  ..i[....E...-...
0080   b9 0b aa 17 29 f3 52 54 46 2b b3 88 39 7e 71 66  ....).RTF+..9~qf
0090   3c 99 84 57 92 ca ca 74 62 05 6a 29 2c bd 03 7a  <..W...tb.j),..z
00a0   02 f1 5f 91 13 a0 0b aa 11 d6 45 28 3a 4a e3 5c  .._.......E(:J.\
00b0   c3 c1 5b c0 0c aa 5c 5a 13 82 c6 44 1a d0 6d fd  ..[...\Z...D..m.
00c0   bc 9e 57 15 82 04 b9 c7 66 0d 13 2a 81 81 e7 f7  ..W.....f..*....
00d0   99 65 dc 58 e1 30 3f 32 78 ef b1 7c 28 c4 61 c0  .e.X.0?2x..|(.a.
00e0   a5 ba 1a 8d 02 51 03 cc 74 e1 6f 6d f3 58 d5 1d  .....Q..t.om.X..
00f0   66 57 fc 10 6a db 76 11 d7 4c a5 44 e4 56 ad 7a  fW..j.v..L.D.V.z
0100   9f d9 27 0f 28 b7 dd 76 9f 98 f1 6d b8 5b cc 17  ..'.(..v...m.[..
0110   f2 69 24 20 f5 9f 6b 3a af e4 dc a5 72 c7 83 35  .i$ ..k:....r..5
0120   66 0e 92 c7 d9 d1 b7 56 cc                       f......V.

0000   65 51 33 4d 61 78 42 6c 49 45 51 30 31 31 33 31  eQ3MaxBlIEQ01131
0010   38 30 3e 57 01 00 00                             80>W...

0000   65 51 33 4d 61 78 2a 00 49 45 51 30 31 31 33 31  eQ3Max*.IEQ01131
0010   38 30 57 00 01 00 12 a1 f7 88 b0 1f b6 f5 be c5  80W.............
0020   c2 5b dc 55 fe 39 be f1 41                       .[.U.9..A

0000   65 51 33 4d 61 78 42 6c 49 45 51 30 31 31 33 31  eQ3MaxBlIEQ01131
0010   38 30 3e 57 01 00 01                             80>W...

0000   65 51 33 4d 61 78 2a 00 49 45 51 30 31 31 33 31  eQ3Max*.IEQ01131
0010   38 30 57 00 02 01 12 70 d8 b8 5a ed 42 34 7f 49  80W....p..Z.B4.I
0020   db 04 92 24 63 ff ab 27 4e d8 64 57 b1 ac ae e2  ...$c..'N.dW....
0030   fb 3a b6 0d 5f 7c 8f d6 31 47 ba 6e 9e 8c da 66  .:.._|..1G.n...f
0040   3a 98 6b ab 5c 51 f3 9f 52 d5 76 24 c7 bf d1 25  :.k.\Q..R.v$...%
0050   74 3c 0a 6e 09 9b fa 1d f2 fb 8e c0 cf d1 39 54  t<.n..........9T
0060   55 8f c5 93 01 7c 61 3c 6d 95 7d 32 f6 2c 6c 27  U....|a<m.}2.,l'
0070   79 b3 08 15 cc 75 1e f7 8c ab 98 e0 ea 24 2a ab  y....u.......$*.
0080   3f 3f 63 51 f2 e9 19 46 96 bf ad dd 83 23 df 6e  ??cQ...F.....#.n
0090   e4 d4 43 83 77 da c4 0e 97 8e d7 42 b4 6c cc b4  ..C.w......B.l..
00a0   84 da eb 5f 5c a6 27 be 9c 5f bc 18 20 46 db b2  ..._\.'.._.. F..
00b0   13 4d f6 08 fa e5 1d f8 67 ab 02 11 ab b7 a5 80  .M......g.......
00c0   db 44 cc 4d 9a 5d ee 2a 70 52 0f 00 e7 55 3c 47  .D.M.].*pR...U<G
00d0   4c 68 b1 a8 11 ee 92 b6 a0 70 d8 f2 b3 a4 db 87  Lh.......p......
00e0   fc 77 27 1a 60 62 a8 72 56 97 16 96 1a 51 8d c3  .w'.`b.rV....Q..
00f0   4c 9a 0e 3c 34 7c b3 6c 6b 85 ec c9 6f 4c fd 80  L..<4|.lk...oL..
0100   e4 03 c3 c5 97 10 06 c2 68 41 5a 95 0d 1f f7 6a  ........hAZ....j
0110   9b 6a 4f 57 37 29 cd 18 b6 53 ac 97 5f eb d0 eb  .jOW7)...S.._...
0120   00 02 b7 b2 ae 17 3e 43 41                       ......>CA

0000   65 51 33 4d 61 78 42 6c 49 45 51 30 31 31 33 31  eQ3MaxBlIEQ01131
0010   38 30 3e 57 01 00 02                             80>W...

0000   65 51 33 4d 61 78 2a 00 49 45 51 30 31 31 33 31  eQ3Max*.IEQ01131
0010   38 30 57 00 03 00 12 7c 19 56 d4 f6 a7 7e 14 2a  80W....|.V...~.*
0020   03 45 0d c7 9b 14 c5 b5 d0                       .E.......

0000   65 51 33 4d 61 78 42 6c 49 45 51 30 31 31 33 31  eQ3MaxBlIEQ01131
0010   38 30 3e 57 01 00 03                             80>W...

Code: Select all

Request:

6  bytes "eQ3Max"     Magic fixed string?
2  bytes "*\00"       Sender: *
10 bytes "IEQ0113180" Serial number
1  byte  57           Request / Reply type (matches the reply)
2  bytes 0000         Packet count (this increments, last request has 047d)
2  bytes 0112         Data size (matches the number of bytes next)
 x bytes              Data

Reply:
6  bytes "eQ3Max"     Magic fixed string?
2  bytes "Bl"         Sender: bootloader
10 bytes "IEQ0113180" Serial number
2  bytes 3e           ?? All replies have this
1  byte  57           Request / Reply type (matches the request)
1  byte  01           "Need more" code? Last reply has 02 here
2  bytes 0000         Packet count (this increments, last reply has 047d)
Interestingly enough, the last packet (which should have been 41 bytes) is 57
butes long (but the structure is the same as the others). It would have made
sense if a 297 byte packet was shortened to account for a odd firmware size,
but it's weird that a 41 byte packet is lengthened...

Reboot

I suspect the Cube does an automatic reboot now. The software sense a few
"network info discovery" packets again. Interestingly, it sends five to
240.0.0.1 and the sixth and seventh go to 255.255.255.255. The seventh (after
12 seconds) gets answered, again with the same reply we've seen before.

After this, the UDP protocol seems complete, the software connects using the
TCP protocol now.



Summary

There's still some blanks in the protocol, but I guess this would be enough to
implement our own firmware flashing tool if needed (if we can figure out the firmware
format, of course).

I'll try to extract the complete data file out of the packet dump sometime soon and post it here. A quick calculation shows it should contain ((0x047D + 1) / 2) * (274 + 18) + (57 - 41) == 167916 bytes (probablly including some kind of checksumming).



Some other notes, not completely related, but just to keep them somewhere:

I also found this directory, which seems to contain the javascript stuff needed for the Max! application:
C:\Documents and Settings\<username>\Local Settings\Temp\Jetty_0_0_0_0_18765_root.war___.ngpk47

I also found this directory, which contains reasonably verbose logfiles from the application:
C:\Documents and Settings\<username>\.MAX\logs

Finally, it seems that the application itself is downloaded / cached into this directory:
C:\Documents and Settings\All Users\Application Data\MAX
matthijskooijman
Member
Member
Posts: 62
Joined: Tue Oct 18, 2011 10:07 am

Re: ELV Max! Hardware & Cube firmware

Post by matthijskooijman »

I wrote a small python script to dissect a pcap file containing UDP packets using this protocol. I've also used this script to obtain a firmware file. You can find the script here:

http://www.stdout.nl/static/files/ELV%2 ... irmware.py

A first glance at the firmware file shows nothing familiar. Running the ARM disassembler on it seems to return mostly garbage, so the file is probably encrypted in some way. The captured firmware data is here:

http://www.stdout.nl/static/files/ELV%2 ... re-273.bin


I also learned that the net info packet indeed contains gateway, primary and secondary dns, I edited this in my above post. I also fixed some small mistakes in that post.

I've also been able to succesfully send discover and net info request packets to my cube using netcat. I noticed that the net info request must have a valid serial number, the Cube doesn't respond if you put in ********** as the serial, which does work for the discover packet.
matthijskooijman
Member
Member
Posts: 62
Joined: Tue Oct 18, 2011 10:07 am

Re: ELV Max! Hardware & Cube firmware

Post by matthijskooijman »

I soldered on some pins to ST1 and ST2 and got some results.

Connecting a USB->TTL serial convertor to ST2 (with the pinout I described in my first post, VDD / TX / RX / GND) and using 115200 8n1, I got the following output:

Code: Select all

Bootloader...
Starting application.


Application...


MAX!-LAN-Gateway --- <SW: 273> - <HW: 3> - <RL: 423> - <SU: 14> - <TS: 00>
MAC-address: 00-1A-22-00-DF-97
Serial:      IEQ0113180
RF-address:  0x00B825

DeviceManager has monitor id 0
DeviceManager: 1 devices in Dataflash
DeviceManager: Found device in Dataflash. Address: 0x0131B4
RFCom has monitor id 1
Time 1.1.11 7:0:0 dow=6 utc_off=2
Network has monitor id 2
Control has monitor id 3
TCP server is now listening on port 62910
[DATAFLASH OK]
[TRANSCEIVER OK]
[ETHERNET PHY OK]
[TASKS OK]
DHCP timeout.
DHCP->ip-address:           192.168.0.222
DHCP->default-gateway:      192.168.0.1
DHCP->netmask:              255.255.0.0
DHCP->primary DNS-server:   192.168.0.1
DHCP->secondary DNS-server: 0.0.0.0
It seems this port does not accept any input (probably the application doesn't have any shell running or something).
I would have expected something like this on ST1, the serial port, not ST2, the debug port. But perhaps the debug port is available to the application as a second serial port or something if the debug unit is not active, dunno.

I haven't been able to get any output from ST1, using 9600, 57600 or 115200.

Looking once more at the specs, it seems the atmel chip has 512Kbytes of Flash built in. Given that the firmware flash only sent 160 Kbyte, this makes me wonder why there is an external 4Mbit (== 512Kbyte) flash chip on the board?

I tried to trigger the debug unit by writing some 0x80 value to the debug port, but that didn't seem to work. Reading the spec more closely, it seems that the builtin bootloader that can trigger the debug unit can actually do _only_ that, so it is intended for uploading a program and debugging that, not to debug an existing program running from Flash...

So, one more option to get at the firmware would be the JTAG port, but I'll need to get some JTAG hardware for that first...
Kingsammy
Starting Member
Starting Member
Posts: 17
Joined: Mon Dec 19, 2011 11:10 am

Re: ELV Max! Hardware & Cube firmware

Post by Kingsammy »

@matthijskooijman: You can find the original firmware file called "firmware.enc" in the original software application, when you have a closer look @ file MaxSettings.jar.

You have to open the MaxSettings.jar with e.g. 7Zip and so you can extract the firmware.enc file.
The fimware file is really encoded/decoded. You can find the code using a Javadisassembler "JD-GUI" with file "MAXLocalBackend-1.3.6.jar" - section "update" --> FirmwareFile.class.
Hope this will help you to get the original Cubes firmware.
Kingsammy
Starting Member
Starting Member
Posts: 17
Joined: Mon Dec 19, 2011 11:10 am

Re: ELV Max! Hardware & Cube firmware

Post by Kingsammy »

And here is the Javacode of the FirmwareFile.class

Code: Select all

package de.eq3.max.al.local.update;

import de.eq3.max.al.local.update.exceptions.InvalidFirmwareFileUpdateException;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.LinkedList;
import java.util.List;

public class FirmwareFile
{
  private final List<byte[]> frames;

  public FirmwareFile(InputStream stream)
    throws InvalidFirmwareFileUpdateException
  {
    this.frames = new LinkedList();
    parse(stream);
  }

  public List<byte[]> getFrames()
  {
    return this.frames;
  }

  private void parse(InputStream stream) throws InvalidFirmwareFileUpdateException
  {
    try
    {
      readFrames(stream);
    }
    catch (IOException ex)
    {
      throw new InvalidFirmwareFileUpdateException(ex);
    }
  }

  private void readFrames(InputStream stream) throws IOException
  {
    this.frames.clear();

    byte[] frame = readFrame(stream);
    while (frame != null)
    {
      this.frames.add(frame);
      frame = readFrame(stream);
    }
  }

  private byte[] readFrame(InputStream stream) throws IOException
  {
    int length = readLength(stream);
    if (length > 0)
    {
      return readFrameData(stream, length);
    }

    return null;
  }

  private int readLength(InputStream stream)
    throws IOException
  {
    int high = readByte(stream);
    int low = readByte(stream);

    return high << 8 | low;
  }

  private byte[] readFrameData(InputStream stream, int length) throws IOException
  {
    ByteArrayOutputStream outStream = new ByteArrayOutputStream();

    for (int i = 0; i < length; i++)
    {
      int value = readByte(stream);
      outStream.write(value);
    }

    byte[] result = outStream.toByteArray();
    outStream.close();
    return result;
  }

  private int readByte(InputStream stream) throws IOException
  {
    int high = stream.read();
    int low = stream.read();

    return createByte(high, low);
  }

  private int createByte(int high, int low)
  {
    return fromHex(high) << 4 | fromHex(low);
  }

  private int fromHex(int value)
  {
    if ((48 <= value) && (value <= 57))
    {
      return value - 48;
    }
    if ((97 <= value) && (value <= 102))
    {
      return value - 97 + 10;
    }
    if ((65 <= value) && (value <= 70))
    {
      return value - 65 + 10;
    }

    return 0;
  }
}
matthijskooijman
Member
Member
Posts: 62
Joined: Tue Oct 18, 2011 10:07 am

Re: ELV Max! Hardware & Cube firmware

Post by matthijskooijman »

Awesome, thanks for these pointers, now I can have a look at the java sources as well. Amazing how much of the original structure is still there :-)

Also, amazing how braindead the code looks. The FirmwareFile class completely implements hex decoding from scratch, while there must be some useful library functions to at least do parts of this decoding (Not to mention the fact that there doesn't seem any reason to actually use hex encoding here, just storing the binary stuff directly would make a lot more sense). Oh well.

In any case, the firmware.enc format is simple: Every two characters in the file are on hex-encoded bytes (e.g., "5E" means a byte value of 0x5e). The file further consists of frames, where each frame corresponds to one UDP packet during the firmware update. Each frame consists of two bytes for the length (big-endian, so "0112" translates to 0x112 == 274), followed by that many bytes for the frame content. Using this decoding, the contents of the firmware.enc are identical to the content I previously captured using wireshark.

The actual format of the firmware itself is still a mystery, of course. Given the fact that the data is embedded in the software in this format already, it seems unlikely that the java sources will provide any more clues as to the format of this file...


I've updated my extract_firmware.py file to also extract these firmware.enc files and include a few more request types (reboot, get/set network config, get/set url).

Interesting to see that the application only parses the IP address out of a network info response, all the other data is completely ignored...
Post Reply

Return to “Homematic, FS20, FHT, ESA and ELV”