X-Git-Url: http://git.subgeniuskitty.com/obfuscated-c/.git/blobdiff_plain/435f6fd05819ba1cb8af9c329fcb1c02dbabe25c..0cf6eab78b1cf8a229ffbc4e80900383c20d2068:/brainstorming.md diff --git a/brainstorming.md b/brainstorming.md deleted file mode 100644 index 66d9f33..0000000 --- a/brainstorming.md +++ /dev/null @@ -1,47 +0,0 @@ -# Overview # - -A few thoughts for use in future obfuscated programs. - - -# Digraphs, Trigraphs and Syntax Highlighting # - -At this point, trigraphs betray their presence by requiring compiler flags, -making any direct benefit for obfuscation dubious. - -However, trigraphs cause many syntax highlighting packages to incorrectly -highlight the source code. For example, the following code snippet frequently -displays the `exit(0);` line as code rather than comment when processed by -syntax highlighting programs which miss the trigraph `??/` converting to `\`, -thereby escaping the newline and creating a two line comment. - - // Should I exit early?????/ - exit(0); - -As long as syntax highlighting is kept sane elsewhere in an obfuscated program, -the user may gradually come to trust it, perhaps allowing an instance or two of -trigraph-induced syntax highlighting failure to slip past the reader. - -Of course, readers may run the equivalent of a search and replace, condensing -trigraphs to their single character equivalent. Since the CPP does an -equivalent search and replace before performing any other processing, this is -safe. On the other hand, digraphs are dealt with during the tokenization -process, meaning that a simple search-and-replace by the user is not -necessarily a safe transformation of the source code. Is it possible to include -two important digraphs hidden amongst frivolous usage, such that - - - one digraph breaks syntax highlighting in a useful way, like the example - demonstrated above, and - - - the other digraph isn't a real digraph, rather being something which breaks - the program if digraphs are converted with a simple search-and-replace? - -One possible example of the 'false' digraph would be embedding the characters -inside another token, perhaps a multi-part string split across multiple lines? -If a naive search-and-replace would convert the string into something -syntax-breaking, then the reader may avoid doing a digraph conversion before -reading the source, despite knowing such digraphs are there, and thus may be -tricked into believing lies from their syntax highlighter. - -I suppose that leads to the natural question: Do people typically do a -search-and-replace for digraphs when reading obfuscated code, or do they use a -more language-aware method?