From CatchChallenger wiki
Jump to: navigation, search


Databases manipulation

  • In case of databases manipulation: Always drop the used item from database, before insert update the new data generated.
    • That's prevent hack on crash (if cash you lost the item used, but not use the item without drop from the inventory)
    • Right way: You use recipe: Drop the recipe from database, if crash after this you lost you recipe, add the learned recipe the the databases.
    • Wrong way: You use recipe: Add the recipe into the db, if crash after this you have you recipe and your recipe learned.

Anti DDOS and cost infrastructure

See: Anti DDOS and cost infrastructure


To limit the DDOS attack effect and maximize the botnet required


Async to prevent a extern element (under mad effect as DDOS) freeze the program See: database and async


All is after the authentication, then we need hardened the pre auth part.

  • If an account create DDOS, it's easy to block it
  • In case of automatic account creation, you need limit the creation rate


  • Hash(password + random datas) = protect the auth without encryption
  • Double hash to protect from database dump
  • Salt to protect agains the rainbow table
  • Multiple database from various place into the world (the auth have their own database). Do the right with better security.



  • All the communications need be encrypted
  • All the destination need to be authenticated: save the public key or public key from i2p network
  • The logins server can be used as reverse proxy to hide the game server address
  • I2P can hide the server location, clients, crypt the communication and authenticate the destination
  • The gateway to pass from one network to other (TOR/I2P → internet), implie packet rewriting, then you need trust into him
  • Why I2P? If a node is disconnected, the packets are rerouted and the connection kept alive, useful to the permanent tcp connection



Mount your CatchChallenger server under virtual machine on encrypted volume. That's mean, you can't start up automatically the virtual machine. You need start up manually and give the prompted password (need be strong). Prevent physical access. Prevent bug or security break of your server. Grsec + Pax for linux kernel with option PAX_MEMORY_SANITIZE is good idea. See: with I2P


  • Kernel protection
  • Limit the information leak
  • Memory protection: stack protection, buffer overflow (better if hardware accelerated as Intel MPX), ...
  • Lxc security: chroot, better isolation, ...

Quote from Grsecurity: Grsecurity is an extensive security enhancement to the Linux kernel that defends against a wide range of security threats. The PaX project is included, hardening both userspace applications and the kernel against memory corruption-based exploits. Grsecurity includes a powerful Mandatory Access Control system with an effortless automatic learning mode and a host of other miscellaneous hardening features.

Now grsec o PaX is not public, see another way above

llvm and clang

Note: you have similar options with gcc, this not initialise the memory,

 QMAKE_CXXFLAGS+="-std=c++0x -Wall -Wextra -fsanitize=address -fno-omit-frame-pointer"
 QMAKE_CFLAGS+="-Wall -Wextra -fsanitize=address -fno-omit-frame-pointer"
 QMAKE_LFLAGS+="-fsanitize=address -fno-omit-frame-pointer -Wl,--no-undefined"
 /usr/lib64/qt5/bin/qmake -spec linux-clang


Allow easy migrate, backup and you have always access the the guest event if it's hacked.


Brute force the hash for auth

Well, the hash for login is easy to bruteforce, double sha224 and you are ready. It's low security because most user will use easy login or same as their character name.

The pass hash is like that's: pass+/*salt*/"AwjDvPIzfJPTTgHs"+login, to minimize the cpu cycle you can:

  • add data to your sha224: pass+/*salt*/"
  • dump it
  • try in loop:
    • test all the login
    • set the dump