"If I have all your code and am running it on my computer it will be a matter of time before I can back out whatever obfuscation or technique you are doing and undo it."
sure try to undo a block-chain and see what happens.
The code will be encrypted with a unique key that will need to be registered on the server with your account. Change that code and it invalidates your entire build along with your account. case closed.
I think you are missing my point. This concept in client computing security basically chains back to the halting problem. You can't /know/ what I am doing with my computer. You can build a very elaborate trap / obfuscation and it might be hard, really hard, to defeat it or circumvent it, but it is a certainty that I can. The block-chain has absolutely nothing to do with client code security because it has a network enforced mechanism. What the grandparent was suggesting was running some nugget of code in a little VM (or actually on my machine), computing a result, and then returning the result to the server to make a security decision. The problem is I control that machine performing that computation and your security decision as the server is based solely on the computation performed on my computer. A skilled reverse engineer will just hook your code in the right place, intercept that security check and have it return the right bytes back to your server, while still doing whatever client side cheats they wanted to do.
https://en.wikipedia.org/wiki/Rice%27s_theorem <--- this is all about program behavior and did the user actually run the code you sent them. Block chain is about "did I possess certain data" (such as a private key to sign a transaction) and not about "did I run certain code".
You are absolutely correct, but it occurs to me that CPU designers could actually implement a kind of RSA style memory fetch instruction. The CPU would generate a public/private key pair, where the private key is not accessible by any means. The client would send the public key to the server, which would in turn encrypt the memory location(s) that it wishes to inspect. There would then be an instruction on client's CPU which would accept that encrypted memory location and return the contents, without divulging location. The CPU could regenerate the public/private key values for each request. I can't imagine defeating that kind of scheme without hardware hacks. The more that I think about it, the more I wonder why no-one has done it before, because it seems useful. Probably there is something I'm missing...
The answer, and it has dark implications, to me, is Trusted Computing. Never let the user have full control. Do this key exchange on a base OS or some other VM the user can never touch (e.g. Knox / TrustZone). Still, we can exploit our way to this trusted OS and MiTM there, but it takes much more skill. With Trusted Computing the base OS can more simply install a "spy" to keep track of a games memory / code to ensure it is only ever loaded and executed from memory that is essentially made read only after the program is loaded but before it executes. The trusted OS verifies the program code, the OS, etc, and if it all checks out, let's the code run. Of course it goes back to the halting problem, but if the programs memory is unexecutable and modern exploit mitigation is applied the game is now in a considerably sturdier mouse trap :)
A server can't validate the integrity of the game remotely. A program on the user's computer must do that for you. You're trusting that the program will do what you expect it to do.
All one needs to do is modify the program to make it always tell your server the build is valid. Problem solved.
If I tell you right now that every single digital dollar will need to include the finger print of the digital printing press that created it. How would you be able to forge a new one without that fingerprint? You can't because every time you alter the digital dollar you create a new fingerprint that does not match the original digital printing machine.
This fixes a lot of problems with altering code and and extensions and modding. Does not fix memory changes but it can make it quite difficult because each memory change would have to be validated against the original fingerprint already registered on the server for your particular build.
I have talked about this in many occasions to developer and they also agree that a blockchain to maintain a unique fingerprint of the game is very good to deter many attacks to modding and extensions to code, no matter the platform.
It is a very simplified comment, but behind that you can expand the topic to include many advantage a blockchain can provide during multiplayer games.
EDIT: yes it is a very unpopular topic, but deep down many of you who are developers, know that blockchain can solve many of these issues with cheater.dll
Blockchain is all I work on and you seem to not understand my suggestion.
cheater.dll needs to be loaded in memory along with the game. Correct, right? If the original build of the game has already generated an encryption key that is stored on a server or a distributed ledger using your account, then tampering with the origonal build in memory will result in generating and invalod key thus changing the ledger or the stored key on the server, and not matching the ledger. If this happens then it invalidates your build and the distributed ledger would need to updated, but since that is not allowed in this instance all ledgers would reject your change and flag the block and the account. Making it easier to find who attempted a change. Sure this can be done on a server but because of the tamper proof inherited by a distributed ledger it would make it harder for this code to be shared. The cheater can still change the code but it would not be able to share it.
How would it invalidate the build? How would the server find out the build was tampered with? Why would my hacked game add anything to a blockchain? I've followed blockchain tech closely since '13 and your comment makes no sense.
Yeah I know a few more of those people and I don't understand how they're convincing innocent people that they need blockchain and that they should pay you money to implement 'the future'.
> If the original build of the game has already generated an encryption key
I'll take that to mean "if the server already generated a key, unique for each purchase, that is put in the game and also stored on the server."
> then tampering with the origonal build in memory will result in generating and invalod key
No, why? You never explained how you got from "distribute license key with game" to "invalid key when you modify the memory".
> thus changing the ledger or the stored key on the server
?!?!?! There are so many steps missing in your "explanation". Who says the game has internet? Who says the cheater didn't block the license servers? Who says the cheater didn't emulate what should have happened alongside his modified version and is submitting that to the server? Who says the cheater didn't cut out the licensing part altogether?
This is making zero sense so far.
> If this happens then it invalidates your build and the distributed ledger would need to updated, but since that is not allowed in this instance all ledgers would reject your change and flag the block and the account.
So... other game clients would see that your key is invalid, is that it? Not the licensing server hosted by the developers, but the other clients would be doing the blocking?
Alright, let's say it were so: there is a blockchain with all the license keys and your license key is computed as a hash of all your RAM memory contents. You submit this hash of your memory to other game clients when you communicate with them. Every network packet needs to contain this, or else they will refuse to process the packet at all. Other clients can look up valid keys in the blockchain.
Then firstly, you don't need a blockchain. What you're looking for is a relational databa -- scratch that, you need json -- oh wait, not even that. No, what you're really looking for is a plaintext file. What in the world does blockchain have to do with publishing valid license keys?!
Secondly, you have a huge list of valid license keys published, ready to be picked up by cheaters. Don't you think anyone is just going to look at that list, be it in blockchain format or in json or in plaintext, and replace their signature field with one of those keys?!
Thirdly, your RAM continuously changes. It's not as if you can play without getting a new signature a few million times per second, with each write operation to RAM. But let's say we only do it once per frame, so 60 times per second. Then you need to know what all the possible states are going to be... you know what, this is making zero sense. Tying some key computed from your game state to a license is nonsense.
I would think you're a troll but your messages seem just a little bit too long for it, it seems like too much effort... but I kinda do think you're a troll. The more I think about what you're saying, that's the only logical explanation.
sharing the altered code. If you share the code and its invalid it can be traced back to your account. Which you can only create if you are part of that chain as a registered user. That fingerprint changes as soon as someone tries to use their account and tries to validate against the chain. It does not stop the cheater, but it stops it from spreading the cheat and it is easy to identify the cheater.
I mostly watch Twitch during a big title release, just to see if I am interested or not. I also like watching big events like Overwatch League and other competitions. To me it is relaxing to watch people that are very good at the game play because I also learn from them and do that myself in game.
some just don't have the money to buy the game they want so they go into Twitch to watch that very game and get their fix until they can purchase that game.
I was also surprised by that comment. I just checked and React still has on the order of less than 30 methods/properties in its entire public API surface. Vue.js has quite a bit more.
If the parent means by byte count, React + ReactDOM is about 32.5KB, Vue is 30.3KB. Not a dramatic difference in byte bloat, either.
Wait, what? A large ecosystem of libraries that are not included by default but are available for you to use is somehow a bad thing (as "bloat" implies)?
"My husband and I would joke and say I'd bet these devices are listening to what we're saying,"
Think about this statement for a sec. Of course is listening to you. It has to listen to you because it needs to be able to respond to "Alexa". So yes, this is always listening.
Now, once you come to terms with that, do you feel comfortable having a technology with access to the internet, location, habits, account, contacts, email, phone, CC information etc etc, to be actively listening to your most intimate private conversations?
It does not take a 5 year old two seconds to figure this out.
The problem with this logic is that it applies to phones, tablets, and laptops as well.
There isn't much additional risk from having an Echo or a Google Home if you already keep a smartphone within 10 feet of you at all times, which most of the people who are buying these devices do.
People make the same jokes about cell phones and location tracking. But it seems like with these invasions of privacy they're always unable to make the leap from joking about it to the reality itself.
Well these are Gov employees so there is a Fringe possibility that has been confirmed to be black projects where Remote viewers attempt to access information through telepathy. Many of the reported symptoms are just like the reported in this article with pressure and weird sound sensations along with nausea and headaches. Some were diagnosed with brain injuries as well.
Again this is the tin foil hat projects that many conspiracy theorist claim is still happening today.
during WWII Germany Scientist did research on remote viewing.
everything is about the environment. If you have an under stimulating environment then even your health is affected.
Read about the WWII pregnant survivors of holocaust where their lack of food evolved into the fetus being stingy with proteins and sugars and now they are experiencing health problems because now their body stores more than it needs and weight gain and other health factors arose.
So yes, environment can be detrimental to not only brain, but full physiological development
sure try to undo a block-chain and see what happens.
The code will be encrypted with a unique key that will need to be registered on the server with your account. Change that code and it invalidates your entire build along with your account. case closed.