Apparently it's relatively trivial to take any exe file, use disassembler and a binary editor, and modify it. This is how cracked versions of code get published via torrent websites.
So either the exe has to be tiny, and the user always has to download it from a server to run it - but I think even that can be cracked relatively easily. If you use an exe checksum, then the code that forms a response that uses the checksum could be modded to respond with the correct checksum - but at least that executable would have to cracked for every new version, and if the server is capable of generating a new executable every day - then it's too much trouble to have it cracked. Creating a script that modifies the exe checksum every day seems like it would be easy to do. But it also raises the server bandwidth.
Another approach is to have self-modifying code that consists of assembly language embedded in a table and written to an area of memory to be executed. Fine so they modify the table. Now if it resides in 10,000 different tables (maybe use a perl/etc script to generate the tables) to obfuscate the assembly code, it requires much more work to crack. This begins to get into the realm of "if you code this - you're crazy" and "if you crack this - you've really earned some sort of easter egg that asks you and anyone running the cracked version to at least donate to charity".
I might wind up with the common model - all code is crackable, but most of the population is honest, and half the people running cracked code only want to know precisely what it is they would be paying for if they bought the product. And it probably helps ALOT to maintain an attitude of humility. Am I going to go broke if some people hack my code? What the whole problem means at the most fundamental level - work for me, and the cracker - work that could have been used more productively, and increased burden on honest users, is something to continually keep in mind.
If you have ideas, or find interesting threads on the subject - maybe something to look at.
Sunday, March 20, 2011
Saturday, January 8, 2011
Achievements versus Visions
I recently had a friend recommend I develop a game for the Microsoft Phone 7 platform. So I started to look into it. From only a small amount of digging, I found it would probably mean development in XNA, rather than Unity. This is fine.
What stood out to me in one of the youtube "Here are all the cool games we have for MP7!" videos, was that they mention "Achievements". This was a feature in Xbox360. They are sort of like badges you can earn, and then when someone looks at your game profile (like all those girls who keep checking out which guys have earned the best achievements)... well you get the picture. Achievements are essentially a marketing tool to promote the platform, and they also provide the gamer a benefit in that they add visibility to parts of the game that haven't been reached yet.
This reminds me of my resume. I get to take that resume to an interview, and the interviewer looks it over and says "so tell me about such and such". But painful as it seems - it's true. I really don't care about such and such. Because that was yesterday's news. And yes, it probably comes through in my voice.
So now I'm in the middle of creating a game. I think it's worth going broke for. Call me crazy. And one of the features I'm looking forward to putting into the game is "Visions". Instead of telling the player "You've gained the following worthless Achievment!" I'm going to tell them "You've gained the following Vision!" The player gains a Vision BEFORE they work on a level or puzzle.
You see, having a vision really IS something. It's the ability for full engagement in something you want to make happen. That engagement will make you forget to eat, forget to sleep, forget that person who cut you off while driving to work this morning. "Without Vision, the people perish."
What stood out to me in one of the youtube "Here are all the cool games we have for MP7!" videos, was that they mention "Achievements". This was a feature in Xbox360. They are sort of like badges you can earn, and then when someone looks at your game profile (like all those girls who keep checking out which guys have earned the best achievements)... well you get the picture. Achievements are essentially a marketing tool to promote the platform, and they also provide the gamer a benefit in that they add visibility to parts of the game that haven't been reached yet.
This reminds me of my resume. I get to take that resume to an interview, and the interviewer looks it over and says "so tell me about such and such". But painful as it seems - it's true. I really don't care about such and such. Because that was yesterday's news. And yes, it probably comes through in my voice.
So now I'm in the middle of creating a game. I think it's worth going broke for. Call me crazy. And one of the features I'm looking forward to putting into the game is "Visions". Instead of telling the player "You've gained the following worthless Achievment!" I'm going to tell them "You've gained the following Vision!" The player gains a Vision BEFORE they work on a level or puzzle.
You see, having a vision really IS something. It's the ability for full engagement in something you want to make happen. That engagement will make you forget to eat, forget to sleep, forget that person who cut you off while driving to work this morning. "Without Vision, the people perish."
Monday, January 3, 2011
Javascript Doesn't have Goto
Think that Goto is never needed in code?
Here:
if (conditionA) {
if (conditionB) {
if(conditionD) {
codeD();
}
} else {
codeNotB();
}
} else {
if (conditionC) {
// wouldn't it be nice to put a Goto to the test in conditionD above?
if(conditionD) {
codeD();
}
} else {
codeNotC();
}
}
I'm encountering exactly this. Obviously I could add a function - but it's messy when there are many nested for loops and variables that will have to be passed, and a Goto would be so simple. Sorry - not in Javascript.
Wish I had switched to C# (which does support goto). Ugh!
Subscribe to:
Posts (Atom)