common flash hw write enable methods

[Stefan Reinauer]

* Ronald G. Minnich <rminnich at lanl.gov> [021202 04:43]:
> Another way I found it on one board was to try every combination of GPIOs 
> until the FLASH started working. Not fun, but pretty fast if you write a 
> program.
 
Some machines, like my Thinkpad A21p, reboot immediately on probing, if
the right GPIO is not set. Pretty ugly. 

> get the flash burner for this board, run under a simulator of some sort, 
> and watch the IOs. Or put a PCI bus analyzer on the machine, run the flash 
> program, and watch the IOs. It's not going to be fun.
 
ouch! sounds like this gets nasty quickly.

> I still don't see how running under Bochs helps with the chipset but maybe 
> I missed something. 

It doesn't. Basically most flasher programs use some kind of data
structure the look for in the bios memory, that contains pointers to
functions like "map flash to memory", "disable write protection", etc.
This is at least the case with AMI and Award, probably Phoenix as well.
These are 16bit calls, which makes it kind of hard/impossible to really
use directly. It's possible to search for this structure and look at 
the code. However, this is likely to be illegal in many countries.

> No, the goal is to make it hard for you to reflash. So the vendors keep 
> coming up with new ways to hide this. Very annoying!

Especially after the first non-vendor-written flashers appeared, many
people were scared of viruses destroying the flash data and such.
Security by obscurity...

  Stefan

-- 
The x86 isn't all that complex - it just doesn't make a lot of
sense.          -- Mike Johnson, Leader of 80x86 Design at AMD
	                          Microprocessor Report (1994)