Bug#523323: openarena-data: missing source code

Simon McVittie smcv at debian.org
Sun Jul 18 18:41:11 UTC 2010


On Thu, 03 Dec 2009 at 02:30:39 +0000, Simon McVittie wrote:
> As well as applying the attached, it's also necessary to repack the
> orig.tar.gz, replacing pak0.pk3 and mp-pak0.pk3 with versions that have are
> output by the included strip-qvms.pl. This will truncate any vm/*.qvm to
> 0 bytes long.

I've been reconsidering the approach I was using before, since it's pretty
ugly, and every time we change the format of the extra info provided, we'd
need to re-upload openarena-data (yuck). So, I think it's worth getting it
right first time!

The approach I'm now planning is:

* QVMs have a magic number in the header, with two possible values identifying
  variations on the format. Add a third value, which means "load native code
  instead", and patch the engine to understand it

* Write a C program that can construct QVM files with a desired CRC32 by brute
  force. Make some QVMs with the following contents:

  - the magic number to mean "go and load the native code"
  - whatever random rubbish the script generated to get the desired CRC32

  On my laptop, it takes seconds to brute-force this using zlib with the
  attached program:

  searching for xxxx such that NTVExxxx has CRC32 0x00031337
  collision found: xxxx = 0x6fb2d782 (in this machine's endianness, whatever that is)
  ./a.out 0x31337  26.11s user 0.00s system 99% cpu 26.139 total

* Replace each QVM with a brute-forced one constructed as above

* While we're repacking the source tarball anyway, it would be more transparent
  if we decompose the PK3 files into their component files plus an (ordered!)
  file list, used that as the orig tarball, and zip up the PK3 file during
  build; we could also check for mismatches during build

Regards,
    Simon





More information about the Pkg-games-devel mailing list