Confiks
Joined 12 years ago
Joined 12 years ago
Now that I've tried it again it doesn't refuse at all. So perhaps just some part of the model still tuned towards that.
The original researcher published about this in August of this year [1], a year after reporting it, titling the report "Defrost the Food", which the attackers apparently took to be a good suggestion.
As the firmware is open for anyone to download [2], blurring the affected function seems more like an invitation to find out more. I know I was curious when the news about the fridges in France broke. The function's actually called "check_code_of_the_day", and this is the implementation:
uchar check_code_of_the_day(LPCTSTR pass) {
uchar uVar1;
LPCTSTR pass_local;
DATE_STRUCT date;
INT32 tothex;
INT32 hex;
UTF8_STR buff;
Get_syst_current_tds(&date);
ftext_s(buff,0x1ff,"%02d%02d%02d%02d",date.month,date.day,date.year,date.month);
sscanf(buff,"%lx",&tothex);
ftext_s(buff,0x1ff,,date.day);
sscanf(buff,"%lx",&hex);
tothex = __aeabi_idiv(tothex,hex);
ftext_s(buff,0x1ff,"%05ld",tothex % 100000);
if ((((*pass == buff[0]) && (pass[1] == buff[1])) && (pass[2] == buff[2])) &&
((pass[3] == buff[3] && (pass[4] == buff[4])))) {
uVar1 = '\x01';
}
else {
uVar1 = '\0';
}
return uVar1;
}
[1] https://www.claroty.com/team82/research/freeze-the-controlle...[2] https://www.danfoss.com/en-us/service-and-support/downloads/...
My great essence mining bot contraption horribly broke when Runescape started randomizing all colors slightly, after making a paltry amount in dollars selling the essences.
And of course, you can write that and still paste completely slop, but nobody seems to be doing that yet, and if they would it's probably not convincing.
There's also a page here that contains the budget for multiple years, although the totals from 2027 on don't sum correctly from the different sub-budgets: https://www.homecomputermuseum.nl/informatie/organisatie/bel...
I extracted the firmware and filesystem of a webOS 3.5 and webOS 24 TV previously so I could remove the spying bits and get an internet connected TV back. I asked Claude Opus 5 to do some analysis on the ACR implementation yesterday. I haven't had time to check it myself, so it might give some insight but take it with a grain of salt. Also because I'm not entirely sure I extracted the complete filesystem for the webOS 24 TV.
See the documents temporarily hosted here [1][2][3]. You can find the Markdown originals in the HTML source. The Markdown has also been pasted here [4] (although the forum software has sometimes inserted a lot of tildes).
LG uses the "Alphonso SDK" for ACR, a company which it seems to have a majority stake in [5].
WebOS itself is actually pretty neat once you get root on the device. It still has open source releases, uses a well documented service bus, the UI apps are unobfuscated Javascript. It's a genuine Linux TV if only LG allowed you to get root and would not install spyware by default. Secure boot unfortunately does prevent you from messing with the boot process.
If you want to know anything specific, let me know. There's also a pretty active Discord (ugh) community here [6].
Personally, I'm most interested whether LG and other device manufacturers are getting informed consent for ACR in European markets, and what the consent screen looks like. I doubt that many consumers actually know what they're consenting to, which might be a GDPR violation.
[1] https://scriptbase.org/lg-tv/webos-24.html
[2] https://scriptbase.org/lg-tv/webos-3.5.html
[3] https://scriptbase.org/lg-tv/comparison.html
[4] https://gathering.tweakers.net/forum/list_message/86090672#8...
[5] https://www.adexchanger.com/tv-2/lg-grabs-a-majority-stake-i...
That's cheap indeed. Enough headroom for some failing disks too. How is the noise and power usage? I didn't look at SAS drives at all, because my impression was that they're very noisy. I can place my NAS in a closed off room, but it's not too far away and I was afraid SAS drives would be audible through the wall. At the same time, the shucked drive I'm using presents itself as an WD Ultrastar, which comes very close to a SAS drive, and isn't very noisy.
The myth, popularized by a notorious thread on the TrueNAS forums [1], is specifically that ZFS requires ECC RAM, and will do worse than other filesystems without it, because scrubbing will multiply a single bitflip into a failed pool.
A ZFS core developer says that that isn't the case [2]. Here's some more reasoning [3], also about many other myths.
[1] https://www.truenas.com/community/threads/ecc-vs-non-ecc-ram...
I'm not entirely sure, but it seems to me that free space (and the 20% reservation) is mostly a proxy for fragmentation, and you can therefore better look at fragmentation directly. That would mean that if you mostly store large files, there shouldn't be a lot of fragmentation even at high utilization. The whole "ZFS changes allocation algorithm from 80% usage on" is something of 10+ years distant past, and lots of things around the allocator have been improved. It's also something that probably isn't too different from the performance of other filesystems at high utilization, so it shouldn't be exaggerated.
I ended up on shucking 4x the 14 TB WD Elements Desktop. They contain helium drives, the WD140EDGZ in my case, and are about a third cheaper than 4x the 12 TB WD Red Plus drives (which are air-filled). The shucking was easier than I expected too, and the performance seems very comparable. The warranty is a definite downside (European, so no Magnuson-Moss), but I think I can even get them back in their enclosure should they fail during the 2-year warranty period.
I've put some second hand 256 GB M.2 SSDs in there as boot drives. It was a bit of a struggle to get it to work in a way that failure of one of the drives doesn't hold up booting, combined with LUKS, TPM keys and ZFS on root. Learned a lot about systemd-boot which I have never used before, but feels a lot saner to me than grub ever was. So now I have a large script which debootstraps a Debian based NAS into being.
I noticed that there are a lot of ZFS myths and cargo culting. For example TFA mentions ECC RAM, which in some circles is a must-have because ZFS would wreck your pool during a scrub otherwise, which is a myth. It's also very expensive, especially this year. You also don't need much RAM for ZFS, L2ARC doesn't use much RAM at all, to name a few others.
Still doubting about setting `dnodesize=auto` (which is the default), because there are some horror stories about that [1]. And it seems impossible to find a cloud storage provider with reasonable prices that supports `zfs send`. Rsync.net upped their minimum order to 10 TiB recently, which is far too much for my use case.