For demonstration purpose I put my experiment with a compiler backdoor in a public repository
It's part of my academic project to work on provable compiler security.
I tried to do it according to the "Reflections on Trusting Trust" by Ken Thompson, not only to show a compiler Trojan horse but also to prove that we can discover it.
What it does is inject arbitrary code to the next version of the compiler and so on.
Regards \n
On Sun, Sep 12, 2021 at 12:29 PM Niklas Rosencrantz <
niklasro@gmail.com> wrote:
>
> For my experiment I put some search-and-replace in tcc_add_file_internal in the file libtcc.c, then built that version of tcc with gcc and installed it on my local system.
>
> I took a video of it to make it easier to follow what happens
>
https://www.youtube.com/watch?v=qy-VLpQE6KM>
> Then use that tcc to compile the distributed sources to the "next" version of my tcc.
>
> Now that next version contains my bug inserted from my evil binary parent tcc, without the bug appearing in the sources that are compiled.
> One could perform diverse double-compiling now to show that the bug from the ancestor is not in the sources I compiled, rather it was inserted at compile-time.
>
> It's merely an exercise on my part but I was a bit surprised that there was no readily available self-contained version of the Ken Thompson compiler Trojan.
>
> Any comments or ideas?
>
> Regards
>
> On Sat, Sep 11, 2021 at 11:45 AM Niklas Rosencrantz <
niklasro@gmail.com> wrote:
> >
> > Great I think it worked.
> > It looks like I could compile tcc with itself using the --cpu=x86_64 as described.
> > What I want to try for research and academic purpose (about compiler security) on my local machine is to experimentally sneak in a RoTT (The Thompson Compiler Hack from
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf).
> >
> > I want to compare two binaries where one is from a tampered tcc that I changed myself to include the Thompson Compiler Trojan to prove that a certain procedure can mitigate it (the diverse dual-compiling). Then use that evil tcc to compile the next version of tcc to include the invisible Thompson Trojan and then prove that a diverse dual-compilation is a working countermeasure.
> >
> > But I'm not sure where exactly to inject the code as described in figure 3.2 and figure 3.3 in the article.
> > I believe it's somewhere in the struct TCCState but I'm still looking after how to replicate and then mitigate a compiler trojan.
> >
> > Sincerely,
> > Niklas
> >
> >
> >
> > On Sat, Sep 11, 2021 at 6:53 AM Christian Jullien <
eligis@orange.fr> wrote:
> > >
> > > Hi,
> > >
> > >
> > >
> > > On macOS, tcc has several limitations and it supports only x86_64 backend.
> > >
> > > On M1, it works thanks to Rostetta translation.
> > >
> > > You can compile tcc with a boostrapped tcc if you use –cpu=x86_64 ./configure flag
> > >
> > >
> > >
> > > I don’t think we are too far from a native arm64 backend as we have already all the stuff for it but nobody is working on it AFAIK.
> > >
> > > I’m ready to help volunteers but I have no enough knowledge on the binary forma to do it myself.
> > >
> > >
> > >
> > > From: Tinycc-devel [mailto:
tinycc-devel-bounces+eligis=
orange.fr@nongnu.org] On Behalf Of Niklas Rosencrantz
> > > Sent: Saturday, September 11, 2021 03:54
> > > To:
tinycc-devel@nongnu.org> > > Subject: [Tinycc-devel] Can tcc compile itself with Apple M1?
> > >
> > >
> > >
> > > Hello,
> > > It worked to compile and run tcc with Apple M1 but I could not make it compile itself.
> > >
> > > I get the following error message
> > >
> > > error: 'tcc' failed to compile conftest.c.
> > >
> > > % ./tcc conftest.c
> > >
> > > tcc: error: R_AARCH64_(JUMP|CALL)26 relocation failed (val=100001176, addr=1000010cc)
> > >
> > > _______________________________________________
> > > Tinycc-devel mailing list
> > >
Tinycc-devel@nongnu.org> > >
https://lists.nongnu.org/mailman/listinfo/tinycc-devel