That's unfortunate... I can see why it would be desirable by the manufacturer and dealer, (as it would enable quite a few shady practices by both), but I question how stable EEPROM is compared to PROM in the hazardous environment under the hood or dash. (I know some modern systems are installed under the center console between the front seats, and some are installed under the passenger or driver seat, but this is still a problematical location in terms of operating environment. Still has large fluctuations in ambient temperature and issues with moisture and corrosion.)

I have seen ODBII dongles made specifically for hotrodding that contain new fuel mix tables and timing data for the ignition control system, but havent really seen kits to completely re-flash the ICS's computer.

Guess you learn something new every day.

No need to do such extreme damage, when the same effect can be achieved with a simple fuse on the positive voltage line of the port. Suspicious activity? Burn the fuse-- BAM-- port is dead, but easily fixed.

However, this would require a "smart" component inside the dash, between the actual ignition control system/ACS system, and the ODBII port interface. Such a device would need to have a reference pattern to check current communications against, and would need some level of processing capacity to compare realtime engine diagnostic data and bus activity against the reference. (Does not need to be fancy here, but this does imply the ability to program a new reference pattern later, especially if the system is fully adaptive to changing engine conditions over time.)

This then places some significant implementation considerations on the vehicle manufacturer-- this device has to somehow be able to be field-reset at a dealership if it gets confused after having the engine serviced, and also needs to have nothing but read-only access to the engine's control system. The only thing it should have "write" access to should be the fuse. (And maybe an indicator lamp)

However, given the less than spectacular implementations of integrated devices in modern vehicles (in terms of security, and security oriented design/implementation) I question if such a device would be properly implemented.

I get the sneaky suspicion that the automaker would be ... "tempted" ... by dealerships and other retailers in the market to integrate lojack functionalty into the security device, thus making it itself into the target of exploits. (Otherwise, the purposeful activation of the intrusion failsafe would render actual lojacks incapable of stopping cars, by disabling the communication bus. This means removing the fuse would essentially disable such countermeasures.) This would then make "remove the dongle" no longer an option.

When presented with a choice between "properly implemented security" and "Pressure from their customers" (Auto manufacturers RARELY, if ever, sell directly to the public. THEIR customers are the dealerships.) , I expect automakers will choose to placate their customers every single time.

except that the firmware in the ignition control system of the vehicle is written on actual PROM chips, not EEPROM chips, because they have to operate in a hazardous environment. (Temperature extremes, moisture intrusion, dirt, corrosion, etc.) Voltage spikes from slowly decaying wiring, or other sources of irregularity can damage an EEPROM's contents, where a PROM will just burp a little, then be fine after the irregularity. (assuming it isnt a very large spike that can kill silicon anyway)

This means that the ODB2 interface (the little connector under the dash) can at best, only be used to circumvent proper engine function when another device is attached to the bus that has such programmability.

There most certainly ARE such devices on the market, such as the lojack type devices used to prevent vehicle theft on vehicles that arent paid off, etc-- used by used car lots and the like, but these are purposefully installed in a fashion that makes physical removal of the device difficult without the correct tools/equipment. The vehicle runs just fine without such devices attached.

In the case of one of these really shitty dongles, physical removal of the dongle should suffice. The vehicle would then operate with no outside manipulation of its ignition control system. They try ransoming the vehicle, just pull the dongle.

The bigger concern is possible malicious actions, such as "Murder by remote" type situations. The vehicle has such an exploitable device (with its lack of challenges against the network it is communicating with), and a murderer chooses to exploit this to make the ignition control system refuse to fire any of the spark plugs, or to drive any of the fuel injectors. The vehicle stalls while driving 70mph (or faster) on a crowded highway during a lane-change, or while passing. Perhaps the antilock brakes (automatic skid control systems have control over braking) are exploited, and the brakes on one side of the vehicle slam down while doing said 70mph, and the vehicle spins out of control or flips over.

Considering that there is absolutely NO protection here, (No challenge/response, no encryption, no verification of remote network authenticity, etc.) there is definitely room in the criminal underworld for such a remote exploit. Professional hitmen, (and government agencies) would love such a toy.

I mention this possible application, because the obvious one of insurance fraud has already been brought up a few times.

Still, the solution is the same. Physical removal of the dongle solves all the problems.

The problem with the latter approach, is that programmers spend time when they arent working, thinking about the problem they are being paid to work on when they are working.

EG, they may have the sudden epiphany while playing super mario brothers, that they have failed to have while sititng in their cublcle, trying so very hard to push that solution out under great duress from their manager.

Or, as archimedes had his epiphanies-- In the tub.

This is not a new thing, and creative problem solving REQUIRES downtime to be effective. The people that insist "You arent applying yourself all the way, therefor I will ding you on your reviews!" are a problem, not a solution.

Usually with the closed source applications, you send in the bug report, and it appears to vanish from your end. There is no feedback from the bug treacking team. There is no update on if the issue is pending more data (which you could supply if they ask. Clearly the bug was severe enough to warrant a report, so clearly you must run into it fairly frequently-- but no-- no access to the bug tracker, so you dont see the comments about "Cant reproduce! closing!" getting thrown about in there) or even if the bug gets closed with "Working as expected, wont fix"

Nope, you get a "Send us a bug report! Fill out this window (which has a max size text field, so keep it contrite!) and hit submit to send it on its way to digital purgatory!

You dont get informed when a fix will be incorporated, you dont get informed of any work arounds. Nada.

Compare that with FOSS bug trackers, and it is night and day.

Yes. I KNOW.

If you had READ THE WHOLE THING, you would have seen the parenthetical comment at the end about how the micro cell could be at an event!)

For fuck's sake, this is the last comment like this I am going to respond to!

All you need is a few kilobytes of storage. Most phones have this already in the underlying hardware for use with things like the region ID and the like.

Seriously, each entry in the blacklist needs only the UUID of the blacklisted tower. That's it. Hell, this could live in the damned SIM card.

Everything else can live in the app.

You havent been following the stories on stingray use, have you?

Law enforcement agencies use them to eavesdrop on multiple cellular devices in the espionage radius, hoping to catch thier perps. the data of innocent civilians driving past also gets logged. this has been reported on. it is not handset specific.

the illegality of the practice does not seem to matter much except when the triale judge demands to know the source of the evidence. Even then, law enforcement frequently LIES about using stingrays.

a community method of tracking and recording stingray deployments in large urban centers that is public domain would open the doors to some serious FOIA request hilarity.

"hello, NYPD? yes, according to OpenTowerMap.Org, it appears that a new cell tower with unique ID XXXXXXXX went into operation in the area near to where your investigation into Nicky the Nose was going on, suspiciously consistent with the length of your investigation. Since your investigation agrainst Mr Nose has concluded, there should be no reason whatsoever to deny my request for any information you have on the use of a cellular monitoring device during that period at that location. Specifically, we want to know how many non-suspects accessed the device, and what the current status of thier records is, and also what degree or level of transparency your agency has taken to inform those innocent citizens that thier data was collected as part of your investigation."

etc.

I know. the problem is that it is impossible to tell a legit microcell from a totally not legit stingray.

the default should be "suspicious: do not use", with an option to manually enable.

the user will know if they are at a major civic event or not, and hopefully will know when they are under a major emergency situation.

I'd say that depends on the cellular technology in question.

Most likely the signals will be in the 700-850mhz band, or the 1700-2100mhz band, depending on the technology and carrier.

I Do think that this is technically inside the RTL-SDR dongle's reception capabilities.

One still needs a way to prevent the cellular device from being pushed to the "New" tower.

Sadly, handset makers and mobile OS makers have not been able to give a "Blacklist tower" feature, or have not been willing to give such a feature. The towers MUST be uniquely identifiable for the tower mesh network to communicate reliably-- so, a means of uniquely identifying and refusing to play ball with a specific "Tower" should absolutely be possible.

Google and Apple should step up to the plate on that.

A better approach would be to keep a triangulation map of available towers over time.

The point of stingrays is that they are mobile. Cell towers are NOT.
Similar to older war-driving apps, the app looks for tower broadcast signals, even when it does not intend to hop. It keeps a record of the GPS coordinates of the handset (Seriously, a smartphone without a gps these days?) and the detected signal levels of all towers it sees.

It then builds a virtual geographical map of cellular towers based on its own radio data over time. The sudden, mysterious appearance of a new tower where there previously was not one, (and also where there does not seem to be capacity reason for one to be added, or one with a suspiciously small radius of service) would get flagged, and should get blacklisted by the phone until the user specifically says "No, it's OK to connect" (It may be a microcell at a crowded event or something)

That should allow creation of a stable whitelist over time.

I'm glad that there's a COTS solution for this, but I suspect that a lot more control could be had with an actual logic controller or mini computer. Other than the soundboard/mp3 playback function (are there any good linux applications for this? I know there are many MP3 players that can be invoked from the console (eg, via an SSH session) but the soundboard would be a bit of an issue) a Raspberry Pi or a BeagleBone with a few diodes, transistors and resistors could drive a shitload of lights in obscene complexity. (Over 32 PIO lines on a beaglebone. Using a common ground and switched voltage sources, one could drive 32 strings of lights directly. Accessing the PIO pins is pretty easy, and can be done with a simple shell script; but this gets into programming, which the OP explicitly stated they wanted to avoid. Though I admit controlling all the pins in full parallel may be tricky. May need to sacrifice one of the IO pins to signal the voltage controller to activate/deactivate. That gives 31 strings, and 1 go/stop signal.)

I dont consider shell script all that painful though. Writing some kind of plugin for a commandline based MP3 player? that's gonna take more doing. Glad there is a COTS solution for the OP after-all.

The OP would stand to learn more using the beaglebone though. If he switched from parallel (easier to program) to a serial protocol, his same compute node could drive several million lights, but would need a much more sophisticated voltage switching board.

I am kinda surprised that there isnt already a sheild kit for this.

desalination plants are likely to have some serious issues with CA in general.

1) They arent very pretty, and will HAVE to be on the coast. This makes NIMBYism a very real problem for any project that works with desalinators.

2) CA has some insane environmental effluent rules. Desalination plants dont just wave magic wands at the salt. In addition to concentrating fresh water, they also concentrate salt. This is usually in the form of very briny water if RO desalination is used, and in the form of crude, non-food grade salt id evaporation plants are used. Both are dangerous contaminants that need to be disposed ofl and in large quantities. Simply dumping the salt back into the ocean wont work-- it will kill local marine life.

3) Desalinators will present a major power consumption drain on CA's already overtaxed power and light infrastructure.

4) Logistics and civic planning to have the water pipeleines from the desalinators routed to where the croplands in the valleys impacted by the drought need the water most is not going to be a trivial matter. Expect political BS to delay, delay, delay as everyone tries to get the biggest slice of the water produced, or get consessions for allowing transport.

You seem to have mis-identified my political affiliation. I am not a marxist communist. I have simply read the manifesto, and marx's rhetoric. I was pointing out that the AC above had clearly not done so, having created such a strawman to beat.

Genuine criticisms, such as "You cant cultivate marginal lands as if they were fully arable! It's madness!" are fully fair game, and I apply them with gusto. However, asserting blandly that Marx had not contemplated human nature? That's clearly not supported by his rhetoric, but is rather a consequence of ingesting pre-chewed propaganda pieces.

I value correct, well based arguments. that's why I bothered to read Marx's rhetoric in the first place. It is a necessity to develop and use proper analytic skills.

Does Marxism work? Fuck no.
Did Marx think about the freeloader problem? Definitely.

That latter part is all I was trying to point out. It never ceases to amaze me how such a correction makes people instantly apply "You must be a marxist!" as a reactionary measure.

Please avoid doing so in the future. Thank you.