Verification problem - 0x9C

[janbalcarik]

Good day,

I have one more question for you. According to the discussions I found on the Internet. Your connection to the Loxone server for DI Extension worked.

I do not know if it is any change (I have a miniserver version 2), after adding an extension to the miniserver, the next packet will be sent.

Rx: 2423267568:907020F0, Command: F0, Data: 00 9C 10 00 1A 4A 88 E9 
Rx: 2423267569:907020F1, Command: F1, Data: 00 C4 DD 71 3B CE 8C 7C 
Rx: 2423267569:907020F1, Command: F1, Data: 00 36 3F AA E8 D2 37 E7 
Rx: 2423267569:907020F1, Command: F1, Data: 00 96 81 AA E8 D2 37 E7 

I assume that this is some kind of authentication packet 0x9C ... Because I do not respond to it, the Extension - (Authentication failed) will be blocked. In the previous version, this tot did not exist. Or did you figure it out?

Thank you

John

[janbalcarik]

I will add

in Loxone Monitor this is a message:

LNK send auth challenge to extension (DI Extension/14123456): 1

[sarnau]

My guess is that they are using the auth challenge, which was already used for the Tree Keypad Extension. That is annoying, but their scheme is inherently insecure – it's just a hack.

Downgrading to the previous version of the Loxone firmware probably avoids this for now – till I have time to look into it.

[janbalcarik]

I am using new hardware, ie (Miniserver 2). So I can't downgrade :(.

I have tested the AO and AI Extension and they work the same way.

Currently I have solved 100 inputs via Quido - PicoC and receive UDP packets, anyway "virtual" DI extension would be better ...

Anyway, thank you.

[sarnau]

If you do not go for Tree devices, but for other Extensions, like the "Extension" or the "Relay Extension" – it should still work, because it seems these were not changed to use a challenge/response scheme.

[SzilardS]

I've tried Extension and Relay extension emulation with 10.3.11.27. In the beginning Config shows extension online then after a few mins it shows Authentication failed :(

[sarnau]

The Extension software version has not been changed, it is still at 9.0.8.22. Maybe they expect newer extension version numbers to authorize and you accidentally set the version of the Extension to 10.3?

[sarnau]

Same with the DI Extension, it should still be at 10.2.2.28

[sarnau]

Ahh, 10.3.11.11 did not have this check, 10.3.11.27 does. They also updated the Extension, etc. for the first time in a while.

[chrisrock1984]

What kind of authentication is this?

[sarnau]

Various hash algorithms plus AES cobbled together, very similar, if not the same as the NFC Keypad. I didn't publish it, because I didn't want to break the encryption of the keypad publicly.

It seems they only to added it very recently to avoid home-brew extensions. That is extremely annoying and makes me rethink my approach.

[janbalcarik]

Is there a chance that you can still use your own extension?

If it is possible to find out and integrate the automation protocol into your documentation?

Respectively, there is always a chance, but I mean a real chance ...

[sarnau]

Miniserver 10.3.11.11 works fine today, Miniserver 10.3.11.27 has the authorization code.

And yes, the authorization is pointless, so it will be defeated.

They probably want to avoid commercial people building clones of their devices, but there are better ways to go after them (e.g. trademark laws) – annoying hobbyists and fans – not a good idea.

[sarnau]

Ok, clarification: Extensions and devices up to 10.3.11.5 don't require authorization.

[SzilardS]

Unfortunately I couldn't find that version on the net. Could you please upload the latest version that doesn't require authorization to somewhere? Thanks in advance

[sarnau]

I do not have it, never cared to keep it – I always keep the last major versions plus the current version.

[sarnau]

I've now documented the new Authorization scheme.