cimnine's Tech-Blog

Fancy stuff about my technical life

What this all about is....

svn checksum error

posted by cimnine @ 6:09pm, Wednesday 6 January 2010.

I just had this scary problem: "SVN: checksum missmatch"

Don't worry, it's easy to fix.
If you use a berkleyDB as filestore, please read here: http://ilovett.com/blog/programming/subversion-checksum-error
If you use FSFS, you'll be fine with me. :)

Important: You do all action on your own risk! The solution below worked for me, it may or may not work for you! You're said now to backup your repositories files NOW!

Good. Now to your problem.

First, make sure you have a good hex editor. hexcurse worked pretty good for me and is available in the debian & ubuntu repositories. (So install it with "apt-get install hexcurse")

First, execute "svnadmin verify /path/to/your/svn/repo".
You should now get messages like "Verified Revision 1, 2, ...". And the last message is a "Checksum mismatch. Expected XXXX. Calculated YYYY." (Something in LIKE that, I'm writing this out of my mind.)

Now you know which revision is the bad one. (svnadmin showed you the last good one, not the corrupt one!).

Now cd to /path/to/your/svn/repo/db/revs. (eg. ~ $ cd /var/svn/repo)
Now cp YOURBADREVISIONNR to YOURBADREVISIONNR.bak . (eg. repo $ cd 178 178.bak)
Now execute hexcurse with YOURBADRESISIONNR (eg. hexcurse 178).
The CTRL+F for XXXX.
Now replace the hexvalues of XXXX with the hexvalues of YYYY.
Save the file.
It should be fine now.

I hoped this worked for you too!
Otherwise, try to email me. You'll find the address on my webpage.

~Chris

comments (0)

Flash Games

posted by cimnine @ 11:35am, Thursday 3 December 2009.

I don't know why, but a lot of flash games are very poor designed in many aspects.
I'll explain some common mistakes in an example:
Kitag, a Swiss cinema group, put up a Christmas game this year, developed (at least hosted) by a company called netvision. Kitag raffles prices totally 3'120 CHF worth. (That's currently about the same in USD).

The game's a very classic jump-and-run game in Mario manner: Santa has to collect some items and get to the end of the level. The more items he collect, and the faster you'll get through the level, the more points you'll get. It's possible to invite friends to the game. Each of your friends gets an email with a one-time-link to register. For every registered friend you'll get another 500 points.

The design of the game is poor in several aspects:
  • Data Transmission: All data gets submitted without any encryption. Usernames, Passwords, Email-addresses; just everything. And we all know how lazy normal users are: Same username, password and mail for everything. Plus: This would stop less advanced people from exploring the underline protocol of the game.
  • Data Integrity: There is no check if the data sent by the client could be faked or not. The score made in each game is submitted as POST parameter (like points=42) without any validation, like a checksum. It's very easy to fake such a request plus it is very easy to set a new, just slightly higher, score like this. There are no time limits for submission (which should be at least the absolute minimal time it takes to get through the game). As I already mentioned, there's no checksum, which would, even if its algorythm was hardcoded, force a person to disassemble the swf file. But this way is clearly against the defined rules and could en up in instant exclusion.
  • Invitations: This more a fail-by-decision, as a fail-by-design. It would be an effort of some hours to write a script getting mails from a mail server and register on the link given in the mail. (Where we have the same problem with the full accessible protocol again.) This could get me lots of points a day - and is not clearly against the rules.
I don't know if only these more easy games are affected by such weak designs, or if Flash-Developer in general are less concerned about data intergrity and security.
But it's at least the second game I examined and it was very easy to trick a better score. (I'm talking about speedfingerzzz from the Swiss Post. It's design is a bit robuster, but not robust enough. It's running for the second year now - without any improvments and the same protocol.)

In my opinion, the only way to effectively secure a flash game is to verify each action a user does on a server. The best way would be to do every calculation on the server, but this isn't that fast if you have lots of users, or if you have users with slow internet connections. The other way I'd propose it to log every action in the client, send it for evaluation to the server, and send the points made back to the client. The important part is: The server calculates how many points the user made, not the client!

~Chris

comments (1)

Breaking your company's proxy with SOHT

posted by cimnine @ 10:07am, Friday 16 October 2009.

After years of trying solutions to break my company's proxy, I finally found the tool SOHT.

What you need:
  • Web-Access to the internet in general
  • HTTPS allowed.
  • The credentials of your company's firewall. (hostname, port, username, password)
  • A Server/PC which
    • is always on an has broadband connection. (best would be a symetric connection)
    • has a running Java Servlet Container (f.e. Tomcat/JBoss/...)
    • has a running HTTP-Proxy (f.e. tinyproxy)
    • for HTTPS-Support: An Apache with SSL and mod-proxy
  • A workplace-PC which
    • Has Java or .NET runtime installed
    • Allows you to configure a proxy or to run (portable) firefox
  • minor technical knowhow
  • some time
What you get:
  • The ability to access every webpage you like
  • The ability to run every tool you like (ssh, irc, ...)
Please note:
Be aware, that what you do might be against your companys rules and this could end up in getting fired!
There is no warranty that this works.
This guide should provide everything you need. If you need more use google or just start thinking. It took me years to figure a way out of my company!

Let's start:
  1. Make shure your Java Container is running with a least Java 1.5
  2. Download and deploy the soht server war-file. (In Tomcat this can be done in the 'Tomcat Manager')
  3. Adjust the Security Manager Settings of your Servlet Container if you have the security manager running. Otherwise you will not be able to change the server-config (eg make users) and to make any tunnel.
  4. Install a HTTPProxy on the webserver. Set it to listen on port 8888. Restrict it to only accept connections from localhost (127.0.0.1).
  5. Download the soht client to your workplace-pc. (If you want to / have to use the .NET client, please try yourself. But it should be about the same.)
  6. Extract the ZIP to a folder.
  7. Windows only:
    1. Copy a 'javaw.exe' (normally in "%JAVA_HOME%/bin") to that folder. Rename it to 'soht.exe'. (Now you are able to kill the process if it hangs once.)
    2. Create a shortcut to 'soht.exe'. Name it 'soht-client' for example. Adjust the 'target': Add " -jar soht-client.jar" to the end of the line. The full line should look now like ' "C:your_soht_foldersoht.exe" -jar soht-client.jar '
  8. Linux/Unix (Mac OS X is a UNIX too):
    1. start soht with this command: "javaw -jar soht-client.jar &"
  9. Open the 'soht.properties' file with a text editor. (Windows: Notepad; Mac: TextEdit; Unix/Linux: You know how.)
    • Fill in your soht server url. If you have users configured (not described here), fill them in too.
    • If you have problems that connection begin to hang, set 'server.stateless=true'
    • Fill in your companys proxy credentials. Set 'proxy.useproxy=true'
    • Add a tunnel from port 8888 to host localhost:8888 like this
      "port.8888=localhost:8888" (Note: SOHT can handle binary protocols, as long as they are TCP based! So SSH can be tunneld to.)
  10. Start the soht-client.
  11. Open your browser. Set the proxy for http and https to 'localhost:8888'
  12. Good luck.
If something is not working:
  1. Open the a shell. (Windows: Start->Run->"cmd"->Ok; Mac: CTRL+Space->"terminal"->[Enter]; Unix/Linux: You know how.)
  2. Navigate to the soht-client folder.
    • Windows:
      1. Enter Drive: "C:"
      2. go step by step to the folder: "cd to", "cd your", "cd folder"
    • Linux/Unix (Mac OS X is a Unix too):
      1. go to the folder: "cd /where/ever/your/folder/is"
  3. Everyone: Enter "java -jar soht-client.jar"
    You should see now the output of the soht-client. And there should be written why it is not working. Now turn on your brain ;)
For more safety: SSL Encryption
  • It depends how advanced you are, but I prefer my Apache HTTP Server to handle my SSL, instead of Tomcat. (It's also because I don't have that many IPs).
  • What you need:
    • A recent, configured Apache HTTP Server with mod-proxy.
    • A SSL-Certificate. (Self-Signed, CA-Cert, VeryTrust, that doesn't matter: SOHT accepts them all.)
    • Again, some time and a bit of technical knowhow.
  • How to do it:
    1. Open your apache configuration. I can't tell you which file, cause XAMPP, Debian, RedHat, Apple and everyone has there one way to organize the config files.
    2. So, 'somewhere', where your have a SSL-Encryption, add something like this:
              ProxyRequests off

              <Proxy *>
                      Order deny,allow
                      Allow from all
              </Proxy>

              ProxyPass /soht/ http://localhost:8080/soht/
              ProxyPassReverse /soht/
    3. Restart your Apache (or just reload the configs)
    4. Don't forget to adjust the URL in soht.properties (on the client side)
If something is not working, try to think why, try google, try call a friend. It's also worth to read what the author of SOHT wrote on his page!

I hope it helped you. I know it's not the definite guide, and it's not for beginners. I apologize. But I don't like writing that much and you should have an idea now how a SOHT setup could work.

~Chris



Log In

Search

Articles