Making an executable difficult to hack

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.

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."

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!

Having a Great Vision

I was recently chatting with a friend about stock trading, where the markets are going, how to survive.  He said "I think working is actually more fun."  I answered "especially when you have a Great Vision." And he replied "Great Vision comes from having an understanding of the technology."

This is absolutely true.  Until you work through technology to the point of clarity of "what is possible?", every little vision will remain foggy.  Your attitude will be horrible: "How the hell can I do that?" and then there's doubt that it can even be done.  Ghosts live their whole lives this way, going from one doubt to the next.  Shriveling away over what couldn't be done.  What a pitiful way to live!  Don't keep company with them.  Don't listen to them.  Don't take on their attitudes.

It takes a lot of digging and finding out what it's going to take.  But once that's clear, then it's just a matter of time, and doing what needs to be done, and the momentum is there that nothing can get in the way of making it happen.  It becomes very focused, and life consuming.

In fact, once that takes place, life becomes completely and wonderfully different: from living in doubt, to living with resolve.

DOS attack mitigation for Google App Engine

Maybe there's a better way - so please feel free to post comments.

For a relatively light loaded app engine server, tracking heavy request loads from the same IP address should be trivial.  This server then would respond to periodic (30 seconds or so) queries from an upload PC asking what IP addresses need to be blocked, and the upload PC issue an "appcfg.py update_dos myapp/" (pipe in your password with --passin, and use the -e <emailaddress> option) to block the app engine server from the DOS attack.

Unity Security and Google App Engine (Python)

I'm relatively new to programming with both Unity and Google App Engine and Python.  I've been playing with them for not even a month now, and ran into a nasty situation today.

Namely, attempting to read any text from a website in Unity doesn't work, unless that website also serves a crossdomain.xml file.  This is explained in some detail here:

http://unity3d.com/support/documentation/Manual/Security%20Sandbox.html

Great!  I'll just add that crossdomain.xml file, and those runtime errors will go away right?  No.  And here I show my flying blind syndrome - I don't know all the ins and outs of app engine yet.  But if you dig deep enough, this is explained with sufficient searching.

The reason it doesn't work to just place the crossdomain.xml file in the project directory, is that the app.yaml file has to be configured to stop expecting every request to the root directory to be handled by the <whatever>.py file, which is what you get when you run the Python tutorial from Google App Engine:

http://code.google.com/appengine/docs/python/gettingstarted/

You'll wind up with an app.yaml file that looks like this:


application: helloworld
version: 1
runtime: python
api_version: 1

handlers:
- url: /stylesheets
  static_dir: stylesheets

- url: /.*
  script: helloworld.py

And they explain it actually very clearly - but for some reason it just didn't sink in:

"Every request to a URL whose path matches the regular expression /.* (all URLs) should be handled by the helloworld.py script."

To get App Engine to serve the crossdomain.xml file, change hte app.yaml file to look like this instead:

application: helloworld

version: 1

runtime: python

api_version: 1

handlers:

- url: /stylesheets

  static_dir: stylesheets

- url: /crossdomain.xml

  static_files: static/crossdomain.xml

  upload: static/crossdomain.xml

- url: /.*

  script: helloworld.py

Then place the crossdomain.xml file in a subdirectory "static" and that's it.  Unity can now use the WWW class to read text from an app engine website.