Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Hacking the Silvercrest (Lidl) Smart Home Gateway (paulbanks.org)
84 points by homarp on May 29, 2021 | hide | past | favorite | 22 comments


> The server has some brute force protection whereby failed logins will cause the device to stop this server for an increasing amount of time. The device has to be left switched on for the anti-brute force timer to expire because the failure counter is stored persistently in the flash.

Excellent! This is the way security should be done if you have to use a password like here.

Too many devices either don't have brute force detection, or don't persist their intervals meaning a reboot gives you new attempts.


I rarely have to think about stuff at this level, but am I interpreting how this works right?

When a remote login fails on these devices, it kills its ssh server process, waits a certain amount of (time * how many failed attempts)ms, then starts it back up?

But if you truly hammer at one of these devices you could force it to reboot, which makes it forget the counter, so an attackers gets an unlimited number of the “cheapest” guesses (though it’d still slow it down a bit).

The solution is the machine physically writes the memory from RAM into onboard FLASH mem, and is reading/writing the count variable to a file instead of just using a variable.

FLASH memory is the type that keeps state as long as it has a trickle of power, so as long as the device is plugged in, this is essentially “long term” storage (but not truly like a hdd would be).

A reboot will wipe the systems RAM (because you don’t want any bad state from behaviour lurking around), but not the FLASH. And because it doesn’t ever physically cut the power the FLASH persists and the intended increasingly harsh punishment for failed logins works.

Lower level stuff is awesome.


Flash memory is nonvolatile (it does not need a trickle of power to maintain state). If it were, SD/uSD/SSD/NVME memory would be wiped the second they were disconnected from a device and every device would lose its firmware when it lost power.


Huh, why does the device “have to be left switched on” for then? If it’s non-volatile it doesn’t matter right?

Or is the point that the counter only counts time when the device is on? Kinda of like anacron vs cron


The latter. Counter is stored persistently; power is needed only to decrease the counter (according to the article).


The real solution is to not have an SSH server enabled.

Former home automation software developer speaking here.


Is there any reason why one sees so many black PCBs nowadays, instead of the 'normal' green? Is it simply fashion? Or is there a new cheaper / better black material being used?

..

I definitely dont like the look of it.. Black chips on a black background.. makes the board harder to 'read' at a glance imo.

Edit: Answered my own question.. https://www.quick-pcba.com/pcb-news/questions-about-black-pc...

It is simply fashion + this : Anti-plagiarism. Because the traces of black PCB are difficult to distinguish with the naked eye.

Also seems there are some disadvantages of not using green.


Interesting, I was wondering why I was never really seeing green PCBs anymore except for “boring” pci cards like USB hubs, or wireless cards. Fashion makes sense.

Kind of makes me nostalgic and want to build a high-end PC with only “retro” green PCB components


I believe the black PCB trend started with Apple.

It won't slow down anyone seriously trying to copy your product, since they'll just depopulate the board and use "bed of nails" or "fly wire" scanning technology to recover the netlist automatically. It does frustrate repair attempts, however.

High-end server-oriented stuff still tends to be "boring" green.



with this, hopefully we are one step closer to a consumer retail home assistant box that users can deploy locally without the cloud integration that every company is in a frenzy to lock you in to.


Hass.io already sells their blue box (https://www.home-assistant.io/blue) but an rpi works nicely too. The Lidl gateways and similar zigbee hubs aren’t really necessary in a hass.io setup once you plug in a (pretty cheap) USB zigbee stick.


that’s also a good step forward, but with all due respect to hass, it’s not a consumer retail brand (yet?). ideally, we’d get a little box like an apple tv/airport express where you plug it in, it finds all the zigbee (and thread) devices in range, and then let’s you validate and configure those by walking around and pointing your phone/tablet camera at each one (hopefully validated via uwb/nfc rather than qr code).


I agree. With Thread I expect this to come to actual Apple TVs and the like in the next few years.


The hardware looks interesting, it should run OpenWRT nicely, and the USB port on board would be handy for adding a WiFi module, audio card and other devices.

Here's some more data about the CPU and RF module used:

http://www.hytic.net/upload/files/2015/09/REALTEK-RTL8196E.p...

https://developer.tuya.com/en/docs/iot/zigbeetyzs4module?id=...

(last one needs login for full datasheet)


I think the Lidl tools brands are the best value for money you can buy, in a lower price segment. There are other brands that are best vale for money in higher price segments, but for tools you only use occasionally, I think Lidl is on top.


I'm surprised this device has so many electronics in it...

Considering it is basically an ethernet<=>Zigbee bridge, and never needs to send more than a few bytes at a time, I would have designed it with a Wifi ESP8266 connected to a zigbee module.

With that setup you could probably cut the retail price in half, which has to be important for a device nobody really wants (People get excited about their new smart bulbs... Nobody cares about the pesky gateway device)


Putting extra hardware in there to allow it to run Linux is probably less expensive than the savings from being able to target Linux for your software.


But you could probably make the users happy by just running example IoT code from the Arduino IDE...

I don't feel like the on-device code is the expensive bit of this.


The aim of the home automation software/hardware industry is not make users happy. It is to make profit.

Any user support (extreme example: dealing with user who brick their devices or play with it in unintended way) cuts into profit.



I have a few of their bulbs (decent) and motion sensors (junk) running on Home Assistant on an RPi. Might have to pick one of these up to play around with.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: