   Knowing files are modified externally
  I used to think this was impossible to do perfectly. You could do some generic things, like saving the date into the file when you write it, then compare that to the file "modified" date. But the modified date can change for reasons other than actual file editing, so it's pretty dangerous to reject a file for this not matching.Anyway, like I said, I expected it was pretty impossible. But the PC edition of Madden 2006 seems to do this absolutely perfectly. I was trying to hex edit my superstar quarterback to increase his ball-carrying and speed to give him a good scramble advantage. But the game seems to know the file has been edited when only one single byte value is changed. I can close the file out of the hex editor, open it back up, change the single byte value back to what it was, and the game opens it and doesn't complain. How in the hell did they do this? I tried modifying many single bytes in different parts of the file to see if I was simply editing something very important, but the game seems to keep track of every single byte. Even the ascii values of my character's name couldn't be changed.Anyone know how they managed to do this so flawlessly?Thanks/   
  Maybe they use some kind of function(XORing,ANDing,whatever) to calculate a single value out of all the bytes in file, and store only that. When the file is loaded, they calculate the value with the same function. If the 2 values don't match, that means the file is changed. That may not be 100% full-proof(you can change some values in a way that the result will be the same), but it's good enough and most importantly: It may mistake a changed file for unchanged, but not the other way around.I don't know really, I just said the first thing that popped into my head.   ;  It could be as simple as storing a hash value for this file inside the file itself. Then when loading the file, matching it agins the stored hash code. Thus, had a single bit been changed, the loader would know it and prevent the player from going on.As mikeman said, you theorically can change the file in a way that would not change it's hash value, but in addition to being almost impossible to du, the way to do it would not match the way you want to change the file.Another hacking possibility is for the player to know how the hash code is computed, and recompute it after his modification, then write it to the file. It would imply knowing where to put the hash code, etc. Pretty difficult for casual people.Did I miss your point Kest ?   ;  hmmm... the probably have back-up files.   ;  I think I follow you. You're saying every byte value in the file could be used to compute a single ID-like value. So if you changed a single 6 to a 3, it throws the final value off. But then you might be able to get away with it, if say, you changed another 3 to a 6, depending on how generic the calculation was.I kind of like it. It's a pretty solid answer to prevent a lazy hack.Thanks for the answers.   ;  Yeah, kind of like that:int main(){unsigned int buff[1000];for (int i=0;i<1000;++i) buff=rand()+1;//Fill buffer with random values//compute the hashunsigned int hash=buff[0];for (int i=1;i<1000;++i) {srand(buff);hash=hash+rand();}printf("Correct Hash: %d\n",hash);unsigned int pos;unsigned int val;printf("Enter position to change(0-999): ");scanf("%d",&pos);printf("The current value is: %d\nEnter new value: ",buff[pos]);scanf("%d",&val);buff[pos]=val;//compute the new hash the same wayunsigned int hash2=buff[0];for (int i=1;i<1000;++i) {srand(buff);hash2=hash2+rand();}printf("New Hash: %d\n",hash2);if (hash==hash2) printf("The buffer is intact!\n");else printf("The buffer has changed!\n");return 0;}It's a pretty lame way to compute the hash, it just shows the logic. The program asks you to enter a value in a position in the buffer. If you enter a different from the current one, it detects the data has been edited.   ;  In addition to mikeman,s code, if you're interested in famous ways of calculationg a hash value, then here you go !