Hi Marton, I checked your PROT program (1995, shareware, 30 bucks for the full version, demo version has fixed key "datar") from sunsite.rediris.es/pub/msdos/security/protdrx.zip a bit...
The binary installer is 16 kilobytes, DIET compressed, easy to decompress with UNP. See the bottom of this mail for the conclusion - avoiding LBA for the MBR and/or first 1024 cyls (which might break other things) would make FreeDOS more com- patible with PROT and other ancient menu and malware software. > PROT will keep all but the most serious hackers out of your data. Sounds like an invitation... > PROT uses special "stealth" technology which does NOT > require any RAM or disk space. Which, as expected turned out to be not true at all: PROT allocates 1 kilobyte of RAM the 40:13 way. Tools like the Ontrack LBA driver for people ancient BIOSes do the same, as does a lot of DOS malware. So DOS will tell you that you have less than 640k of "total" RAM. Modern BIOSes also allocate such memory, but for other purposes. PROT writes the original MBR to CHS 0/0/2 and writes itself to CHS 0/0/1 where the MBR was. So it does take disk space and is incompatible with several boot menu systems, at least unless you configure them to reside outside the MBR area. > Modes - 1/3/5 ALWAYS block diskette boot, 0..3 ask for a key: > 0 - allow diskette boot but hide harddisk if wrong key > 1 - freeze if wrong key > 2 - block only diskette (but maybe allow boot from diskette??) > 3 - same but cannot boot from diskette (or harddisk?) either (?) > 4 - always block diskette but allow boot from diskette (??) > 5 - always block diskette > Install: run "PROT P number", uninstall: PROT U, zap 0/0/2: PROT C > Always start with mode 0 to check compat, never 1/3/5... > Mode 1 (others as well?) needs to find the operating system (why?) > PROT does not encrypt your hard disk. It is possible that > someone somewhere with an extremely deep knowledge of DOS might > be able to hack PROT... Very funny. My extremely deep knowledge and experience already told me that the original MBR is at 0/0/2, just from reading the PROT manual. The super stealth thing simply redirects CHS read/write access to 0/0/1 to 0/0/2 while PROT is active. The access in CHS-ECC/CRC mode and in LBA mode is not trapped and access to 0/0/2 is not trapped either. In addition, the PROT tool can disable PROT on the fly, by calling int 13.fe which toggles the MBR trick thing. If you look at the PROT MBR then you see that the key (always 5 letters) is stored in plain text at offset 4 of the PROT MBR. The PROT MBR contains a nonsense partition table, which is why you cannot normally access the harddisk while PROT is not active and happy in RAM. > PROT uses obscure DOS sub-routines which might not be available... > We have not had any problems on standard IBM compatible clones > running Microsoft, IBM or Novell DOSes from version 3.0 to 6.3. Actually I did not find out which obscure routines are used... But I loaded FDSHIELD (with right options) to protect my real MBR and then ran PROT P 0 with int call logging enabled (in DOSEMU), which readily gave away the self-deactivation trick via int 13.fe. PROT just tests if toggling int 13.fe modifies accessibility of the MBR, then reads the 0/0/1 and 0/0/2 sectors, edits them, writes them, shows a message because FDSHIELD stopped it. But at that point I had already grabbed the modified MBR in dosdebug of DOSEMU :-p. It is somehow unlikely that FreeDOS called int 13.fe and confused PROT that way. The normal style is that PROT asks for the key at boot and then either loads the real MBR and hides itself or halts the system. My guess is that PROT fails on FreeDOS because PROT does not hide itself from LBA access. Arguably, FreeDOS could read the MBR (and other partition sectors inside the first 1024 cylinders) in CHS style and only switch to LBA when it accesses the area beyond the first 8 GB. That would make it more compatible with some malware, badly written boot menu systems, and with PROT. Maybe you can use some SYS CONFIG options (which edit a kernel sys file) to tell the kernel to disprefer LBA and try if that makes the kernel happier with PROT. Opinions about that suggestion please :-). Eric PS: PROT uses a cute way to hook int 13 and it overwrites diskette int 40 because it uses it as a "trampoline vector": > 7c6f mov sp,0x4c ; ss, cs and ds are 0 at that time > 7c72 cld > 7c73 pop word [0x7cdc] ; save the old int 13 vector > 7c77 pop word [0x7cde] ; ... same ... > ... grab 40:13 memory, copy self there (very un-stealth) ... > 7c99 push ax ; ax is the new segment value > 7c9a push bx > 7c9b mov sp,0x100 > 7c9e mov bx,0x7ca4 > 7ca1 push ax ; overwrites int 40 vector > 7ca2 push bx ; ... same ... > 7ca3 retf ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
