Skip to content

Instantly share code, notes, and snippets.

View arvid220u's full-sized avatar

Arvid Lunnemark arvid220u

View GitHub Profile
from typing import List, Optional, Tuple
from battlehack20.engine.game.game import *
def log(msg: str):
"""
Type-agnostic method.
Logs a message.
@stecman
stecman / dump-pyc-with-gdb.md
Last active March 25, 2024 09:20
Dumping all bytecode from a packaged Python application

This is a technique for extracting all imported modules from a packaged Python application as .pyc files, then decompiling them. The target program needs to be run from scratch, but no debugging symbols are necessary (assuming an unmodified build of Python is being used).

This was originally performed on 64-bit Linux with a Python 3.6 target. The Python scripts have since been updated to handle pyc files for Python 2.7 - 3.9.

Theory

In Python we can leverage the fact that any module import involving a .py* file will eventually arrive as ready-to-execute Python code object at this function:

PyObject* PyEval_EvalCode(PyObject *co, PyObject *globals, PyObject *locals);
@simonlindholm
simonlindholm / battlecode-2017-vulnerabilities.md
Last active December 4, 2019 23:23
A short write-up of two Battlecode vulnerabilities and a hypothetical backdoor

Last year's Battlecode engine did JVM instrumentation to sandbox players on the same team from each other, and to limit the amount of computation they were allowed to do. We found two fun vulnerabilities related to the latter part.

The first vulnerability

The process by which the bytecode instruction limitation was done was by decompiling .class files, adding in instruction-counting instructions in relevant places, and them re-compiling them and running the modified executable. More concretely, say the program contained a method like: