Client boots, loads consisting of a tiny Linux Kernel and network driver, and a script or program [Non-NVRAM setup] Client listens for predefined broadcast from Emu(server) When found, Kernel contacts Emu and establishes connection Emu starts logging all activity Kernel reads local bios to Emu [Non-NVRAM setup] Emu executes received bios (emulated), directing all output to Kernel Kernel directs/passes received output to hardware, directs/passes hardware results to Emu Assuming the Kernel does not get overwritten or lose control of system (crash), we now have a log of all neccesary and expected results of that bios on boot on that hardware. This would allow reverse engineering bioses and developing bioses for hardware legally?
BIOS | v A) Emu<->network<->Kernel OR B) ROM Image->Emu<->network<->Kernel Bios<->system/devices ^ | v system/devices
If the above ascii depiction is off, bios is above kernel is above system/devices
Also, as in B) Client can be burned to Flash NVRAM, and ROM images can be fed through Emu to Kernel (Bios) One possibility for A) is loading Client via PXE/bootp/Network boot.
* Justin Hawkeye hawkeyeaz1@gmail.com [060419 20:16]: [..]
Assuming the Kernel does not get overwritten or lose control of system (crash), we now have a log of all neccesary and expected results of that bios on boot on that hardware. This would allow reverse engineering bioses and developing bioses for hardware legally?
Problems with this approach:
- compare it to driving a car. at one intersection the car just drives on. At another one it stops. This way you run into another car in the first intersection and most probably (murphy's law) halt without a reason on the second.
- you can never do better than factory bios
- the emulator would have to pass calls to the hardware. qemu, bochs and co emulate their own hardware.
Stefan
-
Justin Hawkeye -
Stefan Reinauer