Why the "Fun with RA boards" hacking method is LAME! (The REAL way to hack RemoteAccess) ----------------------------------- Knocked up by ByTe RyDeR of the ���� �� � �� � ij��� FundeM�NTAL CoNNeCtiON ij��� :��� �� � �� � "Saving the Brain Forest" Well dewdz, ya seen the file text about hacking RemoteAccess and you wanna crack that H/P or warez RA board for mega ratios? Get Real! RA *CAN* be hacked but only in the same way as any other BBS sox... no sysop reading that file was shat themselves .. here's why not: Basically the technique outlined involved you writing a trojan and disguising it as some program the sysop is really gagging for in the hope is he'll run it on his system. Wot it'll really do is copy his USER.BBS onto the filebase so you can call back later and d/l it... neat idea, and one that in *theory* will work with most BBS sox (most are EVEN easier coz they don't encrypt the users file like RA) but their execution of it sucks! Firstly, their compiled batch file relied on the sysop running RA off their C: drive from the directory \RA... Yeah, maybe some lame PD board they hang out on is like that but most sysops I know run multiple drives and many have more complex directory structures... Lame Hacker 0 - Sysop 1 Okay... letz assume they got on some lame fucking board and the users file *is* C:\RA\USERS.BBS - next step is to copy the file into the filebase and make it d/lable. How do they do that? (patronising Dez Lymon voice) <g>. Their idea was to copy the file into D:\FILES\UPLOAD .. Yeah sure guyz... EVERY board uses the D: drive for the filebase and happen to have a file area in \FILES\UPLOAD - NOT!!!!!! Lame Hacker 0 - Sysop 2 Right, so they got better odds than winning the national fucking lottery and all the above worked (yeah man, we're dreamin' but let's give 'em a chance). What next? The file has to be d/lable... you found a sysop that makes UNCHECKED & UNSCANNED files available for download? Fuck off! Get a life! Lame Hacker 0 - Sysop 3 So... okay.... we got a sysop that's so fucking lame he doesn't deserve to to breath the same air as the rest of the human race and uses all the above paths and makes unchecked uploads d/lable. RA by default won't allow files to be d/led UNLESS they're in the file database. Unless the USERS.BBS destination ALREADY EXISTED in that area and was previously in the area database there's NO WAY you can d/l it. The way they "solved" this was to add an entry to FILES.BBS in the file directory. Nice one... EXCEPT RA DOESN'T USE FILES.BBS AS IT'S FILE DATABASE. Unless you happen to be lucky enough that the sysop does an import from FILES.BBS to the REAL file database before checking out your planted file (most RA sysops only import from FILES.BBS when adding CDROMs) the addition of this entry will do FUCK ALL! Lame Hacker 0 - Sysop 4 To quote from the author "This is a generic program and you will have to tailor it so it will meet your needs." - yeah man, fucking rethink, redesign and rewrite it more like! Oh yeah... EVEN IF YOU DO get a copy of the USER.BBS file downloaded THE PASSWORDS ARE ENCRYPTED!!! Lame Hacker :( - Sysop:-) So how can U hack RA? Well, the idea was okay but, like hacking any system, you gotta KNOW the system ya gonna hack b4 U stand a chance. Most sysops will use the DOS environment variable RA set to the RA system directory so that external doors can find the system files... that's very helpful of the sysop, to show us where we can find his config files. <g> In the RA system directory should be the file CONFIG.RA. You might want to include a check for this file within your program and possibly do a disk and directory scan for the file if RA isn't defined or is set incorrectly. I'm not *entirely* sure about other versions of RA, but in the current release (2.02) the CONFIG.RA offset &h3E4 is where the name of the mail directory starts. This is the path where USERS.BBS will be found. Next you need to know for SURE the name of a directory which stores the files for a filearea from which you are able to download. I suggest you do this in one of three ways: 1) Interogate the file FILES.RA in the RA system directory which contains the filebase area configs. You *could* just search the directory for a valid path but you'd wouldn't know if you had d/l access to the area. 2) If you want to be a bit more clever you could interpret the file and find out the minimum security level required to d/l from each area and dump your copy of USERS.BBS in the area with the lowest access level, pretty much guaranteeing that you'll be able to get to the file. This doesn't take security flags into account so there's still a SLIM possiblity you won't be able to d/l the file unless you also write flag testing into your program. 3) My favourite technique is to have the program read a small config file which is uploaded with your archive. This file just contains the name of a file you KNOW you have d/l access from. You can then either do a global search for that filename or, preferably (coz it's faster) read FILES.RA for the paths used by the filebase and search those. So now you have the location of the USERS.BBS and the destination directory you simply need to copy the file. However, even though the file is sitting in a filebase directory it STILL isn't available for d/l... why? Because it's not in the filearea database. You could get clever and find amend filearea database files directly if you get the fileareas path from CONFIG.RA (offset &hC12) and write to the files HDR\FBD#####.HDR (header) IDX\FDB#####.IDX (index) and, if you want to add a description, TXT\FBD#####.TXT, where ##### is the RA file area number. There *is* an easier way. Shell out to DOS and execute the RAFILE utility from the RA program path, passing the arguments "ADOPT filename #####". E.g. the BASIC command would be: SHELL "RAFILE ADOPT "+filename$+STR$(areanum) Where filename$ contains the name of your USERS.BBS copy and areanum is the RA filearea number. If your filename was USERTEST.ZIP and you'd copied it to the directory used for RA file area 10 you'd be executing: RAFILE ADOPT USERTEST.ZIP 10 This will "adopt" the file, adding it to the RA file database, making it available for d/l (assuming you have the appropriate rights to the area). All you need to do now is to package this trojan file to entice the sysop into running it... In the LAME method for hacking RA the author used DSZ as an example. That was about the most realistic part of the file and the only bit worth leaching! <g> Your archive: DSZ.EXE (your program) DSZ.DAT (the *real* DSZ.EXE) DSZ.CFG (small file containing the name of a *known* d/lable file - preferabbly encrypted) + any other files that normally come with DSZ Flow diagram for DSZ.EXE trojan: _______ / \ | Start | \_______/ | | +--------+--------+ | Read enviroment | | variable RA | +--------+--------+ | | / \ / \ /CONFIG.RA\ +---------------------+ / exist in \___>____| Scan drives & paths | \ that path / No | search for the file | \ ? / +----------+----------+ \ / | \ / | Yes | | +------------<-------------+ | +--------+--------+ | Read CONFIG.RA | | to get location | | of USERS.BBS | +--------+--------+ | | +--------+--------+ | Read DSZ.CFG to | | get a filename | +--------+--------+ |_____________<____________ | | +--------+--------+ | | Read FILES.RA to| | | get name of the | | | next filearea | | +--------+--------+ | | | | | / \ | / \ | /does area\ | / contain the \________>__________| \ file / No \ ? / \ / \ / Yes | ...
sentinell