I remember figuring this out when I needed to buy a new key for my Audi and the dealer wanted $200 to program it.
https://www.audiworld.com/forums/a8-s8-d2-platform-discussio...
the software's available online, all you need to do is get access to the OBD port and you can make your car trust a new key!
I’m not sure if you are using the qualifier “good” to exclude the nest, but it can work on a two wire system (it can siphon enough power to work without making the relay close)
It was upgraded with a rather new controller board at some point despite the machine being rather old, and is very unhappy about any extra loads on the heating control wire. In fact the controller supports all the things (even potentially controlling AC) but there are only 2 thermostat wires in the wall...
The old thermostat is placed quite far from any place I could plug in a transformer to... (otherwise, yes, that would have been the solution)
My current setup has the relay right next to the furnace, where there's plenty of mains lines to tap into for continuous power and this is fine since it doesn't measure anything and just gets commands from hass.
I was at a financial startup ~ 2012 and remember getting a couple of these to play with. They came in the form of 1U servers (HP I think) running RHEL5 that each needed a public IP that was open to bloomberg. I think the client app was windows only at that time, I wonder how much has changed
I do not think it runs on anything but windows, but you can install the terminal software on any Windows computer you want. They are now selling "Anywhere" subscriptions that basically let you move from one machine to another.
I interned at Bloomberg this summer and there was an announcement that B2 (what you're maybe referring to as V2) will be sunsetted, although some of the major improvements will be ported over to B1 (the "original" version). Unfortunately, tabs were not one of the things they'd be porting :(
It's also due (perhaps more) to the nature of television. The content producers due to copyright hold almost all the strings, and benefit from a small choice of delivery providers to bid against each other for exclusivity. The delivery providers also benefit from acquiring content producers (or otherwise delivering "original content" themselves). Content for television that people want to watch (in competition with other content currently available) is expensive which also has an effect on a price floor even if exclusivity deals can't be made. Content can only be watched one way, or at best a handful of ways depending on if the producer spent effort making it 3D-enhanced or whatever.
Meanwhile setting up a site is cheap and comparably much easier, and can even be free or profitable in many situations for many audience sizes and site types and levels of effort. Pretty much anyone can do it, even children and teenagers, and reach arbitrary audience sizes. Content is often cheaply produced, and when it's text, cheaply delivered. Content is furthermore produced by people who don't have a share in the server itself, i.e. interactive users, and those users aren't required to exclusively post their content in one location, nor are they required to continue producing content at any given location. There are many sites in competition to host user content for free so that individuals don't even have to go through the hassle of setting up their own site when they can sharecrop on someone else's, and if they feel like it, move on later. The way browsers work doesn't require any visitor to view the website in the way intended by the site owner, either. More wide-spread encryption (and wide-spread damages for failing to encrypt or otherwise do security properly) makes it harder for anyone but the site owner and the user's computer to know what's going on.
There are so many fundamental differences with cable TV and with how the internet and web function and will continue to function (even if in a less universal way) that comparisons and predictions of everything becoming "packaged" like TV are laughably ridiculous and simplistic. Sure, we might see some business models attempted where ISPs charge for access to certain sites, but if those sites contain links to other sites and users don't have access to those, they're going to be annoyed. When more and more of the web is served over HTTPS, how can ISPs know? Furthermore the cost of plans like "youtube only" or "wikipedia only" can only in the limit ever be as expensive as the "cost per GB delivered" plan that VPN users will have. VPN will continue to exist, if not for the general public at least private parties and probably universities will still want because they can't predict what employees/students/professors will want to access or set up for access that they want it all (as it currently is). Not to mention work-from-home/remotely employees. I'm sure with less regulation many interesting and unforeseen business models could appear, some I'll have no interest in, but I don't foresee the destruction of some way to keep my internet experience more or less what it currently is.
My only concern would be not as a consumer but a big company. No neutrality law lets ISPs more easily attempt to shakedown large or popular companies like Netflix, Facebook, Google, etc. and put them in a standoff of who would survive customer outrage the longest if users couldn't access them anymore. I don't think ISPs can win that fight in the long term without strong support of the government to stop those other companies from providing their own methods of delivering their content to people. Google Fiber was a warning flag to the ISPs to show they're capable of it, and that was just Google acting alone.
It sounds like this is more or less equal to android's "ADB"?
> “There are several ways someone could do this. An attacker could change the BIOS configuration (for example, with a use of a Flash programmator) when they have physical access to the equipment during manufacturing, storage or usage.
It has to be specifically enabled (with physical access)
No, at least not on stock Android devices. ADB is pretty constrained (SELinux policy, the DAC, etc). It shouldn't be possible to go from there to something like root+unconfined on a normal user device, though of course with additional exploits anything is possible.
If the comments above are correct this is either more like JTAG or is JTAG. That's commonly far more capable, usually providing the ability to do things like read and write arbitrary memory without any kernel hinderance at all (although ARM cpus can typically still protect trustzone memory).
JTAG is a protocol for testing electrical connectivity and package pins, all the debug capability is proprietary vendor extensions. Which is to say that for any retail product, the CPU will have had a fuse set to make it "protected" which typically includes disabling debug JTAG functionality.
It isn't always the case that there's a 'protected' fuse.
Manufacturers seem to have settled on a few different approaches to JTAG:
1/ Leave it open, hope nobody notices.
2/ Leave it to ARM, since modern ARM CPUs have the ability to disable normal and secure world invasive and noninvasive debugging.
3/ Require you to scan in a secret to unlock most debugging functionality.
4/ Fuse off JTAG on production devices.
I can only speak to my experience, but my guess is that for consumer electronics this is roughly in order of popularity with the top option being maybe half of devices and the bottom maybe 10%.
And each of these has problems, so it's no wonder people haven't figured out just one.
Leaving it open is terrible from a security perspective, but for some classes of devices it's also a legal and IP headache. So this is mostly the "couldn't be bothered" set.
Leaving it to ARM is fine as long as your trusted world is sane and the only interesting thing on the chain is your CPU. For many devices this isn't the case. And sometimes bootloaders etc can be made to be insane.
Scanning in secrets is just a bad idea. Provisioning per device secrets is hard, so the "secret" often isn't. Usually it's either something simple (1111... etc) or a serial number, or a serial number ^ a constant, or just the constant. Even where this isn't the case, the secret checking logic is often glitchable or has a viable timing attack. So these frequently fall into the "annoying but possible" bucket for me.
Fusing off JTAG is a mixed bag. It's a huge PITA for manufacturing and RMA so I understand why people don't do it. And you really have to have kind of a lot of logic running on most devices today to get fuses working, so it isn't always as effective as it looks in the presence of glitching attacks. But it is still by far the best option for security and it can be gotten right.
There are also usually various levels of 'disabled', with some parts letting you run eg mbists even in a secured configuration. Obviously, more special cases means more ways to go wrong.
Of course some segments of the market are better about these things than others, so YMMV on the frequency of various approaches.
That's interesting, I figured they would just disable/fuse it at the same time that the software is flashed, and updates need to use a bootloader anyway. What's the legal and IP issues?
Some industries are under various requirements not to be user-modifiable. Some of those requirements are uncommonly applied or are uncertain (wifi routers), but some have serious teeth (export controlled munitions). For devices in those classes they often can't be open without risking liability.
On the IP side, some people really care about keeping firmware proprietary. Leaving JTAG in a mode that is meaningful for debugging that firmware will pretty much completely destroy that. So if you super duper care, you sometimes put clauses in your contracts holding the integrator or OEM responsible if your firmware leaks.
Regarding a race condition, yeah. It's pretty common for devices to come up open, then harden up-- and not just for JTAG. It's also not unique to the register-setting approach.
Almost all modern embedded and non-embedded platforms do not actually have fuses (or separate flash area) for HW configuration and instead boot in some fixed and somewhat sane hardware state and all the "fuse setting" is done by software on each boot.
Typically the "sane hardware state" means enough to execute firmware instructions from somewhere and have some scratchpad RAM. Interesting approaches to this include modern x86 system which boot into state that could not be reasonably described as "sane" (no RAM, MMU preloaded with configuration that should not be normally possible...) and various RISC implementations that boot by loading initial contents of various registers and on-die caches from external serial PROM (which is essentially same way as how FPGA's are configured).
> all the debug capability is proprietary vendor extensions.
To be fair, these are generally fairly well documented for most CPU cores. For the ones that aren't documented, sniffing a proprietary debugger isn't difficult.
I'm surprised to see this is the only comment mentioning leaving a bowl of food out 24/7. This is how it's done at every shelter I have volunteered at (and how I do it at home) - the cats should always have access to water and some form of food. The wet (canned) food is what you have to be more careful with because the cats will compete for it.
Yep. We tried this before making the automated feeder. Gave it a 2-week trial period. The initial reaction was surprise and delight with the abundance of food. Initially they decided to eat 3-4X what I normally feed them twice a day. I was hoping once the initial party tapered down they would get sensible. Two weeks in I had 2 happy tigers and two very sluggish fat sad tigers that did pretty much nothing but eat and poop. And Oh man the litter boxes were a nightmare. I needed to clean them 3x day to keep up. I never figured out a way to get _all_ tigers to be responsible with open buffet policy.
Some cats will pig out, even if food is regularly available and not scarce. You don't want to overfeed them. This gets way more complicated as the number of cats increase.
Cats will also fight over dry food. Source: have two cats who like to steal each others' food (dry or wet) and bash each other regularly... and occasionally I'm the victim of full paw bashing in the morning, when they're hungry.
Sadly OP solution wouldn't help me because they 'd just kick the food under thr sofa where it can rot...
I guess it depends on your animal's feeding habits. My dogs don't overeat, so we just leave the food out and refill it when needed. Dry food, that is. For wet food, they'd just about fight over it.
