[Last updated 2005-09-03] Below is a list of various concepts I find interesting, but never managed to finish. This is usually because they're too ambitious (and got started, but I couldn't finish them before I lost all motivation), too mundane to implement (and I couldn't force myself to even try), or simply too ridiculouos to ever consider them seriously. On and off the list: ==================== There is a couple of projects I managed to get quite far, and tend to return to them on a regular basis. They have a non-zero chance of being completed one fine day, so they don't relly constitute the list proper: 1) Asmsh, the delightfully evil assembler shell. The code for asmsh components is mostly in place (http://lcamtuf.coredump.cx/asmsh/), but I never managed to put it together. 2) A nice text-based (UI-driven, though) game engine and story. See http://lcamtuf.coredump.cx/dix.tgz - the engine is pretty much done, the story isn't finished, and I'm afraid it is a bit dated by now. 3) Some of my old projects that should be either continued or extended. There are several popular tools I developed, but that had some major features planned for future versions, or simply are in need of an update. These include Fenris, snowdrop, and, to a lesser extent, fakebust. 4) Hobbyist operating system with uber-cool features (such as, get it, no caps lock support, resume-to-savepoint on reboot, generalized file format abstraction layer, fancy namespace conventions, gpm accidental paste protection, user-customizable virtual directory remapping, new process/execution paragigm, and plenty of security tricks). This started under codename Argante, then evolved into 'hardcore', and then stalled. Will hire henchmen to do the coding when I rule the world at last. The list proper: ================ 1) Class: POINTLESS HACK Title: A truly compatible console video driver One of the features of any EGA/VGA compatible card is that you can redefine fonts on the fly. What is more, nothing stops you from redefining them when the picture is being redrawn. In a typical 80x25 text mode, you can display three lines of characters before you're forced to repeat any (3x80 = 240 out of 256 codes). Let's do that, and then repeat these three lines until the screen is full. This is our display buffer, and we're not going to touch it once prepared. Now, synchronize your program with the card's clock, then define fonts so that the subsequent 240 characters represent a black-and-white bitmap you want to display in three first lines of the screen. This is trivial. Then, wait for the scanline to get past this point, and quickly redefine fonts to map out next portion of the bitmap. To reduce the risk of flicker, you can actually redefine first 80 chars after the first row of chars is drawn, you don't need to wait until all three are done. You probably know where I am going. You want colors, right? That's easy, although a bit quirky. Two colors (out of a configurable palette) can be set for every uber-pixel (8x16), you can also simulate colors by rapidly alternating between two relatively similar shades and color masks. Since you only need to upload new font data (at most over 3 kilobytes) circa 8 times to redraw entire screen, which you want to do at the current refresh rate (50 Hz), this is circa 1.5 MB/s - should be well within the capacity of the card I/O. So you now get a perfect B/W, or a good approximation of probably around 64 colors; with overscan / interlace, you can further boost the resolution probably at least two-fold (1280x700!), and also cause spontaneous epilepsy, vomiting and coma... WHY NOT DONE: I hate blinking text. That, plus mundane low-level hacking involved. 2) Class: HANDY UTILITY Title: Mail bouncer A feature could integrated with PINE and other mail clients to generate a realistically looking bounce message with a permanent error (user over quota, no such address, etc) to fend off annoying stalkers, people you owe money, etc. Standard SMTP error messages should be supported; "596 Recipient deceased" would be handy, too. A poor man's alternative would be a .forward script. You get unwanted mail and forward it to bounce@localhost - the script intercepts it and does all the rest. Suggested by Arturs. WHY NOT DONE: Boring ;-) Writing plugins for mailers is a mundane task. Capturing and accurately simulating responses from various MTAs is also not very exciting. Alas, I would be a happy user of a tool like this. 3) Class: HANDY UTILITY Title: SHAC - show access permissions. A tool that parses symlinks, hardlinks, directory tree permissions, expands groups and so on to come up with the ultimate and definitive list of effective permissions for a resource, and the location they originate from. Come to think about, it's something you can do on Windows, but is next to impossible on *nix, beyond the most obvious cases. Sometimes figuring out why a particular group has to broad or too narrow permissions involves manually traversing, stating and examining all path elements - and that's just a waste of time. *** Done by Ryan Flynn, inspired by this entry: *** http://parseerror.com/shac/ 4) Class: POINTLESS HACK Title: Netpong. Manually reply to ICMP echo packets by bouncing them back with a pad to play the game. Very geeky, beware of ICMP floods. Multiplayer variant possible! WHY NOT DONE: Insane, plus requires some silly fw hacking. 5) Class: POINTLESS HACK Title: Freshmeat mixer / Wikipedia mixer Browsing FM and Wikipedia randomly can get quite boring. Their categories and search capabilities are not impressive, and sometimes, just sometimes, you would like to browse to closely related or somewhat similar topics or projects without running in circles. I wanted to build an associative browser that builds a treeish structure of related items based on keyword / phrasing similarities... and even started doing it, but screwed up. Check out http://lcamtuf.coredump.cx/fmx/ - it sucks. WHY NOT FINISHED: No good idea how to fix it. 6) Class: USELESS RESEARCH Title: Randomness of "random" behavior A research paper on the randomness of "random" keystrokes chosen by the user when instructed to try to come up with something he considers to be entirely arbitrary. This has some interesting implications for password selection and such, but this is only an excuse to research this subject. There is some prior art - such as general observations that humans tend to avoid repeating a single character twice in a "random" stream they're asked to create, even though it would not be such a rare occurence in the real world (per Birthday paradox); and some general statistical research on other types of "random" selections made by humans (such as lottery numbers; but it might be argued many people do not choose randomly here, and use some scheme or "gut feeling" instead) - but nothing that comes close to being comprehensive. Interesting things to check: do humans tend to also avoid sequences of letters (len 2-3) that occur in their native language? In what relation the selection is with the keyboard layout? In what relation the selection is to what we consider to be "lesser random" midless banging on the keyboard (a la "fdsfhdsgjfsd", as opposed to choosing a password)? Etc, etc. Plenty of cool tests and concepts to play with. WHY NOT FINISHED: Failed to collect enough samples (I have a small collection from circa 10 subjects, though, if you are interested). 7) Class: USELESS RESEARCH (perhaps pretty) Title: All-inclusive programming language A programming language in which every text file is a valid program. I think "True" was such a language, but it also seemed to be largely pointless, as it did not produce interesting outputs; my language should actually be usable and, in most cases, give some fascinating and unexpected results for an arbitrary text file (a syntax design challenge ;-) instead of doing nothing, crashing or looping forever. Ideally, the language should be able to execute a poem that produces "Hello world" output ;-) I did some work codenamed Leith (http://lcamtuf.coredump.cx/soft/lx.tgz), and managed to produce a clever variation of cellular automata that, when input data is mapped as pixels in 2D space, produces various pretty patterns - but because of the complexity of this system, and virtually no stable configurations, it seems to be quite impractical. *** Now done in a saner way: *** http://lcamtuf.coredump.cx/wss/ 8) Class: POINTLESS HACK (ridiculously stupid, to that) Title: Text viewer with natural language syntax highlighting. Wonder how would it affect reading performance... but that aside, it should make it easier to spot badly constructed sentences when writting ;-) WHY NOT DONE: Must... resist... urge. 9) Class: USELESS RESEARCH Title: FPGA OS My old idea, actually. Offload most of the basic OS tasks onto a programmable logic chip, leave the CPU almost entirely for userspace. Devise asynchronous mechanisms for as many things as possible to speed things up. WHY NOT DONE: No hardware. 10) Class: HANDY UTILITY Title: Anti-DoS quality-of-service system for Linux. James is working on it, actually. The explanation is quite lengthy, so mail me if you are really curious, but the idea is relatively simple: to have a method of defending against resource starvation connection flood attacks from one or a couple of sources in a transparent manner that does not degrade the service for other users. It's actually quite tricky, and the method I have in mind should work exceptionally well for anything but the most extreme cases (DDoS worm, Slashdot); containing even hundreds of zombies should be easy in no time and without manual intervention. WHY NOT DONE: Mundane work on coding and optimization. Plus, kernel hacking means crashes. But James is not afraid of crashes... 11) Class: USELESS RESEARCH Title: Bad AI I think that my Catty is based on a kinky concept, and that using the Internet as a fact/relation source has some potential. I'm just too lazy to put some actual logic behind the search capability, and so Catty is talking gibberish. WHY NOT FINISHED: Laziness. 12) Class: HANDY UTILITY Title: Good fuzzer. I'm toying with fuzzing quite often - and I found several interesting bugs merely by making my fuzzers more specialized, sophisticated, and optimized for the task than the commonly used "dumb output" ones. Bored of constantly tweaking the code for every single protocol or file format, I have attempted to overcome some limitations of the traditional fuzz experiment by fuzzing the execution path of a client, rather than altering its output - see http://lcamtuf/coredump.cx/soft/bugger.tgz. The problem is, 'bugger' is awfully slow, because it single-steps the victim application, instead of disassembling it and springling int3 insns all over the place. *** Now done: *** http://bunny-the-fuzzer.googlecode.com/ 13) Class: HANDY UTILITY (a bit naughty) Title: Generalized login snatcher. There is a large number of services out there that can be targeted in order to find usernames on remote system by measuring differences in responses they generate, and a number of methods to achieve it (response verification, timing analysis, etc). Knowing user lists is extremely useful for various pen-testing applications. There are some tools to automate information gathering for one protocol, but it would be good to have a reasonable framework for automating it for all protocols and services. You only tell the program what to send and where to put username, and it does the rest, testing the responses and timing and whatnot for any protocol you've chosen. WHY NOT DONE: One of those projects that would have to start with defining an abstract, powerful expect-type chat specification language. If you know what I mean. 14) Class: HANDY UTILITY Title: Evil administrator monitor. Modify SSH on your client system to by default invoke 'sh /dev/stdin' on remote interactive logins, then feed it a simple script that would compare access times on important files to detect unauthorized file or directory viewing. Since access times are difficult to change from userspace without kernel mods, remounts or tz tweaking (all rather problematic on production systems), this sounds like a good idea. Legitimate access times could be either stored on client side, or on server side, just encrypted. Of course, hardly a perfect protection, but a good way to detect privacy violations in most cases. WHY NOT DONE: I *am* the evil administrator. Conflict of interests. 15) Class: PURE EVIL Title: Porn detector / aggregator. More and more commercial products offer efficient porn detection for e-mail content filtering systems, based on heuristic analysis of regions, color tones, etc. Those systems then block, with some false positive and false negative ratios, all pictures that seem to contain nudity. Cobion does a product like that, for example. An algorithm behind such a system is a blend of fairly trivial tricks, fed through ANN or some other weighing system. It wouldn't be hard to reproduce it. It would be next to impossible to get near the claimed efficiency ratio for such products, but that does not matter. I think it would be a great idea to use the very same code not to elliminate, but rather to accumulate such pictures. Consider a web spider that browses the net and picks up such pictures for its master. An instant marketing hit. WHY NOT DONE: Insufficient pr0n library for, umm, testing. Working to solve this. 16) Class: PURE EVIL Title: Antigoogle. A crawler that specifically disregards and focuses on data listed in /robots.txt, bruteforces certain locations, decodes and analyzes known document formats (RTF, DOC, PDF, XLS, etc), detects specific keywords. There are some tools of this nature available for site pen-testing, there are spam-bots that disregard or specifically crawl /robots.txt and brute-force forum locations, and there are several specialized solutions to snatch interesting documents (say, my "revisionist" for MS Word snafus), but I'm thinking of something more generalized, a program that, day after day, would serve you with various tasty tidbits wrapped in a nice report. WHY NOT DONE: Several test designs toyed with, but nothing full-blown. Possible abuse complaints, plus some tedious work to start with. When published, would soon be hindered by anti-antigoogles and antigoogle tarpits. 17) Class: HANDY UTILITY Title: "Persistence of access" detector. Common IDSes pick up plenty of boring, automated activity, while persistent but low-profile access would likely slip under the radar. And although automated worm attacks or mass-defacement attempts are a good thing to trace - and look pretty in statistics for upper management - being aware of a clever and determined person who targets you specifically and tries new things by hand is probably of more value (he's more likely to deeply penetrate your network and stay there for a while, capturing interesting data like credit card numbers). The persistence of access from hosts and netblocks can be easily measured, and correlated with the number of communications that are non-standard (packet contents-, ordering-, count- and size-wise). In a way, this would be an anomaly detection IDS, only far more generalized, simpler, and protocol-blind, and would inform you of things that has not happened before, and seem to be done on a purpose - hence should be watched more closely. It would not require "training" on a clean network, would automatically limit the number of alerts, and probably be of some value in corporate environments. WHY NOT DONE: Have a detailed sketch and some test code ready, but everyday use accounts are on their way out. 18) Class: USELESS RESEARCH Title: Slashdot editors' sleep patterns It is quite easy to map out sleeping habits and other time management information about Slashdot editors by analyzing information on when they approve posts (date and time is included with every item). This would be some fun research, esp. if one of them turns out to be a cyborg. WHY NOT DONE: Makes me sleepy. 19) Class: PURE EVIL Title: Real-world Basilisk images JPEG processing bugs happen, but they're mostly related to decompression of "impossible" data; should there be a JPEG compression or decompression vulnerability (or, more likely, raw sensor data processing and refinement vulnerability) that could be triggered by the actual arrangement of pixel values in a valid input file, you could actually arrange a real world still life scene that 0wns the photographer. XXX: Perhaps more realistic - what about auto-0wn fax messages? Fax machines use compression (w00t), and are nowadays capable of running arbitrary code, most of the time. WHY NOT DONE: No bugs of this type. 20) Class: PURE EVIL Title: Safe lock DPA Small and medium-size electronic safe locks usually have either a back-up battery on the accessible side of the door, or at least back-up terminals to provide emergency power supply in case of trouble. It appears to be possible to perform differential power analysis to find the subtle difference between a valid and invalid key in a sequence (that'd depend on the lock software - is the comparison done on the fly, or not until all digits were read and buffered?). WHY NOT DONE: Maybe... 21) Class: COULD-BE-FUN Title: Wiki-game There is a genre of paper-based games where you start at paragraph 1, read it to see what happens, and you can take several actions; based on your choice, you should jump to paragraph X, Y, or Z. This can (and was) successfully "ported" to HTML, a language that seems to be suspiciously well-suited for that application, and allows for more intuitive navigation and some multimedia content. Now, you could use a moderated, sorta-Wiki-related user-editing model to allow people to edit these paragraphs / pages and collectively create game world. It would probably be messy, full of troll pages, etc. Still, could be fun. UPDATE: Oh, there are some "Addventure" style projects of this type; they suck. 22) Class: USELESS RESEARCH Title: Expensive camera as a crappy seismometer Use a high-end digital SLR with telephoto lens mounted on a very solid tripod in computer controlled mode to periodically take a picture of a test grid placed several meters away. Then use a trivial piece of software to measure single-pixel movements of subsequent pictures relative to previous ones. With 12-16 mpix, should be more than accurate to detect even subtle momentary and long-term movements and shakes. Mirror lock-up might be necessary. WHY NOT DONE: Yeah, sure.