good or bad ideas for use in bootloader?
Rod Pemberton
In your opinion, are these good or bad ideas for use in bootloader or
bootsector?
(many unposted ideas, but also recycling some ideas I've posted lately...)
0) use DL value passed by Int 19h?
1) reset segment registers or use BIOS values?
2) set CS segment register to zero via jmp?
3) load new stack ss:sp via lss or paired movs?
4) disable interrupts to ensure control?
5) disable NMI (non-maskable interrupts) to prevent hardware interruptions
of bootloader?
6) if/when interrupts are enabled, disable hardware interrupts via PIC?
7) if/when interrupts are enabled, disable keyboard to block user
interruptions?
8) if/when interrupts are enabled, disable mouse to block user
interruptions?
9) using BIOS functions (e.g., Int 15h OS functions), are they safe?
10) not using BIOS functions, for safety?
11) changing IVT (interrupt vector table) to ensure control? (e.g., Int
13h/18h/19h)
12) lock IVT by relocating with lidt to ensure control?
13) disable A20 to prevent use of half of memory - until it's needed?
14) enable A20 to load OS into memory? Or, let OS do it after loading?
15) DOS compatible bootsectors (BPB, jump short, PS/2 OEM name, 0xAA55)
16) changing PIC settings from BIOS values?
17) setting CMOS values, e.g., 0Fh shutdown byte to control reboot?
18) compatibility with broken Int 19h BIOSes that jump to cs:ip 7c0:0h?
19) clear first 64k of memory (clear out virus?)
20) clear memory below 512K, 640K, 1MB, or 1MB+64k (clear out virus?)
21) clear memory with NOP instruction to try to prevent execution of bad
code?
22) clear memory using Int 03h (0xCC) instruction to trap run-away code?
23) setting a pre-boot text mode to help init of video card registers?
(e.g., 80x25)
24) clearing non-reserved bits in CR3, CR4, CR0?
25) disable caching CD=1, NW=0 prior to enabling CR0 PM?
26) using a 24-bit or 32-bit lidt address?
27) storing boot and OS control data in bootsector? e.g., boot device,
video mode, memory ranges, clean BIOS IVT table, etc.
Rod Pemberton
Alexei A. Frounze
> In your opinion, are these good or bad ideas for use in bootloader or
> bootsector?
> (many unposted ideas, but also recycling some ideas I've posted lately...)
>
> 0) use DL value passed by Int 19h?
I do. Not sure if it's not universally supported.
> 1) reset segment registers or use BIOS values?
Depends on what you're doing and if you care.
> 2) set CS segment register to zero via jmp?
Or RETF.
> 3) load new stack ss:sp via lss or paired movs?
LSS needs a memory operand. Therefore MOV SS followed by MOV (E)SP.
> 4) disable interrupts to ensure control?
Again, depends on what you're doing. PMode? Code profiling?
Synchronization primitives?
> 5) disable NMI (non-maskable interrupts) to prevent hardware interruptions
> of bootloader?
Haven't really cared about these, although I remember reading
somewhere that NMIs could come in (or after switching to) PMode. Not
sure of the details. This was written in the 286-486 era.
I'm not sure there's much value in NMIs -- one shouldn't seeing them
when everything's OK. I actually wonder if NMIs weren't completely
replaced by SMIs and #MCs.
> 6) if/when interrupts are enabled, disable hardware interrupts via PIC?
Why?
> 7) if/when interrupts are enabled, disable keyboard to block user
> interruptions?
Ah, that's why. I can still ask why. Unless the keyboard is broken or
the user keeps pressing/pressed some of the keys and therefore may
affect the behavior of the code in unwanted ways, I wouldn't worry.
> 8) if/when interrupts are enabled, disable mouse to block user
> interruptions?
Aren't those disabled by default?
> 9) using BIOS functions (e.g., Int 15h OS functions), are they safe?
I only use 0xE820 and the like and 0x87. So far they normally work.
> 10) not using BIOS functions, for safety?
With all kinds of non-standard and varying hardware, I'd say using
BIOS is safer.
> 11) changing IVT (interrupt vector table) to ensure control? (e.g., Int
> 13h/18h/19h)
Very rarely necessary.
> 12) lock IVT by relocating with lidt to ensure control?
Same thing. If you want to reverse engineer or control the BIOS code
you might be better off with v86 mode. It's generally more transparent
and will let you know of certain events (interrupts, port accesses,
etc).
> 13) disable A20 to prevent use of half of memory - until it's needed?
If you know what it is, you can do whatever you want with it.
> 14) enable A20 to load OS into memory? Or, let OS do it after loading?
Depends on the OS size and memory mapping.
> 15) DOS compatible bootsectors (BPB, jump short, PS/2 OEM name, 0xAA55)
I prefer it that way so I don't need any special tools to update the
code/data in the boot image.
> 16) changing PIC settings from BIOS values?
To ensure you don't get any unwanted ints you shouldn't depend on
those.
> 17) setting CMOS values, e.g., 0Fh shutdown byte to control reboot?
Was useful on the 286 which could switch to real mode from protected
only upon reset.
> 18) compatibility with broken Int 19h BIOSes that jump to cs:ip 7c0:0h?
I have this, but it's kind of automatic - I just execute the far jmp/
ret as one of the first instructions and I get whatever I want 7c0:0
or 0:7c0.
> 19) clear first 64k of memory (clear out virus?)
The likelihood of a virus surviving a custom OS boot is probably zero.
Other than that, how do you know where it is and if it's there? How
can you know that that early w/o running fairly complicated analysis
code and virus database?
> 20) clear memory below 512K, 640K, 1MB, or 1MB+64k (clear out virus?)
Don't care until it comes to allocation of user app pages, at which
point they should be zeroed. In the kernel it may only help debugging,
but shouldn't be a big security concern, unless 3rd party drivers are
loaded into the kernel portion of the address space and even then if
something evil is in the kernel it's a bit late.
> 21) clear memory with NOP instruction to try to prevent execution of bad
> code?
> 22) clear memory using Int 03h (0xCC) instruction to trap run-away code?
Yeah, probably.
> 23) setting a pre-boot text mode to help init of video card registers?
> (e.g., 80x25)
IMO, it should already be set up. OTOH, it won't hurt setting it up
either.
> 24) clearing non-reserved bits in CR3, CR4, CR0?
Depends on how well you know this stuff and what you're doing.
> 25) disable caching CD=1, NW=0 prior to enabling CR0 PM?
Caching's good. Normally. AFAIR, Intel doesn't flush the caches when
switching to/from SMM and because of the performance implications. But
not very well though out things like this sometimes return and bite.
> 26) using a 24-bit or 32-bit lidt address?
Um... The code should be CPU/mode-independent, so with 32-bit address
size and properly initialized address always.
> 27) storing boot and OS control data in bootsector? e.g., boot device,
> video mode, memory ranges, clean BIOS IVT table, etc.
You may want to have such an option in case something doesn't work
well with certain settings due to a bug in the hardware or BIOS. The
rest is unnecessary, IMHO, but if you want, you can have the video
mode and boot pic stored there - no prob. :)
Alex
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:hg1cj7$boa$1...@aioe.org...
>
> In your opinion, are these good or bad ideas for use in bootloader or
> bootsector?
> (many unposted ideas, but also recycling some ideas I've posted
> lately...)
>
> 0) use DL value passed by Int 19h?
drive you are on is to use the DL value, right?
> 1) reset segment registers or use BIOS values?
I set the DS and ES values.
> 2) set CS segment register to zero via jmp?
I don't touch or even worry about the CS:IP pair. As long as they
combined point to 0x07C00 and I don't use the CS: override, it doesn't
matter what the two values are.
> 3) load new stack ss:sp via lss or paired movs?
Paired mov's.
> 4) disable interrupts to ensure control?
I do, but it isn't necassary.
> 5) disable NMI (non-maskable interrupts) to prevent hardware interruptions
> of bootloader?
Nope.
> 6) if/when interrupts are enabled, disable hardware interrupts via PIC?
Nope.
> 7) if/when interrupts are enabled, disable keyboard to block user
> interruptions?
Nope.
> 8) if/when interrupts are enabled, disable mouse to block user
> interruptions?
Nope.
> 9) using BIOS functions (e.g., Int 15h OS functions), are they safe?
Sure. Most common interrupt services are always used.
> 10) not using BIOS functions, for safety?
You can't get a disk IO driver *and* do all the necassary work
in 512 bytes. You must load at least one more sector with the BIOS.
Besides, a well written BIOS will read from most any media it is
designed for with a simple call to service (42h)02h/Int 13h, no matter
the type of media. Imagine the code you would have to write to
handle all the media types.
> 11) changing IVT (interrupt vector table) to ensure control? (e.g., Int
> 13h/18h/19h)
Not in my boot code.
> 12) lock IVT by relocating with lidt to ensure control?
Nope.
> 13) disable A20 to prevent use of half of memory - until it's needed?
No, and why?
> 14) enable A20 to load OS into memory? Or, let OS do it after loading?
I do it within a loader, not the boot sector.
> 15) DOS compatible bootsectors (BPB, jump short, PS/2 OEM name, 0xAA55)
All different kinds. If the drive has a MBR, it only has to conform to
the BIOS specifications of the AA55 signature and (maybe?) the jmp
instruction at offset 0. Once your MBR loads the partition boot sector,
you know longer are confined to these restrictions, especially if it
is your MBR. Though some MBR code check for the AA55 sig on the partition
sector too.
> 16) changing PIC settings from BIOS values?
Nope.
> 17) setting CMOS values, e.g., 0Fh shutdown byte to control reboot?
Nope. The BIOS should do this for you.
> 18) compatibility with broken Int 19h BIOSes that jump to cs:ip 7c0:0h?
Why would that be a broken BIOS? Again, as long as you don't use
the CS: override, it doesn't matter what the cs:ip combination is, as
long as they, combined, point to 0x07C00.
A CS:IP value of 07B0:0100h would work just fine, wouldn't it?
> 19) clear first 64k of memory (clear out virus?)
> 20) clear memory below 512K, 640K, 1MB, or 1MB+64k (clear out virus?)No.
> Any real virii would already be in pmode in upper memory.
> 21) clear memory with NOP instruction to try to prevent execution of bad
> code?
:-) Learn to program to prevent execution bad code :-)
> 22) clear memory using Int 03h (0xCC) instruction to trap run-away code?
> 23) setting a pre-boot text mode to help init of video card registers?
> (e.g., 80x25)
Good old mode 03h. INT 10h/AH=0/AL=3 Nothing more.
> 24) clearing non-reserved bits in CR3, CR4, CR0?
Nope.
> 25) disable caching CD=1, NW=0 prior to enabling CR0 PM?
Nope.
> 26) using a 24-bit or 32-bit lidt address?
> 27) storing boot and OS control data in bootsector? e.g., boot device,
> video mode, memory ranges, clean BIOS IVT table, etc.
I store it in low memory until my loader moves to pmode, then it copies it
to upper memory just before it jumps to the kernel.
Again, my idea of a boot sector (partition or otherwise) is to only
load a loader. Nothing more. It needs to make sure that the machine is
in a known state, find the loader file on the partition's filesystem,
load it to a fixed/given location and jump to it. Nothing more.
Let the loader do all the work. It isn't restricted to location or
size and can be written in a higher level language if so desired.
Just my opinion. Thanks Rod.
Ben
Rod Pemberton
news:796bfcaa-f55b-4a0c...@r24g2000yqd.googlegroups.com...
On Dec 12, 4:29 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> In your opinion, are these good or bad ideas for use in bootloader or
> bootsector?
> (many unposted ideas, but also recycling some ideas I've posted lately...)
>
> > 0) use DL value passed by Int 19h?
>
> I do. Not sure if it's not universally supported.
That's what I recall reading somewhere. That DL doesn't always pass a
value. But, as Ben pointed out - how does one know what device to load
from? I just posted about Int 15h, DX=D600h - which might return the value.
Otherwise, I guess I'd have to search the BDA or other interrupt calls...
> > 4) disable interrupts to ensure control?
>
> Again, depends on what you're doing. PMode? Code profiling?
> Synchronization primitives?
Preventing undesirable memory resident code from gaining execution? ...
> > 5) disable NMI (non-maskable interrupts) to prevent hardware
> > interruptions of bootloader?
>
> Haven't really cared about these, although I remember reading
> somewhere that NMIs could come in (or after switching to) PMode. Not
> sure of the details. This was written in the 286-486 era.
> I'm not sure there's much value in NMIs -- one shouldn't seeing them
> when everything's OK. I actually wonder if NMIs weren't completely
> replaced by SMIs and #MCs.
>
I was more worried about a hardware device causing an NMI and there not
being an EOI, or perhaps register corruption, perhaps due to a poorly
written BIOS - RBIL documents a few of these, which could possibly interfere
with the bootsector or loader.
> > 19) clear first 64k of memory (clear out virus?)
>
> The likelihood of a virus surviving a custom OS boot is probably zero.
Maybe... I did some experiments with one version of DOS. I'm pretty sure
it cleared all memory it found. I couldn't keep my code resident, and I
tried.
> Other than that, how do you know where it is and if it's there? How
> can you know that that early w/o running fairly complicated analysis
> code and virus database?
Can't. But, I was thinking that by combining a few of the things on the
list, I could perhaps ensure total control by my code. And, therefore,
block out many of the more likely scenarios.
> > 20) clear memory below 512K, 640K, 1MB, or 1MB+64k (clear out virus?)
>
> Don't care until it comes to allocation of user app pages, at which
> point they should be zeroed.
What about if the page is freed and reallocated? Do you zero again? ...
> > 22) clear memory using Int 03h (0xCC) instruction to trap run-away code?
>
> Yeah, probably.
I like the idea. It may be more useful for debugging though. If memory is
cleared using 0xCC and Int 03h is called in a bootloader, one must assume a
virus. What can you do but attempt a clean reboot?
> > 23) setting a pre-boot text mode to help init of video card registers?
> > (e.g., 80x25)
>
> IMO, it should already be set up. OTOH, it won't hurt setting it up
> either.
>
Well, I wrote my own text mode video routine for my OS, but I noticed that
the video BIOS was setting some additional registers - which seem to be
undocumented. However, a simple BIOS call seems to set these. Maybe I just
need to find some better documenation...
Rod Pemberton
Rod Pemberton
news:Nm_Um.3241$Z%1.1...@newsfe02.iad...
> "Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
> news:hg1cj7$boa$1...@aioe.org...
> >
>
> I don't quite know what you mean. The only way to know what
> drive you are on is to use the DL value, right?
>
I haven't completed my bootloaders. So, I hadn't really thought about it.
I guess I do need to know which device to load from next...
There is Int 15h, DX=D600h. It may return the boot device - at least
according what I posted on Int 19h from the PS/2 manuals in the other
thread.
> > 5) disable NMI (non-maskable interrupts) to prevent hardware
interruptions
> > of bootloader?
>
> Nope.
No? What about a hardware device causing an NMI and there not being an EOI
or register corruption which could possibly interfere with the bootsector or
loader?
> > 13) disable A20 to prevent use of half of memory - until it's needed?
> No, and why?
I was thinking about a memory lockout or disable, e.g., to prevent unwanted
code execution. Unfortunately, A20 is only half a solution. Once in 32-bit
PM, you can use memory management privileges of segments.
> > 17) setting CMOS values, e.g., 0Fh shutdown byte to control reboot?
> Nope. The BIOS should do this for you.
Isn't a 286 style reset still supported by BIOSes? I.e., if someone changed
the CMOS 0Fh shutdown byte to 0x0A, they could bypass a cold or warm reboot
and execute their own code. Yes?
Rod Pemberton
wolfgang kern
Rod Pemberton polled:
> In your opinion, are these good or bad ideas for use in bootloader or
> bootsector?
> (many unposted ideas, but also recycling some ideas I've posted
> lately...)
> 0) use DL value passed by Int 19h?
yes, even I run a more detailed hw-check lateron to install proper drivers.
> 1) reset segment registers or use BIOS values?
I start with: SS=CS=0, ES=DS=8000h to avoid overlapping with stack,
IDT and BIOS-data and allow a full 64KB load.
> 2) set CS segment register to zero via jmp?
only required if CS-override are used
> 3) load new stack ss:sp via lss or paired movs?
mov ss,.. |mov sp,..
> 4) disable interrupts to ensure control?
Not in the bootload, but during IRQ-/HW-setup by the OS.
> 5) disable NMI (non-maskable interrupts) to prevent hardware interruptions
> of bootloader?
No. NMI on mobiles often indicate low battery,
desktops may use it for fatal-HW error (RAM/ROM/...).
> 6) if/when interrupts are enabled, disable hardware interrupts via PIC?
Not required, the BIOS enables only what it needs beside PIT and KEYBD.
> 7) if/when interrupts are enabled, disable keyboard to block user
> interruptions?
No! give to poor user a chance to reboot if he'd chosen the wrong :)
> 8) if/when interrupts are enabled, disable mouse to block user
> interruptions?
Is disabled anyway.
> 9) using BIOS functions (e.g., Int 15h OS functions), are they safe?
Hopefully safe, I have no idea how it could start without INT10,13,15h
while the OS still isn't up and running.
> 10) not using BIOS functions, for safety?
perhaps more a speed concern rather than security,
so not an issue during boot.
> 11) changing IVT (interrupt vector table) to ensure control?
> (e.g., Int 13h/18h/19h)
> 12) lock IVT by relocating with lidt to ensure control?
Not during the bootload.
> 13) disable A20 to prevent use of half of memory - until it's needed?
> 14) enable A20 to load OS into memory? Or, let OS do it after loading?
I enable it already in the bootloader, even the OS-loader does it again.
> 15) DOS compatible bootsectors (BPB, jump short, PS/2 OEM name, 0xAA55)
depends on your desire. I don't want/need to have it M$-compatible.
> 16) changing PIC settings from BIOS values?
why now ? this is done in the OS-startup.
> 17) setting CMOS values, e.g., 0Fh shutdown byte to control reboot?
except for RTCL rd/wr, I never used nor touched the CMOS-RAM.
> 18) compatibility with broken Int 19h BIOSes that jump to cs:ip 7c0:0h?
yes, if your code assumes CS=0
> 19) clear first 64k of memory (clear out virus?)
the real mode IDT and BIOS-data reside there...
what's a virus? 'never execute unknown code !' :)
Also a softboot let the BIOS restore its IDT, so RAM-resident virii
which usually act as INT/IRQ-hooks wont survive a reboot.
> 20) clear memory below 512K, 640K, 1MB, or 1MB+64k (clear out virus?)
Not required, even a clean area may look nice.
But be aware not to clear 'ROM', BIOS(E000..EFFF) and VBIOS(C800..CFFF)
are writeable shadows on my machine.
Later in the game mem_alloc can clear if desired anyway.
> 21) clear memory with NOP instruction to try to prevent execution of bad
> code?
> 22) clear memory using Int 03h (0xCC) instruction to trap run-away code?
I use both above only during debug sessions to embed code under test.
> 23) setting a pre-boot text mode to help init of video card registers?
> (e.g., 80x25)
Isn't this is a BIOS-default anyway? but it wont hurt after warm boot.
> 24) clearing non-reserved bits in CR3, CR4, CR0?
> 25) disable caching CD=1, NW=0 prior to enabling CR0 PM?
No, these bits have no meaning while in RM and I set 'em
as required during the transition to PM in the OS startup.
Sure the OS-loader must enter PM32, but:
Shall a (multi-OS capabile) bootloader already switch to PM ?
I think no, every OS may need its own setup here.
> 26) using a 24-bit or 32-bit lidt address?
not much a gain with 24 bit :)
> 27) storing boot and OS control data in bootsector? e.g., boot device,
> video mode, memory ranges, clean BIOS IVT table, etc.
I only store OS-master_config_bits in the bootsector, somehow similar
to CPUID to tell which modules are present in the current installation,
all other are stored in their dedicated disk locations as part of the OS
or as private configuration in the user-preferences.
__
wolfgang
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
> "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
>> > 17) setting CMOS values, e.g., 0Fh shutdown byte to control reboot?
>> Nope. The BIOS should do this for you.
>
> Isn't a 286 style reset still supported by BIOSes? I.e., if someone
> changed
> the CMOS 0Fh shutdown byte to 0x0A, they could bypass a cold or warm
> reboot
> and execute their own code. Yes?
But then we come back to the "already too late" issue. If other
software has already taken control while in your boot sector,
to be able to modify something that you don't intend to, isn't
it already too late?
The theory is, you have full control of the machine at boot time.
Why wouldn't you have full control?
Ben
Alexei A. Frounze
wrote:
> "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
In theory, one could boot something that would virtualize things and
from there continue to boot the unsuspecting OS. In practice, I'd
expect this to be pretty hard to do as one would need to hack that OS
or have physical access to the PC in the first place and the
virtualizing software would be pretty complex. Imagine having to
emulate everything, say, Windows needs or getting underneath it in a
stealth hypervisor and doing that invisibly. Doing this completely
invisible is perhaps the hardest part because you inevitably screw up
timing of various operations/instructions by virtualizing. Even if you
do it invisibly for the software, the user will see a huge performance
hit and immediately start wondering as to what the hell is wrong with
the system.
Alex
Benjamin David Lunt
Alex
<<<<<<
Yep. Hence the "already too late" comment :-). If this has
already taken place, then why worry about disabling the A20
line, or CMOS 0Fh, or whatever. The virtualizing host wouldn't
let you anyway. :-)
Ben
James Harris
> In your opinion, are these good or bad ideas for use in bootloader or
> bootsector?
> (many unposted ideas, but also recycling some ideas I've posted lately...)
All comments below are from a personal point of view. Others may have
already provided better answers. No insult meant to them.
> 0) use DL value passed by Int 19h?
You mean DL passed-in on boot? I don't know any other way to id the
boot partition.
> 1) reset segment registers or use BIOS values?
> 2) set CS segment register to zero via jmp?
I don't think there's a need to change CS until switching to Pmode.
There may be cases I'm not aware of, though.
> 3) load new stack ss:sp via lss or paired movs?
Before answering this I'd add one to your list:
2a) Check running on a 386 or above
Given that a valid stack is needed early on (before the CPU has been
identified) I set one up with paired movs (mov ss first as you know
because it inhibits interrupts for one instruction).
> 4) disable interrupts to ensure control?
Yes, where appropriate.
> 5) disable NMI (non-maskable interrupts) to prevent hardware interruptions
> of bootloader?
Yes, when switching to the Pmode IDT. I cannot think of another
occasion when this needs to be disabled.
> 6) if/when interrupts are enabled, disable hardware interrupts via PIC?
I think most interrupts can be fired on the bare PC without causing
trouble. In fact those from the boot device might be needed to allow
reads of the device.
> 7) if/when interrupts are enabled, disable keyboard to block user
> interruptions?
Need to allow the user to hit control-alt-delete if he/she wants to
prevent the OS boot.
> 8) if/when interrupts are enabled, disable mouse to block user
> interruptions?
I think (hope) the mouse can be ignored until the shell is running.
> 9) using BIOS functions (e.g., Int 15h OS functions), are they safe?
> 10) not using BIOS functions, for safety?
For both questions: not many BIOS functions are needed. I'd use the
few which are until and unless info came to light saying individual
ones are faulty on certain BIOSes.
> 11) changing IVT (interrupt vector table) to ensure control? (e.g., Int
> 13h/18h/19h)
> 12) lock IVT by relocating with lidt to ensure control?
For all these, I'd keep the original real-mode IDT for the short time
until it is superseded by the PM IDT.
> 13) disable A20 to prevent use of half of memory - until it's needed?
> 14) enable A20 to load OS into memory? Or, let OS do it after loading?
I've read that on some machines A20 is slow to enable. I've no idea
where the slowness manifests itself but as a precaution I set it early
and check it and, if necessary, wait for it later.
> 15) DOS compatible bootsectors (BPB, jump short, PS/2 OEM name, 0xAA55)
I use all of these for compatibility so that other operating systems
recognise the media.
> 16) changing PIC settings from BIOS values?
Sure. Start from a known position.
> 17) setting CMOS values, e.g., 0Fh shutdown byte to control reboot?
Not sure. I haven't looked at this.
> 18) compatibility with broken Int 19h BIOSes that jump to cs:ip 7c0:0h?
Since this is a known problem it may be better to code for either
case.
> 19) clear first 64k of memory (clear out virus?)
> 20) clear memory below 512K, 640K, 1MB, or 1MB+64k (clear out virus?)
For the above two, I cannot see a need. Once we take over interrupts
and then device drivers what's in memory should be irrelevant. This
still doesn't prevent someone editing our loader or OS code to add a
trojan. Perhaps the kernel should perform a couple of integrity checks
of itself once running as that's harder for a hacker to code for -
though not impossible.
> 21) clear memory with NOP instruction to try to prevent execution of bad
> code?
> 22) clear memory using Int 03h (0xCC) instruction to trap run-away code?
Neither of these seem important. Better to use the paging system to
prevent all access to unused pages and to clear those pages which are
allocated before allocation.
> 23) setting a pre-boot text mode to help init of video card registers?
> (e.g., 80x25)
Because this clears the screen(?) and it's annoying when successive
boot procedures (such as extra boot roms) clear the screen I try to
capture anything on the screen before I start writing to it. Then I
just use the teletype output.
> 24) clearing non-reserved bits in CR3, CR4, CR0?
Don't know. I haven't considered or looked at this.
> 25) disable caching CD=1, NW=0 prior to enabling CR0 PM?
Similar but I cannot see a need to do this one.
> 26) using a 24-bit or 32-bit lidt address?
32-bit. Keep it simple/compatible.
> 27) storing boot and OS control data in bootsector? e.g., boot device,
> video mode, memory ranges, clean BIOS IVT table, etc.
* Boot device - ought to be in DL on boot.
* Video mode - best to leave this as something which should work until
loading clever video driver which knows all :-)
* Memory ranges - I get from int 0x15 0xe820 falling back to older
methods as needed.
On the clean BIOS IVT - I don't think we can know what this should be
can we?
You raise some interesting points on security. Perhaps once the OS
kernel and disk drivers have been read in we should disable interrupts
and carry out various integrity checks while transitioning to Pmode.
In general I can't see a way to prevent all hacks, though. At the end
of the day someone could modify our code (especially if it is open
source) and provide the same look and feel while adding malicious
code. But we can make this harder.
Some things to contribute to your list, if in scope:
* Check we are on a 386 or greater (as mentioned above)
* Be informative about what is happening at every stage of booting
* Retain all output in a log. I even try to keep what was on the
screen before my code starts. The log must be in memory initially
until disk drivers are up and working.
* Start the clock early and timestamp all log entries.
* Place origin codes on all log entries so it's clear which program
they come from.
* Place deadbeef-type code or dummy return addresses at top of real
mode stack so stack underflow can be detected.
* Start multitasking before detecting devices so the devices can be
detected concurrently (for performance).
* Consider changing MTRRs. At the least write the BIOS-set values to
the system bootup log.
* Enable full memory caching. Easy to forget to do. Since our OSes
will be so much faster than the popular ones we may think caching is
enabled. :-)
James
James Harris
...
> > > 17) setting CMOS values, e.g., 0Fh shutdown byte to control reboot?
> > Nope. The BIOS should do this for you.
>
> Isn't a 286 style reset still supported by BIOSes? I.e., if someone changed
> the CMOS 0Fh shutdown byte to 0x0A, they could bypass a cold or warm reboot
> and execute their own code. Yes?
This looks possible. Perhaps we should explicitly set this byte on
bootup and also on shutdown if there's any possibility it could have
been changed.
James
Alexei A. Frounze
wrote:
> On 13 Dec, 00:29, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > 0) use DL value passed by Int 19h?
>
> You mean DL passed-in on boot? I don't know any other way to id the
> boot partition.
If it's your OS, you could write unique IDs into the bootsectors of
your OS and scan the disks/partitions at boot time to see where the
currently executing code came from. That's the same idea behind the
detection of the floppy change, especially on older drives which
couldn't even tell if the drive door was opened or not since the last
I/O operation.
Alex
Alexei A. Frounze
> "Alexei A. Frounze" <alexfrun...@gmail.com> wrote in messagenews:796bfcaa-f55b-4a0c...@r24g2000yqd.googlegroups.com...
> On Dec 12, 4:29 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> > > 20) clear memory below 512K, 640K, 1MB, or 1MB+64k (clear out virus?)
>
> > Don't care until it comes to allocation of user app pages, at which
> > point they should be zeroed.
>
> What about if the page is freed and reallocated? Do you zero again? ...
Well, if you don't care about leaking sensitive information, don't
scrub them. :) If you do, zero them every time. AFAIR, the NT zeroes
unallocated pages that have been in use in a background thread.
> > > 22) clear memory using Int 03h (0xCC) instruction to trap run-away code?
>
> > Yeah, probably.
>
> I like the idea. It may be more useful for debugging though. If memory is
> cleared using 0xCC and Int 03h is called in a bootloader, one must assume a
> virus. What can you do but attempt a clean reboot?
Or it could be a nasty bug somewhere.
Alex
Benjamin David Lunt
Alex
<<<<<<<<<<<
I do this to find which drive I booted from. When I boot,
then make it to the kernel, I scan all available drives and
mount the partitions. Then I need to find which of these
partitions I booted from. Therefore, I use the comment above.
Ben
Rod Pemberton
> "Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
> news:hg2dpa$h05$1...@aioe.org...
> > "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
>
> >> > 17) setting CMOS values, e.g., 0Fh shutdown byte to control reboot?
> >> Nope. The BIOS should do this for you.
> >
> > Isn't a 286 style reset still supported by BIOSes? I.e., if someone
> > changed
> > the CMOS 0Fh shutdown byte to 0x0A, they could bypass a cold or warm
> > reboot
> > and execute their own code. Yes?
>
> But then we come back to the "already too late" issue. If other
> software has already taken control while in your boot sector,
> to be able to modify something that you don't intend to, isn't
> it already too late?
What if one boots DOS. A DOS virus sets the 40:67h vector to it's code, and
CMOS 0Fh appropriately, say CMOS 0Fh=0x0A, jump to 40:67. It then waits
until the user reboots. The reboot jumps to 40:67h due to CMOS 0Fh value.
This 286 style reboot is undetectable by the user, yes? Then the virus sets
an interrupt, say Int 13h, to point to it's code. It then sets CMOS
0Fh=0x04, do Int 19h reboot. It's a double reboot that I suspect is
undetectable from a normal reboot. Won't the modified IVT be preserved?
Same or new OS boots. The user noticed nothing and possibly booted with
undectable IVT changes. In a PM OS setting, you could block port access to
prevent a write to CMOS, but if someone finds a way to write to CMOS and low
memory...
> The theory is, you have full control of the machine at boot time.
> Why wouldn't you have full control?
My thoughts were that 286 style reset could be used to take control upon
_shutdown_ and maintain control through a reboot via modified IVT.
Rod Pemberton
Rod Pemberton
news:ad6276cc-225a-4ab1...@n35g2000yqm.googlegroups.com...
I suspect it's very possible. I was hoping to test this today, but I
haven't gotten to it. I made a note in my OS to do just that, but that was
before I spent time thinking about it. Setting upon bootup only makes sure
it's a safe reboot, if CMOS 0Fh is *not* compromised later on. It won't
stop code loaded afterwards. Setting it prior to reboot, also just makes
sure a safe reboot happens if the reboot goes through the OS' default reboot
mechanism. It too won't catch an intermediate case if reboot occurs via
some method not under OS control. In a PM OS setting, you could block port
access to prevent a write to CMOS, but if someone finds a way to write to
CMOS and low memory...
RP
Rod Pemberton
> > 5) disable NMI (non-maskable interrupts) to prevent hardware
interruptions
> > of bootloader?
>
> Yes, when switching to the Pmode IDT. I cannot think of another
> occasion when this needs to be disabled.
I actually have a note in my code that says NMI must be disabled for CR0
access, but I have no idea where that came from...
> * Place deadbeef-type code or dummy return addresses at top of real
> mode stack so stack underflow can be detected.
Interesting. I've considered using an extra return address on the stack,
in case someone managed to call an extra "ret". The DOS .com, which can
exit via ret, and something in the manuals about NT (nested task) made me
think of doing that.
> * Start multitasking before detecting devices so the devices can be
> detected concurrently (for performance).
Hmm... Isn't that what cause Windows 7 and Vista and Windows XP to start up
stuff before all the device drivers are loaded?
> * Consider changing MTRRs. At the least write the BIOS-set values to
> the system bootup log.
I have a note to do that too, but I don't know what MTRR's are yet.
I also have notes like these:
"some BIOS'es don't zero MSR's 0x174/0x176 CS/IP for SYSENTER/SYSEXIT"
"msrwr CS 0x174, ESP 0x175, EIP 0x176"
"PCI CR bit 3 - Special Cycle Recognition"
"PPro setup MTRRS, clear E in MTRRdefTYPE"
"set D_LICK bit to lockout SMM on supported chipsets"
"set SMMLOCK HWCR bit 0"
Any of those useful?
> * Enable full memory caching. Easy to forget to do.
?
Rod Pemberton
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
The key seems to me (admittedly without much thinking about it) to be
period while interrupts are disabled while transitioning to protected
mode. If we do it right then anything either hooked into an interrupt
vector (including the disk access 0x13 and the 18.2 per sec timer
tick) or loaded in memory when we start will be totally irrelevant
when we switch to Pmode. It may occupy memory but has no way of being
executed. Am I right so far?
During the period while all interrupts are disabled we should have
full control. We can set up a clean IDT and other structures, enter
Pmode and reenable interrupts. This is probably a good time to ensure
the CMOS 0x0f byte is as it should be (zero?).
I suppose while interrupts are still enabled in real mode a rogue
program could be trying to overwrite the loader or parts of the loader
as we are reading it from disk. Maybe the code which executes with
interrupts disabled should include a self-check to test integrity
before entering Pmode and maybe another one afterwards.
Then a rogue program would be much harder to write. It would have to
intercept our OS loader and make changes that still pass the integrity
checks. More difficult but, sadly, not impossible.
Once in safe integrity-checked Pmode we should have full control even
when the interrupts are reenabled. It's then up to us to maintain
security. It may still be worth throwing in a further self-check or
two. (If possible each self-check should carry out a different test.)
How does that sound? And thanks for raising the issue. It's a good
one.
James
James Harris
>
> news:3c0be0ad-2f32-48e0...@v30g2000yqm.googlegroups.com...
>
> > > 5) disable NMI (non-maskable interrupts) to prevent hardware
> interruptions
> > > of bootloader?
>
> > Yes, when switching to the Pmode IDT. I cannot think of another
> > occasion when this needs to be disabled.
>
> I actually have a note in my code that says NMI must be disabled for CR0
> access, but I have no idea where that came from...
The change to Pmode immediately changes the format required for the
IDT. Before NMI can be handled an interrupt handler and possibly some
NMI-specific code are needed. All these things need to be in place
before we reenable NMI. Perhaps that's the reason for your note? I
can't think of a reason for NMI to be disabled for all CR0 changes.
>
> > * Place deadbeef-type code or dummy return addresses at top of real
> > mode stack so stack underflow can be detected.
>
> Interesting. I've considered using an extra return address on the stack,
> in case someone managed to call an extra "ret". The DOS .com, which can
> exit via ret, and something in the manuals about NT (nested task) made me
> think of doing that.
I only have this in my os loader code. When in Pmode and 64-bit modes
we can use guard pages so these things will no longer be needed.
>
> > * Start multitasking before detecting devices so the devices can be
> > detected concurrently (for performance).
>
> Hmm... Isn't that what cause Windows 7 and Vista and Windows XP to start up
> stuff before all the device drivers are loaded?
I don't know about Windows. I should say my plan is for programs to
have dependencies registered against them. The system startup should
then be told to start, say, a user-facing shell. It will identify what
programs the shell depends on and what those programs depend on etc.
This dependency tree should direct what needs to be started first and
relative priorities.
As a slight aside, the dependency tree plan is slightly modified by
the desire to load as few files as possible so all the initial
programs including keyboard access are to reside in just one file if
possible. This should make startup fast but also mean that a basic
working OS is not dependent on many small files so startup will be
more reliable: if the file exists and is readable the OS will start.
The basic files won't have all the bells and whistles but they should
work and will be enough to communicate sensibly with the user any
other problems in terse American English.
>
> > * Consider changing MTRRs. At the least write the BIOS-set values to
> > the system bootup log.
>
> I have a note to do that too, but I don't know what MTRR's are yet.
>
> I also have notes like these:
>
> "some BIOS'es don't zero MSR's 0x174/0x176 CS/IP for SYSENTER/SYSEXIT"
> "msrwr CS 0x174, ESP 0x175, EIP 0x176"
> "PCI CR bit 3 - Special Cycle Recognition"
> "PPro setup MTRRS, clear E in MTRRdefTYPE"
> "set D_LICK bit to lockout SMM on supported chipsets"
> "set SMMLOCK HWCR bit 0"
>
> Any of those useful?
Probably though I don't know what they all mean without looking the
MSRs up. Where did you get the notes?
I like the idea of locking out SMM especially when running the serial
port as I suspect SMM action could lead to loss of data that our OSes
can do nothing about. On the other hand I guess it's SMM which
provides the safety of a power off on a laptop when the power button
is pressed for 5 secs etc.
AIUI the MTRRs are a subset of the MSRs.
>
> > * Enable full memory caching. Easy to forget to do.
>
> ?
Off the top of my head the CD and NW bits in one of the control
registers and the caching bits used in the page tables.
James
Rod Pemberton
> On 14 Dec, 23:23, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > "James Harris" <james.harri...@googlemail.com> wrote in message
> >
news:3c0be0ad-2f32-48e0...@v30g2000yqm.googlegroups.com...
>
> > > the system bootup log.
> >
> > I have a note to do that too, but I don't know what MTRR's are yet.
> >
> > I also have notes like these:
> >
> > "some BIOS'es don't zero MSR's 0x174/0x176 CS/IP for SYSENTER/SYSEXIT"
> > "msrwr CS 0x174, ESP 0x175, EIP 0x176"
> > "PCI CR bit 3 - Special Cycle Recognition"
> > "PPro setup MTRRS, clear E in MTRRdefTYPE"
> > "set D_LICK bit to lockout SMM on supported chipsets"
> > "set SMMLOCK HWCR bit 0"
> >
> > Any of those useful?
>
> Probably though I don't know what they all mean without looking the
> MSRs up. Where did you get the notes?
Unfortunately, I don't know. I just make notes of stuff to look into as I
read about it. The basic answer is "everywhere". I agressively search
Yahoo and Google, newsgroups archives via Google groups, Citeseer, etc. for
information on a number of topics: OS design, language design, interpreters,
compilers, etc.
I think the SMM info was from a security related .pdf I found. IIRC, it was
about hackers using SMM to breach security. I want to say it was BlackHat
(or maybe Phrack) document, but I don't know for sure. Actually, I recall
reading a half dozen of them... So, I probably found one, then went for
more.
The SYSENTER/SYSEXIT may have been from one of those companies that produce
security advisories (CERT), like eEye Digital Security.
I'm going to see if I can locate why I think NMI was needed for CR0 access.
I can confirm that at least half of the "double reboot" method works. I ran
into issues with Int 19h, which may or may not be solvable. The OS I'm
running the code under is DOS. It revectors Int 19h. I need to look into
that a bit more.
Rod Pemberton
Rod Pemberton
> On 14 Dec, 23:23, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > "James Harris" <james.harri...@googlemail.com> wrote in message
> >
news:3c0be0ad-2f32-48e0...@v30g2000yqm.googlegroups.com...
> >
> > > > 5) disable NMI (non-maskable interrupts) to prevent hardware
> > interruptions
> > > > of bootloader?
> >
> > > Yes, when switching to the Pmode IDT. I cannot think of another
> > > occasion when this needs to be disabled.
> >
> > I actually have a note in my code that says NMI must be disabled for CR0
> > access, but I have no idea where that came from...
>
> The change to Pmode immediately changes the format required for the
> IDT. Before NMI can be handled an interrupt handler and possibly some
> NMI-specific code are needed. All these things need to be in place
> before we reenable NMI. Perhaps that's the reason for your note? I
> can't think of a reason for NMI to be disabled for all CR0 changes.
So far, I can't find it. The way my note was written, I thought it was
direct statement from somewhere, not a conclusion of mine. Unfortunately,
the best I can come up with is:
1) I mistook needing NMI for use on CR0 instead of for blocking intterupts
during the init of the IDT
2) 64-bit manuals say the protected mode enabling is slightly different now
due to incompatibilities between 64-bit and 32-bit chips and recommends
following the new 64-bit procedure. They say to _not_ insert instructions
between enabling CR0.PE and the jump instruction to flush the cpu's
instruction cache. (It seems to me thats what was recommended before...)
They say if you do, it may be enough time to allow the cpu to switch into
SMM, if triggered. (That's not good.) I haven't searched the manuals to
see if disabling NMI delays the cpu from entering SMM, but perhaps I was
thinking along those lines... block out every potentiality that I can.
3) I may stumble across it later.
Rod Pemberton
Rod Pemberton
>
> I can confirm that at least half of the "double reboot" method works. I
ran
> into issues with Int 19h, which may or may not be solvable. The OS I'm
> running the code under is DOS. It revectors Int 19h. I need to look into
> that a bit more.
>
Ok, I decided to try to see if I could get the regular Int 19h instruction
to work, i.e., reboot a device. I was having problems with that too.
Eventually, I got the regular Int 19h instruction to _partially_ boot the A:
drive. On this machine, the A: drive must be enabled in BIOS, although it
doesn't have to be first bootable device for the Int 19h instruction to boot
it. I'm not sure why Int 19h doesn't seem to select the first BIOS selected
boot device. So far, it seems to pick A: - no matter what. Since I thought
DOS' changes to the RM IVT was getting in the way of the reboot, I also
tried reloading the default BIOS vectors. That didn't seem to help. So,
maybe there is a problem with BDA, EOI, or PICs, etc. As for the Int 19h
reboot via 40:72 and CMOS 0Fh flags, I haven't been able to get that to boot
anything, even partially. The prompt to boot a device comes up, but nothing
gets booted. Some non-authorative sources say you can also pass in DL to
Int 19h. I may try that later.
Rod Pemberton
s_dub...@yahoo.com
> In your opinion, are these good or bad ideas for use in bootloader or
> bootsector?
> (many unposted ideas, but also recycling some ideas I've posted lately...)
>
> 0) use DL value passed by Int 19h?
2.4 Transferring Control to the Operating System
The very last function of the system BIOS POST after loading and
validating the operating system boot
sector is to transfer control. In an ISA system, control is
transferred without any parameters. In a Plug
and Play system BIOS, parameters will be passed to the operating
system. The parameters are:
Entry: ES:DI Pointer to System BIOS Plug and Play Installation Check
Structure (See section 4.4)
DL Physical device number the OS is being loaded from (e.g. 80h,
assuming the device
supports INT 13H interface.)
In a non-Plug and Play operating environment this information will
have no meaning. However, a Plug
and Play operating system will look for a Plug and Play system BIOS
and use any information it may
need. The physical device number is passed to allow the operating
system to continue to load from the
current physical device, instead of assuming a physical device of 00h
or 80h.
Ref: http://download.intel.com/support/motherboards/desktop/sb/pnpbiosspecificationv10a.pdf
IPL PnP Boot device scheme..
Ref: http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdf
(also talks about int 19h & int18h & int 13h behavior in the POST)
I save ES:DI & DL first thing in the boot strap code to 0051:0010
area. Later you can check for $PnP to validate the info. In my
experience, even non PnP old systems pass in DL the boot device
number.
Steve
Maxim S. Shatskih
>assuming the device
>supports INT 13H interface.)
I.e. this worked on pre-PnP machines like XT and AT.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Rod Pemberton
> "Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
> news:hg6s4r$dh$1...@aioe.org...
> >
> > I can confirm that at least half of the "double reboot" method works. I
> ran
> > into issues with Int 19h, which may or may not be solvable. The OS I'm
> > running the code under is DOS. It revectors Int 19h. I need to look
into
> > that a bit more.
>
> Ok, I decided to try to see if I could get the regular Int 19h instruction
> to work, i.e., reboot a device. I was having problems with that too.
>
Well, I got that to work, sort of. In DOS "safe mode", the Int 19h
instruction will boot any enabled device, but not following the BIOS boot
order. It'll boot A: first. So, DOS is interefering with a normal Int 19h
instruction, somehow.
> As for the Int 19h
> reboot via 40:72 and CMOS 0Fh flags, I haven't been able to get that to
boot
> anything, even partially.
Still haven't. It just doesn't seem to work. I've even tried it in a
bootloader! I'm not sure what's going on with this reset option... If I
install an Int 19h routine, Int 19h does get called. The values in AX and
DX seem odd, but technically the routine shouldn't take any inputs. I've
also tried it with a number of different values in 40:72, in case it needed
a certain value.
Rod Pemberton
James Harris
> "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
>
> news:hg91jp$12m$1...@aioe.org...
>
> > "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
Some guesses. Did you check if the CMOS value was set successfully and
was it still set after the reboot? Did you set a code address in 40:67
dword - presumably a far address? RBIL says
MEM 0040h:0067h - RESET RESTART ADDRESS
Size: DWORD
Desc: this address stores the address at which to resume execution
after a
CPU reset (or jump to F000h:FFF0h) when certain magic values are
stored at 0040h:0072h or in CMOS RAM location 0Fh
SeeAlso: MEM 0040h:0072h,MEM F000h:FFF0h,CMOS 0Fh,INT 19
Copied from Ralf Brown's Interrupt List
There are some magic values for 40:72 but they seem to be optional.
The CMOS 0xf set to 0xa should allegedly work regardless of 40:72.
James
Rod Pemberton
> On 16 Dec, 22:46, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
> > news:hg91jp$12m$1...@aioe.org...
> >
> > [...]
> > It just doesn't seem to work.
>
Er... no...
> and was it still set after the reboot?
That's the problem. One of the two Int 19h methods I'm attempting to use
doesn't work. So far, I've been testing them separately.
> Did you set a code address in 40:67
No. I was assuming that since it's called "int 19h reset", it would resume
execution at the segment:offset of the Int 19h vector. So, I thought that
an address at 40:67 wasn't necessary. (?) I probably should do that just to
confirm. I know it makes it to Int 19h, so I'd wonder about needing 40:67.
> There are some magic values for 40:72 but they seem to be optional.
http://groups.google.com/group/comp.lang.asm.x86/msg/a6867183d81b52fc
IIRC, RBIL also covers the 40:72 and CMOS values. The PS/2 tech. ref. had
some of the 40:72 values, but I couldn't locate CMOS values.
> The CMOS 0xf set to 0xa should allegedly work regardless of 40:72.
The 0x0a reset jump to 40:67 works. The 0x04 reset, I'm having problems
with. I tried it with 0, 1234h, 4321h for 40:72h. 0x0b and 0x0c resets
look interesting... Is the iret/retf how it transfers to 40:67h or how a
jump to 40:67h returns? If the later, just where would it return to? Does
4321h work with all CMOS values? I need more info. Didn't someone around
here have some books on "undocumented" BIOS?
Rod Pemberton
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
> news:a2f16f9f-4d69-4e3d...@r5g2000yqb.googlegroups.com...
>
> > On 16 Dec, 22:46, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > > "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
> > >news:hg91jp$12m$1...@aioe.org...
>
> > > > As for the Int 19h
> > > > reboot via 40:72 and CMOS 0Fh flags, ...
> > > [...]
> > > It just doesn't seem to work.
>
> > Some guesses. Did you check if the CMOS value was set successfully
>
> Er... no...
>
> > and was it still set after the reboot?
>
> That's the problem. One of the two Int 19h methods I'm attempting to use
> doesn't work. So far, I've been testing them separately.
>
> > Did you set a code address in 40:67
>
> No. I was assuming that since it's called "int 19h reset", it would resume
> execution at the segment:offset of the Int 19h vector. So, I thought that
> an address at 40:67 wasn't necessary. (?) I probably should do that just to
> confirm. I know it makes it to Int 19h, so I'd wonder about needing 40:67.
The way I read it was that 0x40:67 is invoked after the bulk of the
reboot sequence. And I don't know how far int 0x19 mirrors a full
restart.
>
> > There are some magic values for 40:72 but they seem to be optional.
>
> http://groups.google.com/group/comp.lang.asm.x86/msg/a6867183d81b52fc
>
> IIRC, RBIL also covers the 40:72 and CMOS values. The PS/2 tech. ref. had
> some of the 40:72 values, but I couldn't locate CMOS values.
>
> > The CMOS 0xf set to 0xa should allegedly work regardless of 40:72.
>
> The 0x0a reset jump to 40:67 works. The 0x04 reset, I'm having problems
> with. I tried it with 0, 1234h, 4321h for 40:72h. 0x0b and 0x0c resets
> look interesting... Is the iret/retf how it transfers to 40:67h or how a
> jump to 40:67h returns? If the later, just where would it return to? Does
> 4321h work with all CMOS values? I need more info. Didn't someone around
> here have some books on "undocumented" BIOS?
I've got the book "The Undocumented PC." Do you have a copy? And if
not, why not? :-)
Since you say you have 0x0a working (which I take to mean jumping to
the routine address in 0x40:67-6a in real mode after a restart) what
else do you require? The 0x04 reset should apparently go to a disk
bootstrap routine.
BTW it seems that not all of the values for CMOS register 0x0f are
supported on all PCs. Do you need any more than you already have?
James
Rod Pemberton
>
> I've got the book "The Undocumented PC."
Does it have the information I desire?
If so, you would've posted it, yes? :-)
> Do you have a copy?
I don't believe so...
AFAIR, I'm not in possession of any of the "undocumented" books by various
authors. (PC, DOS, BIOS, Windows, etc.)
> And if
> not, why not? :-)
The Internet is a large source of information: RBIL, data sheets,
specifications, tech. ref. man.'s, security documents, source code, etc.
Albeit, only a small amount of useful source prior to '98 is findable
online, and many websites created from '99 to '04 are disappearing fast.
Unfortunately, sometimes it can take years before the big search engines
pick up these sites, or put them up high enough in their search results that
one can find them. Fortunately, CiteseerX and WayBack Machine are saving
some stuff. Sadly, it's nearly impossible to find anything in WayBack
Machine, unless you have a link to the original site. It'd be good if
Google took them over. Although, I'd prefer Yahoo...
And, it's likely many "undoc" books are available from a Public Library or
via inter-library loan. I just haven't had the desire to track them down.
That reminds me. Although unlikely, it's possible they are available on
Google books.
I found two reference to Gilluwe's undoc. on Int 19h. The first, the guy
says you shouldn't use Int 19h. The second, the guy says there is a bunch
of work to do prior to using Int 19h. However, I suspect these comments are
in regards to calling Int 19h vector via an Int 19h instruction. I suspect
this information is probably not in regards to calling Int 19h vector via
286 BIOS reset method, which may have additional intricacies.
> Since you say you have [...]
If I can get _both_ of the resets working, then I can test the premise that
changing the shutdown byte could allow someone to install an IVT vector and
code prior to a reset which survives said reset. From past experiments, I'm
pretty sure the version of DOS that I use very aggressively clears memory.
Other OSes are likely to do so to. So, even if I can prove that one can
preserve (some) vectors through a reset, I might not be able to prove that
installed code can survive a reset. But, I'd like to know for sure, at
least for my own OSes security, if not for a few utilities... :)
> Since you say you have 0x0a working (which I take to mean jumping to
> the routine address in 0x40:67-6a in real mode after a restart)
That's the first half:
1) need to be able to "reboot" while preserving memory and jump to code
at a known location (0x0A)
> what
> else do you require?
This is the second half:
2) need to be able to reboot "normally" (e.g., POST messages, boot from BIOS
selected boot drive, etc.) while preserving memory (0x04)
The Int 19h instruction boots a device. 0x04 ("Int 19h reset") is hanging
for me, instead of booting a device.
> The 0x04 reset should apparently go to a disk
> bootstrap routine.
I've confirmed 0x04 goes to Int 19h vector. So far, 0x04 doesn't call
40:67h segment:offset. But, it's hanging, so 40:67h may be called later,
although I really doubt this.
> BTW it seems that not all of the values for CMOS register 0x0f are
> supported on all PCs.
True. Some embedded BIOSes only support 0x05 and 0x0A (and probably 0x0).
It seems some BIOSes only support 0x04, 0x05, 0x0a (and probably 0x0).
> Do you need any more than you already have?
I don't need to "have" any more values for CMOS or 40:72h.
I need to "have" both 0x0a and 0x04 resets working.
I've done quite a number of other "shotgun" tests and combinations. None
have worked. Maybe I need to install Bochs or disassemble some BIOS, if I
want to pursue this completely. I may come back to this at a later time.
Rod Pemberton
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
> news:d1cdf4a5-fa46-4aa5...@n35g2000yqm.googlegroups.com...
>
>
>
> > I've got the book "The Undocumented PC."
>
> Does it have the information I desire?
>
> If so, you would've posted it, yes? :-)
I was hoping not to have to! It has a lot to say on the topic. In fact
the deeper I dig the more I find. It has sections in surprising detail
on the CMOS values, the 0x40:xxxx memory addresses, use of int 0x19,
how to reset a PC reliably and how to get control before reset etc.
>
> > Do you have a copy?
>
> I don't believe so...
>
> AFAIR, I'm not in possession of any of the "undocumented" books by various
> authors. (PC, DOS, BIOS, Windows, etc.)
>
> > And if
> > not, why not? :-)
>
> The Internet is a large source of information: RBIL, data sheets,
> specifications, tech. ref. man.'s, security documents, source code, etc.
Yes, the Internet is essential but IMHO there are three sources that
should be on the bookshelf of anyone trying to write an OS for a PC:
1. RBIL
2. The Indispensable PC Hardware Book second edition
3. The Undocumented PC
These form a triumvirate of useful information and I wouldn't
particularly rank one above another. Each has something to bring to
the table. Since we are on the topic of The Undocumented PC a big plus
for it is the author's detailed research and clear prose to explain
things. Things which Messmer gets wrong, for example, van Gilluwe gets
right and includes code samples to show the details of how to do
things.
> Albeit, only a small amount of useful source prior to '98 is findable
> online, and many websites created from '99 to '04 are disappearing fast.
> Unfortunately, sometimes it can take years before the big search engines
> pick up these sites, or put them up high enough in their search results that
> one can find them. Fortunately, CiteseerX and WayBack Machine are saving
> some stuff. Sadly, it's nearly impossible to find anything in WayBack
> Machine, unless you have a link to the original site. It'd be good if
> Google took them over. Although, I'd prefer Yahoo...
>
> And, it's likely many "undoc" books are available from a Public Library or
> via inter-library loan. I just haven't had the desire to track them down.
> That reminds me. Although unlikely, it's possible they are available on
> Google books.
>
> I found two reference to Gilluwe's undoc. on Int 19h. The first, the guy
> says you shouldn't use Int 19h. The second, the guy says there is a bunch
> of work to do prior to using Int 19h. However, I suspect these comments are
> in regards to calling Int 19h vector via an Int 19h instruction. I suspect
> this information is probably not in regards to calling Int 19h vector via
> 286 BIOS reset method, which may have additional intricacies.
Seeing quotes is no substitute for reading the book, eh!
...
I'll reply to the second half of your post separately.
James
James Harris
...
> > Since you say you have [...]
>
> If I can get _both_ of the resets working, then I can test the premise that
> changing the shutdown byte could allow someone to install an IVT vector and
> code prior to a reset which survives said reset. From past experiments, I'm
> pretty sure the version of DOS that I use very aggressively clears memory.
> Other OSes are likely to do so to. So, even if I can prove that one can
> preserve (some) vectors through a reset, I might not be able to prove that
> installed code can survive a reset. But, I'd like to know for sure, at
> least for my own OSes security, if not for a few utilities... :)
If I follow.... Is there a problem when you can ensure the CMOS byte
is as you want it to be before shutdown? In your OS you can prevent
any changes to it. You can also ensure the two bytes at 0x40:72
contain whatever you want them to be. This, of course, relates to
security while running and at shutdown. There are other issues on
startup (that we already discussed).
>
> > Since you say you have 0x0a working (which I take to mean jumping to
> > the routine address in 0x40:67-6a in real mode after a restart)
>
> That's the first half:
> 1) need to be able to "reboot" while preserving memory and jump to code
> at a known location (0x0A)
It sounds like you want to be able to do this (rather than just
preventing someone else from doing so).
>
> > what
> > else do you require?
>
> This is the second half:
> 2) need to be able to reboot "normally" (e.g., POST messages, boot from BIOS
> selected boot drive, etc.) while preserving memory (0x04)
Sounds dangerous. Unless the bootup resets the interrupt vectors at
the least a machine could reboot with all kinds of nasties kicking
around. Are you sure you don't want memory reset?
If it helps, van Gilluwe says, in part:
(Chapter 3) "There seem to be many approaches to resetting the CPU
from software, but only a few will work reliably. Some approaches will
appear to work on one machine while they fail to work reliably on
another.... [Interrupt 0x19] should *never* be called from an
application.... With AT systems and later, the processor can be reset
under software control. This is accomplished by sending a command to
pulse the reset line to the keyboard controller.... On MCA and some
EISA systems, a much easier and faster approach is available."
> The Int 19h instruction boots a device. 0x04 ("Int 19h reset") is hanging
> for me, instead of booting a device.
Sounds like you need to carry out a machine reset (which will itself
call int 0x19).
BTW, sorry if I've not properly understood what you were trying to do
and my comments have been off topic. I'm conscious that not certain of
your plans so my comments may not be of help.
James
Rod Pemberton
>
> BTW, sorry if I've not properly understood what you were trying to do
> and my comments have been off topic.
>
I though you were following at first...
I've got code in my OS to reboot via different methods. The ones I was able
to test, work. Currently, I set CMOS 0x0F and 40:72h only when needed for a
specific reboot. I don't set default values for them. I will do so for
safety.
What I'm trying to confirm is not related to my OS. Theoretically, it
should work for all OSes, if the user has sufficient privilege whether
legitimately granted or not. I'm trying to confirm whether the old 286
resets via BIOS can be used (or abused) to allow code and modified IVT to
survive a machine reboot.
As you know, there are two well known PC reboots: cold and warm. These work
by setting CMOS 0x0F and 40:72h to 0 (full reset) and 0 (cold) respectively
for a cold reset and 0 (full reset) and 1234h (bypass memory test) for a
warm reset (i.e., ctrl-alt-del) and then resetting the cpu. The 80386 or
later cpu can be reset by various methods: lidt of null IDT, keyboard reset,
fast PS/2 reset. But, the 80286 had *NO* software method to exit PM. Once
the cpu was in protected mode (PM) it was "stuck" until a cpu reset. But,
doing a cpu reset also rebooted the entire PC. I.e., memory wipe, reinstall
IVT, reboot floppy or harddisk, etc. So, the BIOS was modified during the
286 era to allow specialized resets with/without reboots, etc. These are
the other CMOS 0x0F and 40:72h values in the posted link. AIUI, the primary
purpose of these was to be able to switch the 80286 cpu from PM to RM via a
cpu reset _without_ rebooting the machine. On a 386+, the cpu can be reset
in software, the cpu modes can be changed via software, and so the 386+
doesn't need help from the BIOS. But, the old 286 BIOS reset methods are
still present in a modern BIOSes, for compatibility with old code. It
occurred to me that by using two of these 286 reset methods that it might be
possible to install code and modified IVT vectors which could survive a
machine reboot. The first 286 style reset is to trap execution, install the
code, and install IVT modifications _after_ the OS has initiated it's
shutdown. IMO, it's more realistic to do this after the OS releases
privileges and control of IVT and memory. The second 286 style reset is to
do the actual machine reboot. Both reboots must preserve memory.
The holidays are around the corner, so I have to take a break from this.
Rod Pemberton
J de Boyne Pollard
AAF> bootsectors of your OS and [...]
... get bitten when your unique IDs accidentally match data in the VBR
of another partition.
AAF> That's the same idea behind the
AAF> detection of the floppy change, [...]
... with the same well-known flaws. Reinventing this particular wheel
of course leads to things like having to write a DISKCOPY-like command
that does the same with one's unique signatures as DISKCOPY does with
volume serial numbers. It's often forgotten that a design decision
such as this has consequences outside of just some boot record code.
One consequence here is that suddenly one loses the "Oh, I can just
'dd' straight from one volume to another and it will all be alright."
paradigm. An operating system designer has to think about whether xe
is happy to trade the loss of that for the VBR unique ID mechanism.
J de Boyne Pollard
RP> take control upon _shutdown_ [...]
Then it's an issue for your shutdown code, not your bootstrap code.
Your shutdown code, if it is general-purpose, is already mucking about
with firmware APIs. A general-purpose shutdown procedure would be
distinguishing between shutdown-and-power-down and shutdown-and-
reboot, for example, which requires dealing in firmware APIs.
Ensuring that the various firmware bootstrap short-cuts are always
disabled, or directed to trusted code, is not a large step beyond that.
J de Boyne Pollard
JH> In general I can't see a way to prevent all hacks, though.
Xe wasn't the first to do so. This is, after all, partly what
"Trusted Computing" deals in. Read about all of the integrity checks
that Windows NT 6 and 7 perform at bootstrap time.
t
news:47a27995-62b9-4a3e...@u7g2000yqm.googlegroups.com...
> RP> My thoughts were that 286 style reset could be used to
> RP> take control upon _shutdown_ [...]
>
> Then it's an issue for your shutdown code,
As stated elsewhere, this has nothing to do with my OS code. In theory, the
ability to use two 286 style resets to install and preserve active code
using old BIOS mechanisms could affect nearly every IBM style PC and PC OS
ever created. I'd like to make sure that's _not_ possible. If it is, it
needs to get reported to reputable security firms. If it is, it'd be useful
for a few debugging utilities also. So far, it seems it's up to me to prove
it, or perhaps someone more adept will since I've been having problems with
part of the BIOS reset on this machine. Hopefully, that person will have
good intentions.
Rod Pemberton
Rod Pemberton
> JH> You raise some interesting points on security. [...]
> JH> In general I can't see a way to prevent all hacks, though.
>
> Xe
[Xe, gender neutral pro-noun...]
I've mentioned this to you previously. You know that I'm a "he", if not
from the name (male), then from both my current and previous statements (a
few years ago). You should also be able to guess with high probability that
I'm male from the given topic of this newsgroup. It's not a topic with
large numbers of female participants. While use of "Xe" shows tolerance
towards a group of people in an extremely small minority (FGA - female
gender assignment), or allows simplified mental representation of concepts
too abstract (sexualtiy) for another extremely small minority group
(Asperger's syndrome), I think it is offensive to dehumanize me to the point
that I'm described in an indeterminate, or as a transitive gender state.
Like it or not, gender is a fundamental part of human identity. You should
respect that. It is used in all parts of in-person social interaction.
Even if I'm more adept with machines and ideas than people, I'm not a
machine, car, or tree for that matter. I'm a (non-gender neutral) person.
If you're not a member of those minorities and are just using "Xe" as
novelty speech or politically correct speech, I respectfully request that
you stop using "Xe" instead of "He" to refer to me.
> [He] wasn't the first to do so.
Nothing posted here ever is. Is it? If something was hugely original, do
you think anyone - other than me - would present it? Was there a point
pointing that out - using me to do so? Although I took no offense, it
seemed to be a somewhat personal "jab." Or, was it just a poor segway to
the following?
> This is, after all, partly what
> "Trusted Computing" deals in.
Are "security" and "trusted computing" the same? Or, is "security" a subset
of "trusted computing"? "Trusted Computing", in capitals, seems to refer to
a specific technology implementation.
> Read about all of the integrity checks
> that Windows NT 6 and 7 perform at bootstrap time.
Post a link.
RP
J de Boyne Pollard
RP> take control upon _shutdown_ [...]
JdeBP> Then it's an issue for your shutdown code,
RP> As stated elsewhere, this has nothing to do with my OS code.
As you stated at the very start of this thread, you are asking about
bootstrap code. And as *the rest of that sentence* that you edited
out said, this is an issue for your shutdown code, *not your bootstrap
code*. Read to the ends of sentences before hitting that "reply"
button.
J de Boyne Pollard
RP> Nothing posted here ever is. Is it? If something was
RP> hugely original, do you think anyone - other than me
RP> - would present it? Was there a point pointing that
RP> out - using me to do so? Although I took no offense,
RP> it seemed to be a somewhat personal "jab." Or,
RP> was it just a poor segway to the following?
It's an extreme reach to see anything personal there except a personal
pronoun. You're reaching, and replying to individual words again.
Read whole sentences, and read the sentences in the context of the
paragraph that they belongs to. Remember Unmistakable Mark #4.
JdeBP> Xe wasn't the first to do so. This is, after all, partly
JdeBP> what "Trusted Computing" deals in. Read about all
JdeBP> of the integrity checks that Windows NT 6 and 7
JdeBP> perform at bootstrap time.
RP> Are "security" and "trusted computing" the same? Or,
RP> is "security" a subset of "trusted computing"? "Trusted
RP> Computing", in capitals, seems to refer to a specific
RP> technology implementation.
RP> Post a link.
Come now! You don't need to be spoon-fed either the meaning of
"Trusted Computing" or how to find out about the Windows NT bootstrap,
surely? There's a Wikipedia entry for "Trusted Computing". And it's
not hard to find WWW sites that discuss the Windows NT 6/7 bootstrap
process, or indeed books on the subject, wherein this information can
be found. There's a Wikipedia entry, handily entitled "Windows Vista
startup process", that links to one, for starters. Russinovich's and
Solomon's _Windows Internals_ gives it some discussion. There's also
a 2005 WinHEC paper by Microsoft on Trusted Computing, giving a
technical overview of full volume encryption and the "Secure Startup"
process that it forms a part of, that describes what portions of the
bootstrap are "measured" into the several TPM registers. And there's
also a paper by Matthew Conover of Symantec corporation on the
integrity checks performed in Windows NT 6's bootstrap, entitled
"Assessment of Windows Vista Kernel-Mode Security".
Rod Pemberton
>
> You're reaching,
You're dismissive.
> and replying to individual words again.
Delusional... I replied to you. They were your words. Take responsibility
for them.
> Read whole sentences, and read the sentences in the context of the
> paragraph that they belongs to.
"Pot" calling the "Kettle" black? Yet, I did that - what you just
requested. So, I guess it'd be "Pot" perceiving white "Sugar" is a black
"Kettle" first, and then the "Pot"... ? Anyway, it's your other posts in
this thread that are out of order. So, once again, it seems odd you are
transfering your mistakes onto me. (See "transference".)
> Unmistakable Mark #4
?
JdeBP> [He] wasn't the first to do so. This is, after all, partly
JdeBP> what "Trusted Computing" deals in. Read about all
JdeBP> of the integrity checks that Windows NT 6 and 7
JdeBP> perform at bootstrap time.
RP> Are "security" and "trusted computing" the same? Or,
RP> is "security" a subset of "trusted computing"? "Trusted
RP> Computing", in capitals, seems to refer to a specific
RP> technology implementation.
RP> Post a link.
JdeBP> Come now! You don't need to be spoon-fed either the meaning of
JdeBP> "Trusted Computing" or how to find out about the Windows NT
bootstrap,
JdeBP> surely?
Exactly. As I perceive them, they are not the same. And yet, you mentioned
"Trusted Computing" in regards to (trivial) security issues for a
bootloader... i.e., you implied equivalence. I would've expected you to
perceive them as being different also as you now imply you are aware. But,
I'm not yet able to determine for sure if that would be an accurate
statement in regards to you, since you didn't answer my question but chose
to criticize me instead. So, why did you mention them as if they were
synonymous?
Rod Pemberton
Rod Pemberton
RP> My thoughts were that 286 style reset could be used to
RP> take control upon _shutdown_ [...]
JdeBP> Then it's an issue for your shutdown code,
RP> As stated elsewhere, this has nothing to do with my OS code.
> As you stated at the very start of this thread, you are asking about
> bootstrap code.
For that part of the thread, true. For this part of the thread, false. The
topic was changed to the following, which was a question asked by me:
RP> Isn't a 286 style reset still supported by BIOSes? I.e., if someone
changed
RP> the CMOS 0Fh shutdown byte to 0x0A, they could bypass a cold or warm
reboot
RP> and execute their own code. Yes?
See? Responses to that question are a different topic. The question was
inspired by the original topic.
> And as *the rest of that sentence* that you edited
> out said,
Irrelevant, also. I just decided to leave in some irrelevance... To most,
it would've looked odd if I'd replied to you without some context actually
from you. Don't you agree?
> Read to the ends of sentences before hitting that "reply"
> button.
I read everything. As is typical for you, you failed to read the entire
thread prior to posting so your responses were out of order. And you failed
to comprehend that: 1) the topic of conversation changed, 2) your statements
as where posted are irrelevant to the current topic.
Rod Pemberton
s_dub...@yahoo.com
> "J de Boyne Pollard" <J.deBoynePoll...@Tesco.NET> wrote in messagenews:867542b7-d2ed-4ee6...@z41g2000yqz.googlegroups.com...
>
> > JH> You raise some interesting points on security. [...]
> > JH> In general I can't see a way to prevent all hacks, though.
>
>
> > This is, after all, partly what
> > "Trusted Computing" deals in.
>
> Are "security" and "trusted computing" the same? Or, is "security" a subset
> of "trusted computing"? "Trusted Computing", in capitals, seems to refer to
> a specific technology implementation.
>
> > Read about all of the integrity checks
> > that Windows NT 6 and 7 perform at bootstrap time.
>
> Post a link.
>
> RP
Re: "Are "security" and "trusted computing" the same?" - NIML, Not In
My Lexicon, heh.
"security" resides in the hand of the user (well should),
"trusted computing" trust no one, especially the user, only us TPM
implementers.
http://en.wikipedia.org/wiki/BitLocker_Drive_Encryption
"According to Microsoft sources,[14][15] BitLocker does not contain an
intentionally built-in backdoor; ..."
hmm. surely no embedded flight simulator in excel either..
"Nevertheless, in February 2008, a group of security researchers
published details of a so called "cold boot attack" that allows a
Bitlocker-protected machine to be compromised by booting the machine
off removable media, such as a USB drive, into another operating
system, then dumping the contents of pre-boot memory"
Steve
Maxim S. Shatskih
No such thing for years, since 2000 or so.
>"Nevertheless, in February 2008, a group of security researchers
>published details of a so called "cold boot attack" that allows a
>Bitlocker-protected machine to be compromised by booting the machine
>off removable media, such as a USB drive, into another operating
>system, then dumping the contents of pre-boot memory"
Any BitLocker-type product can be compromized in such a way.
s_dub...@yahoo.com
<ma...@storagecraft.com.no.spam> wrote:
> >hmm. surely no embedded flight simulator in excel either..
>
confidence in that capability.
> No such thing for years, since 2000 or so.
Good, I'll have to take you as an authority on that point. There is
the irony; placing my trust in a third party authority, after the
first party has shaken it.
>
> >"Nevertheless, in February 2008, a group of security researchers
> >published details of a so called "cold boot attack" that allows a
> >Bitlocker-protected machine to be compromised by booting the machine
> >off removable media, such as a USB drive, into another operating
> >system, then dumping the contents of pre-boot memory"
>
> Any BitLocker-type product can be compromized in such a way.
>
And so, near worthless. Except its worth may be to shake my
confidence yet again.
Steve
s_dub...@yahoo.com
>
> - Show quoted text -
Speaking about confidence, and who is watching the watchers, yahoo
news reports:
"Tarnovsky figured out a way to break chips that carry a "Trusted
Platform Module," or TPM, designation by essentially spying on them
like a phone conversation. "
http://news.yahoo.com/s/ap/20100208/ap_on_hi_te/us_tec_crypto_chip_cracked
Steve
Rod Pemberton
news:18ebdb98-20f6-4037...@o28g2000yqh.googlegroups.com...
>
> Speaking about confidence, and who is watching the watchers, yahoo
> news reports:
>
> "Tarnovsky figured out a way to break chips that carry a "Trusted
> Platform Module," or TPM, designation by essentially spying on them
> like a phone conversation. "
>
Did you read _how_ he did it though?
He used chemicals to remove (i.e., etching) all the plastic casing on the IC
and to expose and/or remove wiring. Then he probed around with a fine wire
probe, likely connected to a high speed digital oscilloscope, until he found
signals he wanted to decrypt. Of course, he also had to have had a
zero-oxygen environment setup to do this, since the circuit was powered
while probing. You also need many copies of the exact IC and circuit board.
You're likely to destroy a few IC's by the etching methods, since etching is
non-exact. You're also likely to destroy a few IC's when "probing" the
circuit while powered.
The techniques he used have been around for some time. Normally, EE's
(Electrical Engineer's) of one IC company use those techniques to
investigate potential patent violations by another IC company. It's the
first time I recall hearing of a non-circuit designer, or non-EE using them.
But, if you check old magazines, you'll probably find that someone did that
with VideoCipher (satellite video) with DES encrypted audio, or maybe later
on with the Xbox.
Rod Pemberton
s_dub...@yahoo.com
> <s_dubrov...@yahoo.com> wrote in message
>
> news:18ebdb98-20f6-4037...@o28g2000yqh.googlegroups.com...
>
>
>
> > Speaking about confidence, and who is watching the watchers, yahoo
> > news reports:
>
> > "Tarnovsky figured out a way to break chips that carry a "Trusted
> > Platform Module," or TPM, designation by essentially spying on them
> > like a phone conversation. "
>
> Did you read _how_ he did it though?
>
Yes. It speaks to 'where there is a will there is a way'. A
different sort of 'back door'. :)
> He used chemicals to remove (i.e., etching) all the plastic casing on the IC
> and to expose and/or remove wiring. Then he probed around with a fine wire
> probe, likely connected to a high speed digital oscilloscope, until he found
> signals he wanted to decrypt. Of course, he also had to have had a
> zero-oxygen environment setup to do this, since the circuit was powered
> while probing. You also need many copies of the exact IC and circuit board.
> You're likely to destroy a few IC's by the etching methods, since etching is
> non-exact. You're also likely to destroy a few IC's when "probing" the
> circuit while powered.
>
> The techniques he used have been around for some time. Normally, EE's
> (Electrical Engineer's) of one IC company use those techniques to
> investigate potential patent violations by another IC company. It's the
> first time I recall hearing of a non-circuit designer, or non-EE using them.
> But, if you check old magazines, you'll probably find that someone did that
> with VideoCipher (satellite video) with DES encrypted audio, or maybe later
> on with the Xbox.
>
Yes,...
"
1973...
I was sitting quietly at my desk when Masatoshi Shima hurried into
my office
at Intel and asked me to follow him to his laboratory down the hall.
In the
middle of his work bench, among the typical snaggle of jumpers,
oscilloscopes
and multi-meters, sat a binocular microscope with spider-leg probes,
all of
which were subjecting a minute piece of silicon to helpless
investigation. I
peered through the microscope at the enlarged regular patterns with
particular
interest. As a consultant, my job was to design and develop certain
software
tools for Intel. One was Interp/80, a program which simulated
Intel's newly
evolved 8080 microprocessor to be used by Intel customers on time-
sharing
systems. As I searched for something recognizable, I hoped my
simulation
resembled the operation of Shima's first 8080 chip which had finally
come to
life.
"
- "The Evolution of an Industry: One Person's Viewpoint"
Gary Kildall
DDJ ("Dr. Dobb's Journal"), #41, Vol.5, No.1, January 1980, pp.6-7
> Rod Pemberton
Maxim S. Shatskih
> and to expose and/or remove wiring.
Amazing! First time I've heard for such a hacker!
Governemental institutions did this for years, since the cloning of x86 CPU by some research institute in Kiev, USSR, in around 1985 - after they discovered the topology of the chip, in turns out that the Soviet industry was uncapable of this gate size - so they redesigned the topology to be compatible with larger gates.
But the hackers...