Closed thomas-br closed 2 years ago
Same here... looks like their domain transfer went wrong. I'm looking into all sorts of options. I'd love to get the Nello Hardware going (this seems rather complex and would be my last resort).
I have gotten the Nello one to talk to my local MQTT server. Receiving notifications in case the door bell rings works fine. I wasn't able to trigger the door buzzer though. Systematically sending the right commands while at the same time forcing the Nello to reconnect appears to be not feasible in my setup...
So probably the next step is to try to find out the encryption mechanism... Any ideas anyone?
I wonder if it would be easier to simply write a custom firmware for the nello. It would be alot of work to write the code to communicate with the doorbell initially,but it would have the positive of being able to support new devices. Unfortunately my nello is not working, it's missing a part, (i think it's the voltage reg, but i don't know the part number) so I can't try reverse engineering the actual firmware.
because i wouldn't be able to test it i mean
Hey colleagues,
@thomas-br, your assumption is correct. I'll have a look on that and'll also check if we can figure out a way to RE the mapping.
@OnkelKeule, good to hear that the bell notification solution does work for you. Yeah, there are a lot of setups and reasons, where and why you don't want to force nello to reconnect. I see two further opps: either it possible to decipher and decrypt all the messages by analyzing the traffic (even by replaying the traffic...) or it is possible to reverse engineer the FW, in order to know how the system behaves correctly - as @Atanasovgoran also said.
I use my solution (the full BE impl.) since march this year and it works quite well. But sometimes, I have to admit, waiting for 10-12 seconds is a bit annoying ;-).
Maybe I can provide you another hint I figured out in march, but did not make public yet. Sclak prob. did move all user accounts from nello to its system (at least my account) - without even asking me for my user account permissions - that is really really sad.. I was able get into the sclak system by simply "trying to reset" my password via: https://admin.sclak.com/#/forgot and they provided me all the information I needed to login. Having said that, you're then able to retrieve a valid Access Token to their APIs via
[POST] https://api.sclak.com/auth_tokens (body: something like {"username": "myuser@mail.com", "password": "myPw"}).
Afterwards you can call the Firmware API (all their Firmwares are listed there and can be downloaded): https://api.sclak.com/firmwares
From my RE tasks back in march, I think that the Nello device firmwares are already listed there (just my guess). Firmware Ids: 39, 40, 41 ,42 (all the ULock stuff things). But unfortunately, these four firmwares are just set up as a placeholer without any data in it. Checksum = d41d8cd98f00b204e9800998ecf8427e (MD5 Hash of an empty string).
Maybe we've to wait... I don't know. Maybe it will help you guys with your further analysis.
{
"id": "42",
"version": "1.05",
"checksum": "d41d8cd98f00b204e9800998ecf8427e",
"notes": "Ulock 1.05",
"peripheral_type_id": "2",
"peripheral_type_code": "ulock",
"beta": "0",
"support_pin": "0",
"support_upgrade": "0",
"support_battery": "0",
"upgrade_mandatory": "0",
"insert_time": "1444063305",
"edit_time": "1444063305"
},
{
"id": "41",
"version": "1.04",
"checksum": "d41d8cd98f00b204e9800998ecf8427e",
"notes": "Ulock 1.04",
"peripheral_type_id": "2",
"peripheral_type_code": "ulock",
"beta": "0",
"support_pin": "0",
"support_upgrade": "0",
"support_battery": "0",
"upgrade_mandatory": "0",
"insert_time": "1444063305",
"edit_time": "1444063305"
},
{
"id": "40",
"version": "1.02",
"checksum": "d41d8cd98f00b204e9800998ecf8427e",
"notes": "Ulock 1.02",
"peripheral_type_id": "2",
"peripheral_type_code": "ulock",
"beta": "0",
"support_pin": "0",
"support_upgrade": "0",
"support_battery": "0",
"upgrade_mandatory": "0",
"insert_time": "1444063305",
"edit_time": "1444063305"
},
{
"id": "39",
"version": "1.0",
"checksum": "d41d8cd98f00b204e9800998ecf8427e",
"notes": "Ulock 1.0",
"peripheral_type_id": "2",
"peripheral_type_code": "ulock",
"beta": "0",
"support_pin": "0",
"support_upgrade": "0",
"support_battery": "0",
"upgrade_mandatory": "0",
"insert_time": "1444063305",
"edit_time": "1444063305"
},
Cheers Lars
That's interesting. Can anyone post a picture of the PCB, it may help me find the broken component and fix it. I could then tryand helpwiththe reverse engineering
@Atanasovgoran - here's a picture of the front (took it a while ago... hope it helps):
@LFE89 - I just tried to reset my pw at sclak and reveived an error message. Seems like my account was not transferred...
yes i can see the part i am missing, seems to be a battery or a supper cap, will have to search for it when i am home
@OnkelKeule , that is quite interesting. Why did they then migrate my account... I can even see that they did that prob. already on 19.02.2020.
My tests through the inofficial Sclak API back in march were all successful, because they either redirected the requests to the origin BE or already owned the infrastructure....
@OnkelKeule Did you try to create an account with your nello mail address? I remember that I got a strange error message, that it is not possible by using that mail address. Afterwards I tried the reset password thing...
@LFE89 - seems to be Italian style. I'm using gmail's "+", which obviously Sclak can't handle. So was able to register a new account (which I won't be able to use, as I can't very my email adress) but Sclak got it wrong:
Same here. Can login to Sclak after password reset but Nello is not working. DNS request to live-mqtt.nello.io results in NXDOMAIN. Could test customized firmware
Does anybody know a source of the existing nello firmwares other than maybe in the future at the sclak firmware api?
I guess when I didn't get this set up while the service was working (to capture packets), I am out of luck now until the official service comes back up?
@AfromD unfortunately yes. As long as we are not able to create new valid „test“-messages by our own, you need at least one recorded message (to support door open commands)... Maybe, it should be checked if „test“-messages from other nello devices may work for other devices as well. I am not convinced, because they prob. include unique device identifier or signature information to prohibit that, but maybe it is worth trying.
Maybe, it should be checked if „test“-messages from other nello devices may work for other devices as well. I am not convinced, because they prob. include unique device identifier or signature information to prohibit that, but maybe it is worth trying.
@LFE89 Wouldn't that be a huge security hole? A local attacker would use ARP spoofing to direct Nuki to his server, and then just serve up prerecorded packets from anywhere to unlock a door.... I might want to get the Nuki opener just as well if that proves to be true...
@AfromD the security issue already exists - also in another manner. In the „old“ cloud environment. Any nello user, or let’s say any user who has access to a valid nello id (just the id), could connect to the mqtt broker and read all the messages, of each nello device. Including the test messages. And the fact, that there is prob. a misconfigured BE or a bug in the fw (still needs to be proven) which lead in my online scenario test to 15-20 minutes reconnects, let attacker to not wait long time to capture the right packets. Only the restricted write access to the specific topic prohibited further access. Employees prob. had access to that topic and could have control all locks within that attack scenario, without knowing any users sensitive data / passwords .
And yes. By doing a dns/arp spoofing attack, an attacker could do that locally. There is no way to prevent that with the current firmware.
The attacker just had to do the following things:
One thing that I don't understand: with Nello working I always received a Push notification when I pressed the buzzer to open the door. With Nello using my local mqtt server, I don't see any communication whe I press the buzzer. How's that explained? Confuses me...
Since the migration from nello to Sclak I never got any ring notification anymore
Looks like live-mqtt.nello.io is responding now. Haven't tried it out yet, but might be viable to catch the message again.
@LFE89 Looks like im migrated too, on Feb 19. Have you seen this? FHEM I have used this a long time to get Nello into HomeKit and they got the whole communication working.
Looks like live-mqtt.nello.io is responding now. Haven't tried it out yet, but might be viable to catch the message again.
the error message is gone but neither unlocking nor ring-push is working
Looks like live-mqtt.nello.io is responding now. Haven't tried it out yet, but might be viable to catch the message again. the error message is gone but neither unlocking nor ring-push is working
Same here
@LFE89 Looks like im migrated too, on Feb 19. Have you seen this? FHEM I have used this a long time to get Nello into HomeKit and they got the whole communication working.
There are a lot of such solutions in place. But all of them make use of either the official (a long time ago you just could request an official API account) or inofficial API (the API the original app used) and therefore have a dependency on the public cloud backend.
Looks like live-mqtt.nello.io is responding now. Haven't tried it out yet, but might be viable to catch the message again. the error message is gone but neither unlocking nor ring-push is working
Same here
Hope you can record your relevant mqtt messages.
to be honest, i would be more interested in a custom firmware. nello cloud api failed often enough now...
@secuninja totally agree. But you can try my non-cloud solution (without nello cloud api dependencies) as long as there is no other firmware available.
Hello,
for now I can use my migrated Sclak account by reset my password. Furher I can log in into the Sclak App, but my Nello is still not working at the moment.
Alex
ditto... not working at all
Looks like its working again. The Device became today reponsive again in Homebridge. Even the Api with token creation is up and running again.
Yes, it works. Thanks for the information @thiroxx :-)
But please keep in mind, that the security issue still persists (4.3. Control nello (the attack)) in the current SCLAK cloud & FW solution.
IMHO it is important to know about the security issue, then it is up to the customers if they are willing to take the risk explicitly or not. Unfortunately neither Nello nor Sclak commented on the issue I reported back in february. So take care...
One update from my end. I recorded again some reset / setup flows as tcpdump. Basically no new insights besides what is already shared by @LFE89 in his Readme.
Interesting are indeed the encrypted messages. I am wondering whether it is based on a static key for all nellos, a static one put into the hardware during manufacturing or exchanged / constructed out of the blinking which syncs the wifi information.
Some more thoughts... I opened also my nello for find a way to get the encryption key which seems to be put into the device during manufacturing (that at least what the nello product page says) and is used for the AES-256 encryption. I mean sometimes such keys are even included as a QR (or similar) code onto the board [1]. Besides the MAC-QR I found another one on the back of my nello IC-board. Unfortunately it only contains a 10-digit number (starting with 994...
)
I though dumping the binary data from the flash chip could also be worth a try [2] [3] I was not able to locate an isolated flash chip where we can hook a SOIC clip to. As the nellos use a ATWINC1500/ATWINC1510 which also contains afaik 8MB flash and OTA support. So the firmware might be contained in here, or what do you think? Or is it really just for the Wifi connectivity?
Does anybody has an idea how we could dump a .bin
?
Thanks for your work. Just found it now as it seems that the original server is down again...
Thanks for your work. Just found it now as it seems that the original server is down again...
Since yesterday nello hasn’t a connection to the Sclak server. Tomorrow I will try to setup your solution without cloud. Thank you @LFE89
Same here... have you been successful on recording the test-message so far?
@thomas-br I'd assume that the firmware is stored inside the nordic BLE uC found on the back of the board
It wouldn't surprise me if wifi was actually just an afterthought and therefore glued on top of the finished product by adding another module. There may or may not be protections against dumping the flash of that uC but at least there are testpoints available for all the required connections.
To try this, you will need an SWD programmer/debugger and rather precise soldering skills because those testpoints aren't very large. You could also try using one of these conductive needle things, but keep in mind that the required testpoints are spread on both sides of the PCB
@Hypfer either on the BT uC or also possible (and actually my initial thought) on the Wifi uC (ATWINC1510). Based on the data sheet it offers enough storage for the firmware and even features like OTA upgrades which they might planned to use in the future.
I read firmware dumping might be possible over the SPI Interface here. But as you said, first challenge would be soldering to the pins which are in fact not huge
How come you rather think the firmware is on the BT chip instead of the ATWINC which seems way more "mature" based on my readings
Same here... have you been successful on recording the test-message so far?
As the mqtt messages (payloads) are encrypted, the first challenge in my eyes is more to get to the key of your own device to be able to understand what is going on
How come you rather think the firmware is on the BT chip instead of the ATWINC which seems way more "mature" based on my readings
That's just a hunch after having seen other IoT stuff which was developed at a similar time. I think nordic has/had very easy to use devkits or something? I also don't see any reason for why else there would be that additional BLE uC on the board if not because it actually contains the logic part. iirc configuration was done via the wifi hotspot? It's been a while since I've tried that
See here: https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52-DK
An arduino-compatible breakout board. The software/docs are also quite nice
The chip on the back side of the nello PCB is labelled N52832 QFAAB0 1718GC
Hello, have you take a look at this repository: https://github.com/nello-io There're drivers for the board and some documentation. Perhaps it is possible to reconfigure the nello someway?
Is it just me or is their api down again? ^^
yes, their API is down since last Friday
The mqtt server seems to be down on live-mqtt.nello.io… Interestingly enough, there seems to be a node exporter running there: http://live-mqtt.nello.io:9100/metrics AWS Hosted Kubernetes node with an ubuntu vm
I still don't get a response from the server. Is there any news regarding integration with sclak, e.g. new firmware?
It's really frustrating that I can't use the device any more.
Sclak filed for bankruptcy in October 2020. In mid January 2021 there's been an auction to sell the company but I don't know if someone bought it or not, so I don't think we should hold our breath in hopes to see the servers up again
Hey!
Im not sure but the mqtt Server seams working again, at least ping work... can somebody confirm ... (can't Check it since the Nello app always says network error on the initial setup since I have reset my nello)
Hey, just checked but sadly for me it doesn't work 😕
pattyland@air ~ % telnet mqtt.nello.io 1883
Trying 52.59.132.203...
Connected to mqtt.nello.io.
Escape character is '^]'.
Connection closed by foreign host.
pattyland@air ~ % telnet live-mqtt.nello.io 1883
Trying 3.120.140.153...
telnet: connect to address 3.120.140.153: Connection refused
telnet: Unable to connect to remote host
I would say no. Afaik ping and other services but mqtt worked the whole time
Hi @LFE89,
thanks first of all for your great RE work on the nello. Sadly after the server shutdown, it is currently not possible any longer to use the nello devices. I would like to dig deeper into the topic of a local nello backend.
After going through your documentation my current understanding is, that we don't now the payload details of the mapping phase after resetting / initial setup, correct?
Do you still have the recorded messages between the backend and the nello device to continue reverse engineering on this? It would be awesomely insane if we can reproduce a mapping, that the nello device accepts the local backend.
Best