silver_sun

It's simulating the Dunning-Kruger effect.

GPT-8 Novo

I think that depends on your point of view. I wouldn't run a program on my computer unless I were sure that it's not malicious. And if you mean that some program I already trust could be exploited, that's true even for the Linux kernel or any sandbox / security solution you would come up with. I'm not denying that there's always a risk, but there's nothing good in running arbitrary code that you can't trust.

But if an attacker can put arbitrary code into your .bashrc, you are already executing arbitrary malicious code.

If you're running a malicious user process with write (or read) access to your files, you are arguably already compromised.

Some problems with this particular system:

If the TPM signs the original image taken by the camera, then even the slightest image processing on another device would invalidate the signature. Routine changes like cropping, scaling, converting between image formats / quality levels, or applying image filters would invalidate the signature.

An adversary can manipulate the date/time settings on the camera and forge evidence to frame someone. "This cryptographically signed photo, with timestamp, proves that you were here at this time!"

And camera sensors can get damaged and need replacement. But if replacement of the TPM-and-sensor chip is allowed, then you can just as well replace it with a sensor from another camera. In which case a signature from a specific TPM+sensor doesn't prove that a specific camera took the photo, at best it might be evidence that a specific camera model took the photo.

If the manufacturer will happily ship a replacement TPM+sensor for a specific camera, someone can fraudulently claim that their sensor is broken and be given a new TPM+sensor for the same camera. And there will now be multiple TPM+sensors in existence that have the same key. Since this module can be switched between cameras, there could be multiple cameras that signed a given picture.

To ship (identical) replacement TPMs, the manufacturer would also need to know the private keys of all the cameras, so the manufacturer could forge arbitrary signatures at will.

Finally maybe the manufacturer doesn't want to deal with the above problems and decides that repairing the camera's TPM is not allowed after all, or that only the manufacturer is allowed to repair a camera, but then they may be in violation of right-to-repair laws in several jurisdictions.

There's some common-sense understanding of this situation that I'm not sure you're wilfully overlooking or oblivious to. The claim is that it's unjust to blatantly exploit a system that was intended to fund/sustain you, for profit. It's not necessarily illegal behavior since "open access" was not in the terms, but how can it possibly be morally defensible that they have managed to find a way to legally subvert/trick the system for their own benefit? An overly pedantic view of the situation isn't helpful.

I totally agree with you, and didn't mean to endorse that.

I'm not a lawyer. But I think if your "binary patch" is a series of instructions to write specific code to specific locations in a binary file, and the patch itself doesn't include any of the code present in the original binary, making/distributing a binary patch can't possibly be copyright infringement.

It's normal in the videogame ROM hacking community to distribute this kind of binary patches (known as IPS patches) so as to avoid legal trouble, since the binary patch is useless if the user doesn't have access to the original videogame ROM. Distributing the ROM or even its patched version would be illegal, but a patch of the kind I mentioned is fine.

I'm curious whether OP could have achieved the same result without rooting the tablet, by running the following command in ADB shell, to remove the unwanted package:

  pm uninstall -k --user 0 com.amazon.device.software.ota

The only difference to the command the agent executed as root is the additional "-k" flag, which instructs the package manager not to delete data/cache directories off the device (which may require root access). But the effect is the same in that the undesired package is uninstalled from the user's profile.

I'm sharing this because I've used this command to debloat Android devices I was unable to root, removing various "system packages" that would otherwise refuse uninstall attempts. It's worth a try when you don't otherwise have root access. At worst you should get an error message if it doesn't work.

>The public might donate food to the poor. That doesn't give them the right to go into their house and rummage through their fridge.

I think a better analogy for this situation is: The public donates food, then the recipient, after being fed, sells access to (infinite cheaply replicable copies of) said food for a profit. The public in this case just wants to have said food.