1. BUGSWORLD It CAME from Aaron Shbeeb – Eugene Talagrand Building a better bug – by any means necessary

2. BUGSWORLD – THE GAME Students program bugs using primitives such as move, turnleft, turnright, infect Each bug is aware only of the state of the square in front of it – no other information is available The goal is to infect all enemy bugs

3. BUGSWORLD – beating the game Building the ultimate bug is hard – complex artificial intelligence is near impossible, and randomness is too great a factor The CIS 321 course series encourages students to read Client.cpp to understand the source code. Let’s be model students and try to break the code

4. Part I – Why information is good Bugs don’t get enough information to be smart. A bug species with information about the entire world could: Move defensively, avoiding enemy bugs Sneak up from behind for surprise attacks Amass in groups, and watch each other’s backs Hunt and kill remaining survivor enemy bugs

5. Part I – Getting more information Unfortunately, the server does not transmit any information to the bug Client other than what’s available through the Bug programming language However, one piece of code does get this information – the Display! Next stop … merging a Display client into a bug Client.

6. Part I – Merging Client and display The Client and Display were not meant to share information Problem – no way to associate a given bug on the display with the currently executing bug in the client Solution! Pick apart the network protocol and reverse engineer the server’s Hash function that sends messages to the Client and Display!

7. Part I – Merging Client and display Both the Client and the Display have a main event loop to send and receive messages to and from the server. Merging the loops leads to code that is twice as slow as ‘legit’ clients Bugs skip turns!

8. Part I – Merging Client and display Problem: Bugs skip turns, the code is too slow Solution! Implement a multithreaded client with two main loops that connect through message queues. Put that 660 knowledge to use Problem! RESOLVE is not MT safe! (Crash!)  Pointer_C uses global allocation tables  The Text object uses a global resource pool  Character_I[0]Stream uses non-reentrant code

9. Part I – Merging Client and display Problem: RESOLVE is not MT safe Solution! Bare metal C reimplementation of the Client and Server cores. Aaron’s ShbeebLib RESOLVE-workalike with a good dose of mutexes thrown in. It works!  Time to take some advanced AI classes!

10. Part II – Exploiting the protocol Why play fair when you don’t have to? Intelligent bugs are nice, but crippling other bugs is way cooler The server doesn’t check the source client for SKIP requests – generously offer to send SKIPs on behalf of other bugs!

11. Part II – Exploiting the protocol SKIPping other bug’s turns This wastes your bug’s turn. However, an intelligent species can program bugs that are in no danger of being infected to SKIP the turns of enemy bugs that are in danger of infecting friendly bugs.

12. Part II – Exploiting the protocol Superpowers It’s still unclear if the server checks how many times a bug moves per turn. Experimental results show the server acting very peculiarly when sent many moves per bug per turn Bug BLIND_FRENZY: Move Move Move Move Move Infect Turnleft

13. Part II – Hacking the Server The ULTIMATE superpower – controlling the server Possible through an exploit of /usr/class/sce/bin/rcpp-c++ Allows any student to arbitrarily read, add, modify, and delete any file pertaining to RESOLVE, including the Busgworld server