Q: Why is the tool called Tigress?

A: Well, there's the Man-Eating Bengal Tigress of Jowlagiri who randomly killed 15 people. And then there's Master Tigress, who, when growing up in an orphanage was feared by the other children because of her "destructive temper and strength." And, then there's the Tigress/Paula Brooks/the Huntress/Mrs. Menace who was a "skilled hand-to-hand fighter whose nails were once sharpened like talons."

So, there are some powerful, lethal, destructive, random, kick-ass Tigresses out there.

But, yeah, we totally just made it up.

Q: Can I be sure this tool will generate correct code? Have you proven the transformations correct? Or, do you just test? If so, how?

A: Diversity definitely causes a problem with testing. Since Tigress' actions are driven by a seed, just because a test passes once, or 10 times, doesn't mean it will pass the next time. And, just because a test passes with three transformations T1,T2,T3, it doesn't follow that the sequence T1,T3,T2 would pass, or that a slight change to one of the arguments wouldn't make it fail. We currently follow the following testing procedure:

for T in {all transformations} do
   for O in {important combinations of options to T} do
      for C in {806 C test cases (gcc torture tests, etc.)} do
         for S in 10 random seeds do
            C' := Tigress[T,O,S](C)
            execute gcc(C') and compare the output with gcc(C).
         end
      end
   end
end

for T1,T2 in {all pairs of transformations} do
   let O1,O2 be "worst case" options to T1,T2 in
   for C in {806 C test cases (gcc torture tests, etc.)} do
      for S in 10 random seeds do
         C' := Tigress[T2,O2,S](Tigress[T1,O1,S](C))
         execute gcc(C') and compare the output with gcc(C).
      end
   end
end

Q: How can I be sure Tigress doesn't deliberately put malicious code in the generated code? With two levels of virtualization, for example, it would be easy to sneak in something in the bytecode that's pretty difficult to detect, right? And, since Tigress isn't currently open source, I have no way to examine it myself.

A: There is no malware deliberately inserted. You have to take my word for it. And, if you can't trust a Swede, who can you trust?
Q: Why is this a binary-only distribution? Why aren't you sharing source?

A: As noted above, in a system like this it is easy to insert secret malicious code, since the output is, well, obfuscated, and supposed to be hiding things. I therefore want to be in control of the source myself, so that I can make guarantees such as the one above. We're hoping to make Tigress a plug-in architecture in the future (CIL 1.7.2 supports this), and that will make it easier to contribute to the system even without source code access.
Q: Seriously, why aren't you sharing source? Given your work on repeatability and sharing in Computer Science, aren't you being hypocritical?

A: No, we're not being hypocritical. As you can read in our technical report , there are plenty of situations when code sharing is not possible, or desirable. Issues of security and privacy come to mind. Also, our proposal is not to require everyone to share all their research artifacts all the time (this would be naive), but rather to require full transparency with respect to the level of sharing a particular project will support.
Q: What is the best way to learn what Tigress can do, now that I can't read the source?

A: The best way to learn what Tigress can do is not to look at the source (which is pretty complex) but to treat Tigress as a black box, feeding it small input programs, examining the output, changing one of the options, and repeating the process. The fact that Tigress is C source-to-source (rather than, say, binary-to-binary), makes this particularly attractive. Also, in the online documentation many of the transformations provide examples of transformed code.
Q: I'm getting this error: for loop initial declarations are only allowed in C99 mode. What should I do?

A: Tigress supports the C99 language. Depending on your compiler, you may have to add a switch (such as -std=c99 for gcc) to indicate this.
Q: What's up with the naming scheme? "Purple Nurple?" Really?

A: I tend to wear lots of purple.
Q: I love the naming scheme! What color will Tigress 3.0 be?

A: I don't know! Send us suggestions!

Q: Nothing works! Whatever I do, I just get parse errors:

/usr/include/sys/stdio.h[39:80-86] : syntax error
Parsing error
Fatal error: exception Frontc.ParseError("Parse error")

A: Let me guess, you're on a Mac. See this!

Q: Nothing works! Whatever I do, I just get this parse error:
```
/usr/include/bits/mathcalls-helper-functions.h[21:12-28] : syntax error
Parsing error
Fatal error: exception Frontc.ParseError("Parse error")
```
A: Let me guess, you're using a recent version of glibc and you're including math.h. See this!
Q: Nothing works! Tigress just gives a weird error and exits!

A: Run uname -a to verify that you're running on the platform (64-bit Linux, etc) for the version of Tigress you downloaded.
Q:My program works (albeit compiles with a few warnings) but after I've run it through tigress it crashes!

A:If your program doesn't compile cleanly it may well not work when obfuscated by Tigress. For example, say that you forget to include stdlib.h in your code. gcc may complain with
```
foo.c:51:27: warning: implicitly declaring library function 'malloc' with
      type 'void *(unsigned long)' [-Wimplicit-function-declaration]
```
but, your code still works. However, when tigress processes your code, it doesn't know malloc's prototype, and will assume that it returns an int, and not void*. Bad things will happen when a void* gets truncated to an int. Moral of the story: make sure your code compiles cleanly before obfuscating it.

Frequently Asked Questions