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.

And why is this site tigress.WTF? Really? A little sophomoric, no? Sure, but WTF is what we're hoping a reverse engineer will say when they look at the Tigress-generated code, so it fits.

No.

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

The bottom line is that you have to run all your tests before and after obfuscation,

Good question. With two levels of virtualization, for example, it would be easy to sneak in something in the bytecode that's pretty difficult to detect. And, since Tigress currently isn't open source, there is no way for users to examine it themselves.

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?

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. 

So, given our work on repeatability and sharing in Computer Science, aren't we being hypocritical? No, we're not. As you can read in our CACM paper, 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.

Also, we regularly share the Tigress source with colleagues in academia. You just have to ask.

Then, what is the best way to learn what Tigress can do, now that you can't read the source? 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. 

I'm getting this error: for loop initial declarations are only allowed in C99 mode. What should I do?
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.

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")
Let me guess, you're on a Mac. We thought we fixed all these isses... They stem from Apple adding new syntax to declarations. We might have missed some. Let us know.

Tigress just gives a weird error and exits!
Run uname -a to verify that you're running on a 64-bit platform.

My program works (albeit compiles with a few warnings) but after I've run it through tigress it crashes!
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.