I know someone with a fake Chinese "Rolex" watch and it's a damned good copy. My cousin has a real one. Side by side it was virtually impossible to tell them apart. The fake one even had the same hologram on the back and the movements looked the same. The fake one keeps excellent time as well and the workmanship is top notch. Opening them up one can tell the difference. The wording on the inside of the back looks like they intentionally made it different. The works were made in Switzerland though. This wasn't a cheap fake Rolex, I think he paid under $200 though. He's picked up a number of other "expensive" watches over there as well. The place that sells them keeps their hidden inventory in the ceiling with someone up there who passes down the merchandise when the inspectors aren't around. All the vendors keep a close eye on them and quietly hide stuff when they come around looking for counterfeit goods.

I know someone who has bought a number of "Rolex" and other expensive watches in China. These aren't the really cheap knock-offs and they're actually of decent quality and keep excellent time. One of my cousins has a real Rolex watch. We put them side by side and it was impossible to tell them apart, right down to the hologram on the back. Of course they were different when you opened them up, but the works in these fake watches were often made in Switzerland or Germany just like the real watches. The writing on the inside of the back of the case also made it obvious that these were fake and this appears to be intentional. From the outside, however, everything seems to be the same, even the smooth movement of the second hand.

Now with the iWatch it should be fairly obvious since they run different operating systems, though I suppose it's possible for a cloned watch to also be able to run iOS just like the real one.

The funny thing is that they only require the connector, no actual data. My car (Tesla model S) has an ODB II connector but it doesn't provide anything other than power and ground. The manufacturer can access the car via wifi, 3G or a special Ethernet port but not through ODB II. Before screaming about the insecurity of Wifi and 3G, all communication is sent over an encrypted OpenVPN connection and the devices connected to the internal Ethernet network are fairly secure. There's a web server that serves up the album art cover and the ability to display something remotely via X11 onto the center console and that's about it. As far as remote access to do things like unlock the car, etc? That's disabled by default and must be physically enabled via the center console.

You must have read a different paper than me.

ECC on a decent machine would make this attack almost impossible.

For one thing, the memory controller will likely support memory scrubbing, which will detect and correct single memory errors long before enough bits are flipped for ECC to no longer detect the corruption. ECC will typically correct one bit error and detect two bit errors. Since the chance of a bit flipping is random and takes thousands of operations, the chance of having three bits flip and not be detected is exceedingly low.

Also, the CPU does not operate on single words in DRAM. It is always a burst operation on a cache line (or even more). When you write to a word in memory if it is not in the cache then the entire cache line will be fetched into memory before it can be modified and written back as an entire cache line. It is possible this may be able to be bypassed by writing an entire cache line into the write buffer but I don't know enough of the low-level Intel architecture to know if it does this or not.

Flipping more than one bit with ECC is far more difficult since you need to make sure that there is no read operation involved before the write operation. You also need to make sure that the server isn't doing memory scrubbing. If memory scrubbing is taking place, which is something I would expect any decent server to do, it will detect and correct a single bit error long before three bit errors are generated. Also, if you don't generate three bit errors but only one or two or more than three then it will be detected. Since this requires a large number of write operations over a lot of memory to make this happen it is far more likely that this will be detected.

Also, if you start a write operation on a memory location you need to make sure that the memory controller does not first try and read in the entire cache line before the write happens. Memory accesses are performed on cache lines, not single words in DRAM. Typically the memory controller will read 32 or 64 bytes at a time from DRAM, modify the changed data, then write back the entire cache line.

And try flipping three bits before you try and access the memory. If it's not exactly three bits then the memory corruption will be detected, and if it's one bit it will be corrected. In any case, if it is not three bits when the memory is accessed then it will be reported. Also, high end hardware can do memory scrubbing, where the memory controller periodically reads all of the memory in the background to detect and correct single bit errors before they are a problem. See Memory Scrubbing.

Every implementation I have seen in recent times has always performed error correction as well as detection. You only need 7 bits to correct one bit error out of 64-bits. With 8 bits you can detect two bits and correct one bit. ECC DIMMs are typically 72-bits wide. LPDDR4 also includes support to detect and prevent this sort of attack.

It makes it completely ineffective when there is ECC. If three bits haven't flipped then the error will be reported and logged and probably blasted out on every console. The likelihood of this attack being detected well before it is exploited is extremely high. If it's two bits then either the application will be killed or the machine will halt, most likely the latter.

The problem is you don't know how many bits have flipped, and if only one bit has flipped it will get corrected when you check. If two bits flip then it will also be detected and the fact that this occurring will be reported. Depending on the OS, it will either kill the application and lock out that block of memory or it will cause the system to halt. In any event, one and two bit errors will be reported and detected.

Back in the mid 1990s I worked on a complex ATM (Asynchronous Transfer Mode) networking driver for OS/2 that was written in C++ and it was actually quite elegant compared to the Windows NT driver which was written in C. It had more functionality yet was less than 1/3 the amount of code. It used new and delete as well as templates but other than that it was somewhat limited in its use of C++. Granted, C++ has evolved quite a bit since then but it showed me that C++ can be used for low-level stuff. Performance was actually quite good, at least as good if not better than the C counterpart. The code was also easier to debug and tended to have far fewer bugs than the 360KLOC C driver. This driver was around 100KLOC of mostly C++ with a small amount of assembly and some C for the OS bindings. It included the full signalling stack, lan emulation and all the other various parts needed for an ATM stack.

Adding features was also much easier than the C driver. The code base was also used for other operating systems and compilers as well (i.e. AIX running on Power).

I did the same thing years ago and they matched an offer I had from another company. A few years later after they shut the division down and layed everyone off (at the height of the dot com boom) I learned that the project I single handedly worked on was paying for most of the division.

My current employer is pretty good at retaining talent and we're growing. Sadly we're having a hard time finding good talent to help with the growth. It seems 90% of the candidates are just not qualified and lack the experience. Several of us have some good programming questions and none is particularly hard, yet it seems most candidates fall flat. A lot of the people I work with are older since we're looking for experienced developers. We don't care how old you are as long as you can do the job and adapt.

In reality this would be difficult to exploit on a server since servers typically use ECC memory. ECC memory can typically detect two bits and correct one bit error and will likely catch this unless you can flip enough bits correctly so that the ECC remains correct. Doing this means that you would need to know the contents of those memory locations prior to flipping the bits.

I don't know about X86, but on the CPUs my company makes we support hardware address randomization, so that the address lines going out to memory are randomized such that finding adjacent rows or columns can be very difficult to figure out.

It's a shame that Intel only supports ECC memory with their XEON processors rather than all of their processors. ECC does not add much in terms of cost, only 12.5% more DRAM chips and a few more traces and a few other miscellaneous parts (resistors, capacitors). Even the lowest end processors my company makes (for things like small routers, wireless access points, etc) supports ECC and address line randomization.

Maybe some tech companies do, but where I work we have strong needs for certain skills and they're impossible to find.

If the people I have been interviewing are any indication, most of the candidates I interview are not qualified. Many fail basic C coding and algorithm questions. We need specific skills but in a broader sense just good software engineers who can deal with low-level code and hardware and understand basic stuff with modern microprocessors. We're looking for people who can work with multi-core CPUs in C and have no problem working on stuff like the Linux kernel or embedded systems. Usually the requirements we put in the positions are skills we need. And frequently the candidates lie on their resumes, claiming skills they lack when asked about them. We're even having trouble finding qualified people for positions like a lab assistant to deal with racks of Linux servers (running ARMv8) with networking knowledge who can handle an Ixia tester. For one position I need I've basically given up for someone to help with the bootloader code, involving dealing with a lot of different hardware drivers, especially dealing with 10G Phy chips who understands things like the need to follow certain coding practices (i.e. the Linux kernel coding standard).

The Toyota Prius has been doing this for a few years. Previously they pumped the hot coolant out of the engine and into a thermos. Now they just use the exhaust to heat the coolant to warm up the engine faster.

It is much slower to do it this way. It means that instead of just parsing the directory entries it needs to open every file and read the header to figure out the file type.