Deliverable Statement

Create a version of the Tiny C Compiler (also known as TinyCC or TCC) that "miscompiles" itself, adding in an extra bit of code whether or not it is included in the source code of the program.

Objectives

• Create a snippet of code that is injected by the tcc program
• Find a part of the source code of the Tiny C Compiler (tcc, or TinyCC) that can be used to uniquely identify it (the "signature"), and modify the source code such that it prints an identifiable message to the terminal when compiling itself.

Discrete Tasks

• Kickoff Meeting
• Week 1
  • Find the unique signature to use, and write a C program to detect it
  • Find the optimal place to inject the code
• Week 2
  • Modify the tcc code to print a message when compiling code containing that signature
• Weeks 3-4
  • Make tcc inject the signature-detection code into its own output

Set up a development environment with QEMU available to run foreign binaries, and the hed hex editor.

• install hed from source
• install qemu binaries
• set up binfmt-misc support, and register QEMU binaries for foreign architectures

Make the modified TCC from Milestone #3 only inject the signature detection code if it's not already present, and make it also "miscompile" GNU nano so that the message reading "Welcome to nano. For basic help, type Ctrl+G." is replaced with a different 45-character string to be determined. After that, use diverse double-compiling to create a "clean" version of TCC

• Weeks 1 - 2
  • modify evil-tcc's injection to avoid duplicating itself when perpetuating itself - i.e. only injecting itself if it's missing from the source code
• Week 3
  • Add functionality to replace nano's welcome message

Modify the AMD64 version of tiny clear elf to be dynamically linked against libtinydynclearelf.so and create that ELF shared object which provides wrappers around the two syscalls used.

• Kickoff meeting
• Week 1
  • Adapt A Whirlwind Tutorial on Creating Somewhat Teensy ELF Executables for Linux to work for 64-bit systems
• Week 2
  • Create a library called libtinydynclearelf.so that implements 2 functions - tdce_clear and tdce_exit, to print the escape sequence and exit the program, successfully, and a simple program that links against it and calls those two functions (both in a normal programming language, likely C).
• Week 3
  • Create a drop-in replacement for libtinydynclearelf.so that was made by hand in the vi-like hex editor known as hed,
• Week 4
  • Replace the program that calls those functions with one made in hed.

Implement tiny-clear-elf binaries for the 6 or 7* remaining architectures planned. tiny-clear-elf binaries are defined as follows:

• ELF executables with properly-structured ELF header and Phdr, but no section header, made in the vi-like hed hex editor
• less than 256 bytes, assuming that's possible within the constraints of the architecture, otherwise as small as possible.
• only makes 2 Linux syscalls, one of which writes "␛[H␛[J␛3J" to STDOUT, and the other exiting with error code 0. No extra functionality, and no parsing of arguments

* armhf and armel are technically the same architecture, but armhf can take advantage built-in support for hardware floating point calculations, which not all arm processors have. Debian has separate repository architectures for the two, and I took my list of architectures to target from the list of architectures that the current stable release supports. The same binary will be used for both in this project, because I don't see how the write and exit syscalls would need to deal with floats.

• Kickoff meeting
• Week 1 work
  • armel/armhf implementation
  • aarch64 implementation
• Week 2 work
  • ppc64el implementation
  • s390x implementation
• Week 3 work
  • mips64el implementation
  • mipsel implementation
• Demo
  • run binaries with QEMU and binfmt_misc

Thinking about either Tiny Clear ELF or an LTE connection monitor