Re: [Freedos-user] Boot sector not standard? [Solved]
Bart Oldeman wrote: > > On 10/27/06, Marton <[EMAIL PROTECTED]> wrote: > >> Any chances of a permanent fix or it is actually hard to implement? > > Something like this: > [...] > Just tried this and with my 6.4gig hard drive it works like a charm. I have yet to try with one bigger than 8.4 gigs though. I will post the results once done :) Many thanks Bart!!! Cheers, Marton -- View this message in context: http://www.nabble.com/Boot-sector-not-standard--tf2471283.html#a7251285 Sent from the FreeDOS - User mailing list archive at Nabble.com. - 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
Re: [Freedos-user] Boot sector not standard? [Solved]
On 10/27/06, Marton <[EMAIL PROTECTED]> wrote:
> Any chances of a permanent fix or it is actually hard to implement?
Something like this:
--- initdisk.c.old 2006-10-30 00:30:02.0 +
+++ initdisk.c 2006-10-30 00:32:31.0 +
@@ -995,7 +995,9 @@
for (num_retries = 0; num_retries < N_RETRY; num_retries++)
{
regs.d.b.l = drive | 0x80;
-if (driveParam->descflags & DF_LBA)
+LBA_to_CHS(&chs, LBA_address, driveParam);
+if ((driveParam->descflags & DF_LBA) &&
+(InitKernelConfig.ForceLBA || ExtLBAForce || chs.Cylinder > 1023))
{
dap.number_of_blocks = 1;
dap.buffer_address = buffer;
@@ -1009,7 +1011,6 @@
}
else
{ /* transfer data, using old bios functions */
- LBA_to_CHS(&chs, LBA_address, driveParam);
/* avoid overflow at end of track */
if (chs.Cylinder > 1023)
-
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
Re: [Freedos-user] Boot sector not standard? [Solved]
Hi Eric, Many, many thanks for looking at this. I am amazed of the results :) Please tell me what is the problem of my fix... I am using a 6.4gig drive for testing this and it seems to work... You mean that if I use a bigger drive (8+gig) I would be screwing it up? Any chances of a permanent fix or it is actually hard to implement? Thanks again, Marton -- View this message in context: http://www.nabble.com/Boot-sector-not-standard--tf2471283.html#a7029951 Sent from the FreeDOS - User mailing list archive at Nabble.com. - 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
Re: [Freedos-user] Boot sector not standard? [Solved]
Hello Eric, thanks for the analysis. a) so PROT is good enough to keep Mom from using the computer if Dad is out of house, but not a bit better. b) if the author has no email address, does anybody think you could buy a registered version ? But Mom probably doesn't know 'datar' either ;) I wouldn't care much Tom Friday, October 27, 2006, 12:09:02 PM, you wrote: > 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
Re: [Freedos-user] Boot sector not standard? [Solved]
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
Re: [Freedos-user] Boot sector not standard? [Solved]
OK, when I meant sector 0, I meant the first sector. If it's the case, startSector is 0 but in this case where the tool moves it to the second sector, startSector is 1, so partitionStart goes to 64 which is not right. Do you know any way around it? Is it right to not add startSector to the relative sectors to get the start of the partition? Or there are cases in which this needs to be added? Arkady V.Belousov wrote: > > Hi! > > 20-Окт-2006 06:29 [EMAIL PROTECTED] (Marton) wrote to > freedos-user@lists.sourceforge.net: > > M> If the partition is at sector 0, > > Sectors numbered starting from 1, not 0. > > - > 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 > > -- View this message in context: http://www.nabble.com/Boot-sector-not-standard--tf2471283.html#a6983195 Sent from the FreeDOS - User mailing list archive at Nabble.com. - 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
Re: [Freedos-user] Boot sector not standard? [Solved]
Hi! 20-Окт-2006 06:29 [EMAIL PROTECTED] (Marton) wrote to freedos-user@lists.sourceforge.net: M> If the partition is at sector 0, Sectors numbered starting from 1, not 0. - 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
Re: [Freedos-user] Boot sector not standard? [Solved]
But DOS 7+ is LBA, right? It works like a charm there... If the partition is at sector 0, ScanForPrimaryPartitions gets 0 as the startSector. This is in most if not all cases, right? Well if the tool moves it to sector 1 and tells FreeDOS that the partition is there, and FreeDOS recognizes the partition to be at sector 1... why do we need to add startSector to partitionStart? I don't think there's a bug in the tool because it works fine on all versions of MS-DOS. Eric Auer wrote: > > > If the tool somehow manages to make DOS aware of the moved > partition table, then still it would be the wrong fix to let > DOS shift all partitions by one sector: Actually it is a > bug in the tool then, and the tool should have subtracted > 1 from RelSect at that point. In that case, the result of > the analysis would be that your tool is totally incompatible > with operating systems which support LBA (as opposed to only > CHS) disk geometry. > -- View this message in context: http://www.nabble.com/Boot-sector-not-standard--tf2471283.html#a6916771 Sent from the FreeDOS - User mailing list archive at Nabble.com. - 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
Re: [Freedos-user] Boot sector not standard? [Solved]
> 1) The partition table is moved from sector 0 to sector 1 > 2) Some code is written to sector 0. This code asks for a password and if > you fail, you can't boot. So far so good. > I found the problem to be in initdisk.c, function ScanForPrimaryPartitions. > > What happens is that when the tool has moved the partition table to sector > 1, startSector here is 1... and this line: > >partitionStart = startSector + pEntry->RelSect; > > makes partitionStart be 64 in my case (because RelSect is 63 on this > drive)... and the real start of the partition IS at sector 63! You cannot "fix" that, because as far as I understand the purpose of the tool, the partition table will LOOK as is if it is at the NORMAL location while DOS is starting up. Otherwise, DOS would not even find the partition table, as the tool would have hidden it. If the tool somehow manages to make DOS aware of the moved partition table, then still it would be the wrong fix to let DOS shift all partitions by one sector: Actually it is a bug in the tool then, and the tool should have subtracted 1 from RelSect at that point. In that case, the result of the analysis would be that your tool is totally incompatible with operating systems which support LBA (as opposed to only CHS) disk geometry. Eric - 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
Re: [Freedos-user] Boot sector not standard? [Solved]
Well, I did some research on everything and found the cause of the problem. First, I confirmed that what the tool does is this: 1) The partition table is moved from sector 0 to sector 1 2) Some code is written to sector 0. This code asks for a password and if you fail, you can't boot. I found the problem to be in initdisk.c, function ScanForPrimaryPartitions. What happens is that when the tool has moved the partition table to sector 1, startSector here is 1... and this line: partitionStart = startSector + pEntry->RelSect; makes partitionStart be 64 in my case (because RelSect is 63 on this drive)... and the real start of the partition IS at sector 63! If I manually remove startSector from there so partitionStart is always 63, the protection from the tool is effective and it boots, and everything works well. Will this "fix" cause problems with some drives?? Is it safe to leave startSector out of that line? Thanks for any clue. -- View this message in context: http://www.nabble.com/Boot-sector-not-standard--tf2471283.html#a6909759 Sent from the FreeDOS - User mailing list archive at Nabble.com. - 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
