Reverse Engineering

[Gadgetoid]

I've got the majority of the Airmash protocol figured out- enough to connect to a server, receive and parse data, and pilot a ship. However, I would very much like to build out Enum types for things like "protocol" and other ambiguous attributes in some of the packets.

I'm in the process of adding "TODO" notes into the code where it's unclear to me what a packet, or part of a packet, does, or what its expected ranges and human-readable values might be.

Player Commands (Client -> Server)

Player LOGIN

• What are the values for protocol?
• What's the minimum/maximum allowed range for horizonX and horizonY and what effect does it have
• What are the available flag types/supported two-letter country codes?

python-airmash/airmash/packets.py

Lines 4 to 18 in 2748117

	player_commands['LOGIN']: Struct(
	# Log in a player
	# Players can log in anonymously by providing a 'session' value of 'none'
	# Protocol: should be 4, TODO: enum is needed to describe the other available protocols
	# Name: is the player name, up to 255 chars
	# HorizonX: is the game screen width / 2
	# HorizonY: is the game screen height / 2
	# Flag: the two-letter country code of desired flag
	'command' / Default(PlayerCommands, 'LOGIN'),
	'protocol' / Int8ub,
	'name' / Text,
	'session' / Default(Text, 'none'),
	'horizonX' / Int16ul,
	'horizonY' / Int16ul,
	'flag' / Text

Player BACKUP

• What does this do? Is this an alternate to "LOGIN" that allows us to resume a session with a particular token?

python-airmash/airmash/packets.py

Lines 20 to 24 in 2748117

	player_commands['BACKUP']: Struct(
	# TODO: Figuere out what this is for
	'command' / Default(PlayerCommands, 'BACKUP'),
	'token' / Text
	),

Player ACK

• Under what circumstances do we need to reply to the server with an ACK? It seems we have PING/PONG for keepalive. Should we ACKnowledge every received packet?

python-airmash/airmash/packets.py

Lines 34 to 38 in 2748117

	player_commands['ACK']: Struct(
	# TODO: Figure out what this is for
	# Have managed to maintain a connection to the server without ack-ing any packets
	'command' / Default(PlayerCommands, 'ACK')
	),

Player COMMAND

• Can we quantify the com field with all available commands?

python-airmash/airmash/packets.py

Lines 56 to 63 in 2748117

	player_commands['COMMAND']: Struct(
	# Send a command to the server, eg: to switch to spectate mode: com = spectate, data = player ID
	# com: command to send
	# data: additional data for command
	'command' / Default(PlayerCommands, 'COMMAND'),
	'com' / Text,
	'data' / Text
	),

Player LOCALPING

• What is this for?

python-airmash/airmash/packets.py

Lines 103 to 107 in 2748117

	player_commands['LOCALPING']: Struct(
	# TODO: figure out what this is for
	'command' / Default(PlayerCommands, 'LOCALPING'),
	'auth' / Int32ul
	)

[Gadgetoid]

I've spend some more time watching incoming data from the server and added some new types to disambiguate numerical values:

• PlayerStatus is an Enum that tracks 0 = ALIVE and 1 = DEAD statuses (there may be more?)
• KeyState is a BitField which converts the player keystate from bit-packed flags to a collection of True/False values for each key.
• MissileTypes is an Enum that identifies different missile types. This may be wrong but it seems ships currently have their own set of types (actually the Tornado is the only ship with two types of missile) and type 4 seems to be MIA (haven't observed any types >7 yet)

Types still to document:

• COMMAND_REPLY -> type
• PLAYER_HIT -> type
• PLAYER_UPGRADE -> type
• PLAYER_POWERUP -> type
• GAME_FLAG -> type
• GAME_FIREWALL -> type
• EVENT_REPEL -> mobs -> type and MOB_UPDATE -> type (etc) (what are mobs?)
• EVENT_LEAVEHORIZON -> type
• SERVER_CUSTOM -> type

[Gadgetoid]

It looks like mobs are both projectiles and collectables. I have enumerated mob types (with some guesses yet to be tested/verified), created a new Mob class to store mob telemetry and implemented the mob update commands in test.py