OSDev.org

Hi everyone,

I'm looking to experiment with a self-distributing system that basically acts similar to a virus, but doesn't have a malicious intent!!! What I aim to do is to create a minimal system containing a Genetic Algorithm, allowing it to evolve; a sort of artificial organism. So far, I've had the idea of implementing the said system as a PXE NBP that contains a PXE server. In other words, a PXE server would distribute this system to other computers, which would then itself run as a PXE server and redistribute itself! I would use the APIs provided by the PXE client to implement the PXE server.

However, I want to be able to also copy this NBP to the boot sector of the host's hard drive (if it exists). This means that I'll need to somehow access the PXE APIs without having the system boot from PXE (or at least gain access to the UNDI API). It looks like I need to somehow load the PXE Option ROM manually to acheive, but I have no idea on how to do this?

Please could somebody point me in the right direction, as I desperately want to start experimenting!!!

Thanks in advance, Lee.

I've noticed that gPXE somehow acheives this; I'm looking for a way to access a generic NIC interface from a bootloader without having to worry about the specific NIC that is installed within the machine. Also, if possible, I'd like to do this from Real mode. my aim here is to create a minimalistic self-replicating program, as opposed to a full-blown OS; I'll do what's required to get this working, but code simplicity is preferred.

Thanks again, Lee.

Okay, I think I've made some progress with this, but I'm not sure if it will work until I get home from work tonight to try it out;

After reading the PXE Specification, it looks like I need to use the PXE installation check (Interrupt 0x1A, Function 0x5650) in order to get the segment/offset address of the PXENV+ structure. From this point, I should be able to access the various APIs without having actually booted via PXE, thus allowing me to build a PXE server using these APIs. I'll post back with my progress later on, but if anybody has anything to add in the meantime, please do post! I hope this works, as I'll then have everything I need to build a self-replicating base for my system!!!

Hi,

leejbaxter wrote:In other words, a PXE server would distribute this system to other computers, which would then itself run as a PXE server and redistribute itself! I would use the APIs provided by the PXE client to implement the PXE server.

I'm not too sure how much you already know and how much you don't, so I'm just going to spurt random facts in case something I say is useful..

A computer won't boot from network until/unless it's configured to do so (e.g. in BIOS configuration).

When a computer does boot from network; the first part is handled by DHCP. Normally (for normal DHCP) the computer broadcasts a "who am I" packet to everything on the subnet, and a DHCP server sees this and allocates a "current not in use" IP address from a pool of IP addresses and sends back a "you are <IP address>" reply. If there are 2 or more DHCP servers on the same subnet, then they all allocate (potentially different) IP addresses and everyone (all the DHCP servers, the client, and any routers and other computers that may be listening) get confused and everything breaks (packets flying everywhere and getting lost and choking things up).

Basically; you can only have one DHCP server on a subnet (without causing mayhem). Note: Technically this isn't exactly true - you can only have one "authoritative" DHCP server on a subnet, but may have additional DHCP servers that are not "authoritative" (e.g. just sit there and monitor things and don't reply, possibly as part of some sort of fail-over redundancy scheme). It's best to ignore this as it makes no practical difference and just confuses things.

For network boot it's almost exactly the same as normal DHCP except that the client adds an optional thing on to the end of their "who am I" packet and the DHCP server sees this and adds some extra information to the "you are <IP address>" reply. This extra information is the IP address for a TFTP server and a file name.

Now; you can only have one DHCP server on a subnet (without causing mayhem); so if one computer boots from the network it can not setup it's own additional DHCP server (for other computers to boot from) because that would just break everything and violate the relevant DHCP specification/s. A computer can boot from network and setup its own TFTP server, but the DHCP server won't know anything about it and won't magically start telling other computers to boot from the new TFTP server, so it's mostly pointless.

In addition to all this; if a computer boots from network and actually could replace the existing DHCP server or TFTP server, and provided a copy of itself that the original DHCP and TFTP server would've given out anyway; then it'd still be completely pointless (as the other computers would boot the same boot loader from network regardless of where they got it from).

To summarise everything above:

• It can't work
• If it did work it'd be pointless

leejbaxter wrote:I've noticed that gPXE somehow acheives this

No, they don't. What gPXE does is very different. Basically the computer boots and the DHCP server tells it to download gPXE, then gPXE starts and it wants to download the real boot loader that should've been started to begin with and can't, because (normally) the DHCP server would just tell it download itself (the same file from the same TFTP server as last time). To get around that the assholes ignored the DHCP specification and the established standardization process, and simply hacked non-standard (and mostly retarded/pointless) puss into several open source DHCP servers; so that gPXE can send a non-standard option that should be ignored and the hacked/broken DHCP server will send a different file name.


Cheers,

Brendan

Hi Brendan,

You've made a really good point there about a PXE-booted PXE server basically being redundant. My intention of doing this was to allow the program to continue propagating itself even if the other host computers (as well as the original PXE server) were to cease working (which would naturally happen as part of the evolution process I'm implementing). As I mentioned it's similar to a virus; if a cell infected with a virus were to stop working, the other infected cells would still be able to propogate it.

Allow me to simplify my explanation of what I'm after. I basically want to be able to access the UNDI API (as well as the other PXE API's, if possible) from a bootloader that ISN'T booted via PXE.

Thanks, Lee.

Hi,

leejbaxter wrote:You've made a really good point there about a PXE-booted PXE server basically being redundant. My intention of doing this was to allow the program to continue propagating itself even if the other host computers (as well as the original PXE server) were to cease working (which would naturally happen as part of the evolution process I'm implementing). As I mentioned it's similar to a virus; if a cell infected with a virus were to stop working, the other infected cells would still be able to propogate it.

In that case, you might be able to setup each computer as a non-authoritative DHCP server, such that if/when the current authoritative DHCP server goes offline one of the other computers gets promoted to "authoritative" and continues providing the same service. In this case, whichever computer is acting as the current/authoritative DHCP server would also have its own TFTP server (so that the DHCP server always says a valid TFTP server and not a offline TFTP server). Of course this wouldn't be without problems (e.g. if a cable gets unplugged and your subnet becomes 2 subnets, each with their own DHCP server, then the cable is plugged back in) and you'd have to do a lot of research, etc to solve those problems.

Even after solving the other problems; it probably still wouldn't be 100% bullet-proof. For example, if the current server goes offline after a client has done the DHCP phase but before that client has started the TFTP downloading, then the client will fail despite a new DHCP/TFTP server becoming available.

leejbaxter wrote:Allow me to simplify my explanation of what I'm after. I basically want to be able to access the UNDI API (as well as the other PXE API's, if possible) from a bootloader that ISN'T booted via PXE.

The network card's own ROM is only initialised if the computer is being booted from network, and if the computer boots from hard drive or something else then nothing is setup. This leaves you with 2 choices - implement your own network card driver/s for each different network card; or implement special code for each different chipset to mess with the memory controllers and trick the network card's ROM into thinking you are the BIOS and that the computer will be booting from the network. For these choices, the first (have your own network drivers) would be more work but would also be a lot more reliable - there's too many "corner cases" that can mess up the latter (e.g. some or all of an "onboard" network device's ROM built into the system ROM itself preventing you from finding it).

Of course the first choice doesn't need PXE at all. It's the same as every other OS- e.g. boot from hard drive, setup network card drivers, then start processes (e.g. DHCP and TFTP servers) that use those drivers.


Cheers,

Brendan

leejbaxter wrote:
I basically want to be able to access the UNDI API (as well as the other PXE API's, if possible) from a bootloader that ISN'T booted via PXE.

Thanks, Lee.

Of course, you can use UNDI API from your bootloader, I use it for a long time to connect to the internet in real mode.
But I think that you are a beginner, then it is better to study a little bit before you do these things
However in the specifications of the Intel PXE, it says how to do it

Hi

djmauretto, it seems that you know exactly what I need! I've read through the PXE specification briefly; please could you point me to the section(s) where I should be looking within this document in order to access UNDI? I'm comfortable with assembler language (I'm using NASM for this project), so if you've got any snippets of code it would be greatly appreciated!

Thanks, Lee.

leejbaxter wrote:Hi

djmauretto, it seems that you know exactly what I need! I've read through the PXE specification briefly; please could you point me to the section(s) where I should be looking within this document in order to access UNDI? I'm comfortable with assembler language (I'm using NASM for this project), so if you've got any snippets of code it would be greatly appreciated!

Thanks, Lee.

Section 3.3 "EARLY UNDI API Usage",
PXE spec version 2.1

Learn also about PnP spec 1.0A section 3.0 "OPTION ROM Support"

I will not give you a code That Is ready to use, you have to first evidence That you are well underway with assembly programming, and be able to study the spec

djmauretto wrote:

leejbaxter wrote:Hi

djmauretto, it seems that you know exactly what I need! I've read through the PXE specification briefly; please could you point me to the section(s) where I should be looking within this document in order to access UNDI? I'm comfortable with assembler language (I'm using NASM for this project), so if you've got any snippets of code it would be greatly appreciated!

Thanks, Lee.

Section 3.3 "EARLY UNDI API Usage",
PXE spec version 2.1

Learn also about PnP spec 1.0A section 3.0 "OPTION ROM Support"

I will not give you a code That Is ready to use, you have to first evidence That you are well underway with assembly programming, and be able to study the spec

Brilliant, thanks mate! I had a quick look at that section last night, but wasn't sure if it was the correct way to go about things; I'll attempt to write some code over the next couple of days to implement a basic universal NIC driver.

Thanks again, Lee.

leejbaxter wrote:
Brilliant, thanks mate! I had a quick look at that section last night, but wasn't sure if it was the correct way to go about things; I'll attempt to write some code over the next couple of days to implement a basic universal NIC driver.

Thanks again, Lee.

Ok
anything, I'm available to help you with

djmauretto wrote:

leejbaxter wrote:
Brilliant, thanks mate! I had a quick look at that section last night, but wasn't sure if it was the correct way to go about things; I'll attempt to write some code over the next couple of days to implement a basic universal NIC driver.

Thanks again, Lee.

Ok
anything, I'm available to help you with

Okay, I'm going to be honest; I'm not completely sure on what I've actually got to do to prepare the UNDI API for use. I don't mind if no code is posted; I can work that out myself once I know I've actually got to do to get this thing going once I get to the entry-point of my HDD-based bootstrap loader. I'm not being lazy or anything; it's just that I'm a bit overloaded with information, and I'm a completely clueless when it comes to Option ROMs .etc.

So what do I know? Well, with the programming I've done so far in assembly (NASM), I can write a basic bootloader that can print strings, unsigned-integers (I implemented my own set of functions that can print an unsigned-integer in any base) using interrupt 0x10, and can look into an ISO-9660 file-system to find a stage-2 file to load into memory and run.

What I'm after is a set of steps on how to gain access to a !PXE or PXENV+ structure from a HDD-based bootloader so that I can begin using the various APIs to communicate with other computers. I'm prepared to do any research necessary; I just need to know what to do, then I can research how to do it. For instance, if I need to find a particular option ROM, just let me know and I'll be quite happy in writing code that scans memory and finds the option ROM I'm looking for .etc.

I'm extremely grateful that you've eased my mind by letting me know that it can be done...I just need a for-dummies guide on HOW to do it!

Thanks again, Lee.

OK,
Note that I can guide you step by step, but it is not for beginners as I said at the beginning.
Anyway, the first step is to do a scan to find the option rom:
The Option ROM Header has a signature of 0AA55H .
The ROM scan should be performed from C0000h to EFFFFh on every 2k boundary.
Note that usually at offset C000:0000 there is always Video Option rom.
When you find a Option ROM , you must check for PXEROMID at offset 16H,
if it's not zero then you will find an offset at 'UNDI' structure, you must check for 'UNDI' ascii
signature do the checksum, save the various data, and then load the UNDI DRIVER.
Start to write code to search for Option ROM and post it

djmauretto wrote:OK,
Note that I can guide you step by step, but it is not for beginners as I said at the beginning.
Anyway, the first step is to do a scan to find the option rom:
The Option ROM Header has a signature of 0AA55H .
The ROM scan should be performed from C0000h to EFFFFh on every 2k boundary.
Note that usually at offset C000:0000 there is always Video Option rom.
When you find a Option ROM , you must check for PXEROMID at offset 16H,
if it's not zero then you will find an offset at 'UNDI' structure, you must check for 'UNDI' ascii
signature do the checksum, save the various data, and then load the UNDI DRIVER.
Start to write code to search for Option ROM and post it

Thankyou, that's brilliant! I'll implement this when I get home tonight and post the code!

djmauretto wrote:OK,
Note that I can guide you step by step, but it is not for beginners as I said at the beginning.
Anyway, the first step is to do a scan to find the option rom:
The Option ROM Header has a signature of 0AA55H .
The ROM scan should be performed from C0000h to EFFFFh on every 2k boundary.
Note that usually at offset C000:0000 there is always Video Option rom.
When you find a Option ROM , you must check for PXEROMID at offset 16H,
if it's not zero then you will find an offset at 'UNDI' structure, you must check for 'UNDI' ascii
signature do the checksum, save the various data, and then load the UNDI DRIVER.
Start to write code to search for Option ROM and post it

I'm still writing code as I'm developing utility subroutines .etc. to make everything neat and tidy, but from what you've posted I think I understand how this is going to work...

• Find the next Option ROM which resides somewhere between C000:0000 and E000:FFFF.
• Find the offset of the PXEROMID, which resides at 0x16 (if this is zero, continue on to find the next Option ROM).
• Check that the PXEROMID signature is 'UNDI' and that the checksum works out (if not, continue on to find the next Option ROM).
• Call the UNDI Loader (whose offset is found within the PXEROMID structure) with the required parameter structure to load the UNDI Driver and retrieve the pointers to the PXE! and PXENV+ data structures.

Again, once I get the Option ROM scan code going I'll post it. I'll implement it by first writing a function that finds the first Option ROM within a range of physical addresses. Using this function I'll look at each Option ROM and perform all the checks you mentioned to determine whether it's the UNDI Option ROM.

Just one more question; how does the checksum within the PXEROMID structure work please?

Thanks, Lee.