These days hardware is hidden beneath a thick blanket of Operating System's code. Yet, for me and many other folks, according to Google searches,
a possibility to reach and experiment with hardware would be a very exciting opportunity. I have created an exploratory platform consisting
of two Intel-based computers connected via RS232 interface. One computer, the Master, is running Windows and is used to control the second computer.
The second one, the NakedCPU, runs essentially without any operating system, hence it is available to truly low-level experiments. My platform was
featured on the cover of Circuit Cellar Magazine, issues 259, 260. Current article is an adaptation of the original publication, which is available
on my web site.
It seems that experimentation with a PC is limited to developing high-level code software with the aid of numerous libraries and technologies hiding the hardware beneath layers and layers of code. Rarely limited experimentation with PC hardware is possible, however one has to install drivers allowing some access to hardware, because OS naturally does not permit us to do any low-level activities. The sad part is that such drivers are mysterious themselves. It is safe to say that the hardware programming was well known to many computer professionals and enthusiasts in the 80-s. Later the people forgot about it, while the technology has tremendously leaped ahead. In this article, I try to bridge the gap in time and to revive the interest in hardware programming based on the state of the art technologies and concepts. There is a Russian saying: "Everything new is actually well-forgotten old".
This article is a result of my interest in the Intel CPU, chipset, I/O controller and other essential PC devices from the perspective of low-level hardware programming unobscured by an operating system and drivers. The motivation for this project was to reach out to people with inquisitive minds who would appreciate a possibility to directly experiment with the CPU, chipset and other hardware. Here I present NakedCPU: a facility providing full access to hardware and CPU without any restrictions imposed by the operating system. Importantly, the processor will not be obscured by Linux, DOS or Windows, and it will be operating in its most interesting and powerful regime - the protected mode. In the text, the users are referred as inquirers, because NakedCPU is made for researchers, i.e. devoted geeks, rather than regular users.
The other goal of this article is to provide the inquirers with a roadmap into navigating hardware documentation, which is confusing and difficult to find otherwise. I did not want to retell the documentation, because many computer concepts and technologies quickly become obsolete. With the roadmap, however, it will be easier to follow the newer technologies and documentation.
Let us think for a moment about one of the modern Intel CPU varieties, for instance Intel Core 2 Duo. Impressively, this processor is capable of consuming up to 75A of current [1]! Also, it is not a simple processor: its documentation consists of 5 volumes with the total page count of approx 4200 pages [2]. Intel CPU does not operate alone: it is interfacing a chipset, i.e. a Graphics and Memory Controller Hub (GMCH). The chipset on the other side is connected to an I/O Controller Hub (ICH). Interestingly, this arrangement is analogous to our nervous system with brain, brain stem and a spinal cord. GMCH and ICH are processors themselves, containing hundreds of configuration and control registers. The documentation on GMCH and ICH spans over 1400 pages [3, 4]. No wonder why operating systems hide actual hardware under a thick blanket of intermediate code!
NakedCPU is an experimental platform exposing the hardware internals of a PC. Experimentation with NakedCPU requires two computers (Figure 1). One is the master computer having Windows and Visual Studio software, whose job is interacting with us and the second computer. The second computer, i.e. the NakedCPU, is connected to the master via RS232 interface.The NakedCPU computer is booted up with a small startup code (provided here), which enables it to communicate via RS232 with the master. Upon startup, the NakedCPU is expecting two separate packages of bytes: one is a stream of Intel CPU opcodes to be executed (i.e. the executable) and the other one is the data to be processed. The executable can modify any part of memory, chipset registers, etc, and even overwrite the startup code. In other words, the freedom is yours.
NakedCPU will not be alive without some sort of a startup code. At startup we have to accomplish two tasks: switch the CPU into the Protected Mode and begin listening on the serial port for two packets of bytes: executable and data. In order to supply NakedCPU with a startup code, the easiest way is to prepare a bootable floppy disk with our own code. Certainly, one can also put this code into a hard drive. The startup code (up to 512 bytes) is written in assembly language and must be stored in the sector 0, i.e. the Master Boot Record (MBR) of the disk. It is difficult to use assembly language compilers and linkers such as MASM, since they tailor the executable to a particular OS. There is, however, a binary editor HexIt [5], which among other things allows direct conversion of assembly commands into binary code. Using this editor, a binary file of the future MBR was created. The content of this file can be seen in Appendix. "Anatomy of MBR" provides detailed dissection of the content.
A small utility "Firstsectwrite.exe", see Appendix, was written to transfer this file into sector 0 of the disk. Although the code of this utility is quite simple, it deserves some attention. A Windows API call
CreateFile(TEXT("\\\\.\\A:")...)
opens raw communication with a disk, in this case a floppy drive A, to allow writes into the sector 0. It is important to note, that this call will be only successful under the administrator account.
In this paper, a Dell Optiplex 760 computer was used to conduct the experiments. It had a floppy drive attached via USB and BIOS startup options allowed to boot up the computer from such a drive.
In this paper, a Dell Optiplex 760 computer was used to
conduct the experiments. It had a
floppy drive attached via USB and BIOS startup options allowed to boot up the
computer from such a drive.
It may sound contradictive to the spirit of the article to be OS-free, however NakedCPU is booted up with a tiny (262 bytes long) 32-bit "operating system", NakedOS, which makes the NakedCPU capable of communicating with the outer world via serial port. In fact, we did not compromise our principles of truly free exploration, because NakedOS is absolutely transparent and its code completely presented in the Appendix. NakedOS defines several memory segments (Table 1), which are useful as initial environment for the inquirer's executable. Intel documentation [2] provides explanation for protected mode memory segments, Global Descriptor Table (GDT) and Interrupt Descriptor Table (IDT). In addition, NakedOS defines two software interrupts and a base vector for hardware interrupts. Note: the INT interrupts have nothing to do with DOS or BIOS; they are solely defined by our code.
Immediately after start, NakedOS is expecting two transactions: one for the executable code and another for data. Each transaction is a stream of bytes sent over the RS232 (see Figure 2). The first transaction is written into the memory segment "Target executable", while the second transaction goes into the "Extended memory" segment. After completion of the second transaction, NakedOS transfers control to the executable by a long jump:
jmp 00030:000000000
From that moment, in principle, any memory occupied by NakedOS can be overwritten by activities of the inquirer's executable. The hardware interrupts are normally masked when NakedOS is running; however the 8259 interrupt controller is set up (see additional file
MBRListingNakedOS.doc in the download archive) to handle the interrupts if the inquirer decides to unmask them. Detailed instructions on programming the interrupt controller are provided in the documentation for the I/O Controller Hub (ICH) [4].
The
important issue remains how to send an executable code to NakedCPU to conduct
experiments. Recall the beginning of the
article, where it says that two computers are involved. The master has a Visual C++ project, NakedCPU
Explorer, which acts as a "shell" allowing inspection and modification of
chipset registers and memory. The code
defines a class having a constructor, which provides __asm{} brackets to be
filled up by the inquirer with executable code:
__asm{}
class Ports : public NakedCPUcode
{
public:
Ports()
{
DWORD pe, ps;
__asm
{
mov pe, offset end //save end and start of the code
mov ps, offset start //to be sent to the NakedCPU
jmp end //master jumps over the NakedCPU code
///////////////////////////////////////////
start: mov ax, 0x28 //loading
mov es, ax //data
mov ds, ax //and stack
mov ax, 0x18 //segment registers
mov ss, ax //initializing
mov esp, 0x3fe //stack pointer
xor edi, edi
mov eax, 'OLEH' //NakedCPU Explorer says HELO
stosd
xor esi, esi
mov ecx, 4
INT 0x21
... //here goes rest of the code
_emit 0xEA
_emit 0x00
_emit 0x00
_emit 0x00
_emit 0x00
_emit 0x10
_emit 0x00
end: nop
}
if(!PrepareCode(ps, pe)) delete this;
}
};
Since Microsoft Visual C++ is running on the master PC having an Intel CPU, the compiler will translate the assembly code into appropriate opcodes, which are naturally suitable for the NakedCPU! Specifically, this class is derived from another class, NakedCPUcode, which performs a preparatory work by extracting the opcodes produced from the code in the __asm{} brackets and making them available for sending over to the NakedCPU. Note, NakedCPU only receives the code between "start" and "end" labels. It is important to understand that the master computer will not execute the code in the __asm{} brackets, it simply jumps over it. The strange keyword "_emit" allows placing opcodes directly by their hexadecimal values - for some reason a long jump is not permitted when using Visual Studio compiler.
Any other executable code, besides the NakedCPU Explorer, can be prepared and sent to the NakedCPU computer. Actual sending of the NakedCPU Explorer code is accomplished the following way:
Ports ncd;
SerialComm Com1;
if(!ncd.UploadEx(&Com1))
throw 1;
The project also defines a class SerialComm and a function SendNakedCPUdataRecvResponse to send and receive data. It is worthwhile to examine the straightforward code of the project to understand the details of communication with NakedCPU. Besides serving as an example, NakedCPU Explorer sends an executable to NakedCPU, which permits interactive examination and modification of various chipset and I/O controller registers. NakedCPU Explorer offers eight commands "write", "write32", "read", "read32", "pci", "memread", "memwrite" and "quit". First four commands will ask for a port address, i.e. an address in the CPU I/O space. With these commands, NakedCPU will write to and read from a GMCH or ICH register, one or four bytes. The fifth command will ask for Bus (decimal), Device (decimal), Function (decimal) and Register (hexadecimal) values. The values will be packed into the port 0xCF8 to open a "window" into the PCI configuration space, accessible via port 0xCFC. Details on addressing PCI devices are provided in the chipset documentation [3]. Memread and memwrite allow reading and writing double words from and to the memory respectively.
Note: NakedCPU Explorer does not use any hidden "helper" drivers or libraries. The code is small and entirely transparent for the inquirer's perusal.
The following sections describe experiments with direct access to the hardware and CPU.
Although
it may sound trivial, making a PC speaker to produce sound involves understanding of timers and some low-level work. Ironically, there seems to be
no way to make a speaker beep using Windows API on Vista and XP 64-bit version, because Microsoft decided that the speaker hardware is obsolete [7]. Certainly, in the past, the DOS programmers must have known how to do it, but now it seems to be forgotten. Reading ICH documentation [4] and conducting a few experiments resulted in the following protocol:
Parallel
port is becoming more and more obsolete, nevertheless it offers a possibility
to read and send data over 8 lines. Strangely, ICH documentation does not say
anything about programming a parallel port. Browsing Internet reveals that
there is still some interest with regard to the parallel port and programming
information is available. Connect an LED to the D2 port line via 470 Ohm
resistor and follow the protocol below, which demonstrating writing to and
reading from the parallel port.
Which instruction the processor executes first after power
on? Documentation [2] says that the processor reads its first instruction from
the address 0xFFFFFFF0, i.e. 16 bytes below 4GB. Attempting to examine this
address with a debugger is fruitless (tested, did not work). In order to reach
this high address, which is in the range of high BIOS, a small executable for
the NakedCPU was prepared. The executable defined a segment of memory
addressing high BIOS and sent the content of the 16 bytes below 4GB back to the
master computer. Quite expected, there was a short jump, approximately to 30KB
below. The executable was modified to download the entire chunk of memory 30KB
below 4GB up to the top. Especially curious inquirers are welcome to
investigate the content, which was saved and available for download. As a
general impression, one can see many accesses to PCI bus and calls for CPUID
instruction. It certainly makes sense, because various devices have to be set
up and BIOS is attempting to determine which processor is being used.
Communication via network is accomplished using the Media
Access Controller (MAC). Documentation is available at the Intel web pages. It is also helpful to read first three chapters of the IEEE 802.3-2008 standard
to get an idea of the low-level network lingo as well as the packet format sent
over the wires [8].
Once again
we will use NakedCPU Explorer to investigate the internals of the Media Access
Controller and conduct some experiments. MAC requires data structures in
memory and configuration transactions via I/O address space. First, we must
determine I/O address of MAC, which is called Base Address 2 (BAR2). The
address is stored in the PCI configuration space at bus 0, device 25, function
0 (B0:D25:F0) register 0x18. By the way, there is a confusion in the
documentation referring to the same register. ICH calls this particular
register as MBARC [4], while MAC documentation [6] calls it BAR2. Conduct PCI transactions
with NakedCPU Explorer as follows:
The number
0xECC1 means that the I/O address is actually 0xECC0 with the 0th
bit hardcoded to 1 to indicate that the address is indeed in the I/O space as
opposed to being memory-mapped [6]. The latter indication is important
because all configuration and communication with MAC can also be done using
memory-mapped registers, which is faster, however for our experiments it is
sufficient to use the I/O space, because it is simpler and accomplishes same
results as with memory-mapped operations.
In order
to interact with MAC, the inquirer writes an address of a register within MAC
into the BAR2 I/O address (0xECC0). After that, BAR2+0x4
(0xECC4) becomes a window to the value of that MAC
register. It is important to mention that BAR2 and BAR2+0x4
accept only 32-bit double word read / write operations. MAC registers
have plenty of bits to deal with and some bits are dependent on one another.
It is very difficult understand the settings just by looking at the hexadecimal
value of a register. An Excel worksheet InterpretRegister.xls (available for
download) features a macro that greatly helps in this situation. Specifically,
a table containing bit descriptions should be copy-pasted from the
documentation PDF and a hexadecimal value of a register will be converted into
binary 1s and 0s in appropriate cells right next to the description text, see Figure 4.
Let us
examine control CTRL(0x0) and status STATUS(0x8) registers; the address of the
register is given in parentheses. After power on with network cable unplugged:
This particular bit constellation determines among other
things enabled automatic configuration for speed and full/half duplex.
These bits tell that there is no link established but
initialization is completed.
After
connecting the master computer with the NakedCPU, CTRL register stays the same
as expected, while the status register changes to 0x80080683. The new value means full duplex
communication, established link and 1Gbps speed. The master computer running
Windows XP reported the same communication parameters, which indicates that the
NakedCPU network interface was able to negotiate with the master computer's
interface on the hardware level.
In this section, we will experiment with reading network
packets originated from the master computer. It was found that when master
computer detected live NakedCPU via the network cable, Windows began generating
DHCP requests. These requests are attempts to obtain an IP address and other
high-level network settings, because Windows assumes (erroneously) that the
NakedCPU is a router or a network server. Although Windows is mistaken, this
is perfectly fine for our experiments, because we can catch these packets and
examine them.
MAC uses
direct memory access to store the received data. We have to create several
descriptors, which will tell MAC where to write the data. Thus, two memory
ranges are required: one for the descriptors and the other for packets.
Referring to Table 1, one can see that there is an area of memory above the
address 0x100000 available for inquirer's data. Bearing in mind that NakedCPU
Explorer uses a tiny bit of that memory to store incoming commands, we can
safely use addresses above 0x100500. It is sufficient to create two
descriptors for the initial experiments. A descriptor is a data structure of
four double words (16 bytes). The first two double words are 64-bit physical
address of the location where the packet is to be stored. With the ability of the
NakedCPU Explorer to write into memory locations, let us create the descriptors
at the address 0x100500, pointing to two 512-byte long buffers located at the
addresses 0x101000 and 0x101200. A collection of descriptors is called
"queue". After MAC finishes with storing packets, it will update the
descriptors to indicate received packet size, errors and several other
parameters.
The command "memwrite" asks for the address and the number
of double words to be written. Note, writing below 0x100000 will cause
general protection fault and reboot of the NakedCPU.
MAC has to
know the location of the descriptors, the size of the receive buffers and the
type of packets to receive. This information has to be stored in several MAC
registers. RDBAL0(0x2800) and RDBAH0(0x2804) - low and high portions
respectively of a 64-bit physical address of the base of the queue. RDLEN0(0x2808)
- length of the memory buffer allocated for the queue. RDH0(0x2810) and RDT0(0x2818)
- head and tail pointers respectively. RFCTL(0x5008) - receive filter control register.
RXCSUM(0x5000) - receive checksum control register. Before setting up these
registers, a bit 26 of the CTRL(0) register has to be set to 1, which will
cause MAC reset. After setting up all registers, data reception is initiated
by writing into RCTL(0x100) to set up the "enable" bit, the size or the receive
buffers reception mode and type of the descriptors.
For the CTRL, RCTL,
RFCTL and RXCSUM registers, the worksheet InterpretRegister.xls shows values
(and bit states) that are going to be used in our experiments. The meaning of
value for the RDLEN is somewhat confusing. According to the documentation, the
length of the queue buffer must be a multiple of 128, which means at least
eight descriptors (128 / 16) must be in the queue. We have only two
descriptors, however. I have determined experimentally that it is not a
problem to tell MAC that the queue buffer is larger than it needs to be, as
long as the RDT0 register is pointing to the end of the actual queue. Hence,
for our particular experiment we must set RDLEN = 0x80, RDT0 = 0x2.
Before receiving the packet by NakedCPU, the Master
computer should not be sending DHCP packets. To suppress the DHCP packets
originating from the Master computer, the following should be entered in the
Windows command-line tool under the Administrator account:
ipconfig /release
Next, copy and paste columns of the Table 2 into the NakedCPU Explorer in the order I - V. Note that at the end of the 4th
step, MAC is ready for enabling reception. That step ends up in reading from
the status register, which should result in a value 0x80683. This value is
similar to the one previously described (0x80080683, page 8) with the difference that the bit 31 is cleared, which indicates that the DMA clock
cannot be lowered to Â¼ of its value. The reason why MAC changed its "mind"
concerning the DMA clock is not known, but this is not relevant for our
experiments.
To initiate
the Master sending packets, type the following in the command-line window under
the Administrator account:
ipconfig /renew
After reading
from the network, MAC updates the two descriptors. With the memread command observe the new values by reading 8
double words beginning from the address 0x100500. You will see that the
descriptor's address field is changed and two additional values appeared. Figure 5 shows the new values that my computer produced. Detailed information about
the fields is provided in the MAC documentation [6]. Briefly, the lengths of the
packets are 342 bytes (0x156); no errors occurred, the descriptors are
indicated as "done" and the entire packet was able fit to the buffer
(0x20073).
MAC stored the actual two packets at the addresses
0x101000 and 0x101200 respectively; their contents are present in InterpretRegister.xls,
"Packets" worksheet. Figure 6 shows the beginning of the stored data array and
the order of transmission. The first six bytes marked red are the destination
(broadcast) address, which are followed by the source addresses and the
two-byte length / type field. The latter field is transmitted with most
significant byte first [8], which makes it to be 0x0800. If the value of the
length / type field is less or equal to 0x05DC, then it indicates the length of
the packet, otherwise its type (Ethertype). Web pages at standards.ieee.org in
theory provide specific Ethertype values, however it is virtually impossible to
find the actual list of values. Luckily, Wikipedia points to an exact URL in
the innards of the ieee.org site [9]. According to the standard, Internet
Protocol (IP) is designated with the Ethertype 0x0800. Apparently, next step
is to investigate the format of the Internet Protocol, which is described in
RFC894, which points to RFC791 [10].
The fields of the IP header are transmitted in a similar
way as the previously described length / type field, i.e. most significant bit
and the most significant byte first. In contrast to the intuitive notation,
where bit 0 is the least significant bit, RFC791 provides the opposite, with
bit 0 to be the most significant bit. Table 3 shows continuation of the
received packet and the assignment of its specific values to the fields of the first
32-bits of the IP header. Important fields are IHL and Total Length. IHL
indicates the number of 32-bit words in the header. In our case it is 5, which
means that according to RFC791 Options and Padding fields are omitted. It is
interesting to note that MAC reported receiving 342 bytes and the IP header
indicated 328 (0x0148) bytes. The difference of 14 bytes makes perfect sense,
because they make up to two bytes of the length / type field plus 2*6 bytes of
destination and source hardware addresses.
All other
fields of the IP header are easy to map following this example. Specifically,
the field values are: Identification - 0x0fe8 (packet 1), 0x0fe9 (packet 2);
Flags and Fragment Offset - 0; Time to Live - 0x80; protocol - 0x11; Header
Checksum - 0x29be (packet 1), 0x29bd (packet 2); Source IP address - 0.0.0.0;
Destination IP address - 255.255.255.255. It is understandable, that the master
PC is asking for an IP address while doing the dynamic host configuration
process, therefore the source IP address is all zeroes. For the destination,
the address is all 255.255.255.255, which is a broadcast address, similar to
the hardware broadcast address (6 bytes, all 255).
The value for
the protocol field is 0x11 (17); according to RFC790 it refers to the User
Datagram protocol (UDP) - the next level of data encapsulation - which is
described in RFC768. According to that document, a UDP header contains four
16-bit words. In the order of transmission, these words are source port,
destination port, length and checksum. The values received by NakedCPU in my
experiment were source port - 0x0044, destination port - 0x0043, length -
0x0134, checksum - 0x5c1a (packet 1) and 0x581a (packet 2). The length of 308
(0x134) bytes makes sense, since IP header reported the total datagram length
of 328 bytes minus 20 bytes occupied by the IP header. The source and
destination port numbers should have been explained in RFC790, however it
turned out that a long chain of other documents obsolete this one. At the end
of the chain, it is suggested to look at the website of the Internet Assigned
Numbers Authority (IANA), where, unfortunately, the information is not well
organized. It was possible, however to find among the obsolete RFCs that port
numbers 67 (0x43) and 68 (0x44) correspond to the Bootstrap Protocol, server
and client ports respectively. The Bootstrap Protocol is described in RFC1542
that points out to the DHCP protocol, see RFC2131. A summary of all fields
discussed in this section is provided in Figure 7.
It is possible to directly experiment with Intel CPU and
other PC hardware without any layers of unknown intermediate code that is
intended to make our life "easier". As of yet, the most comprehensive
documentation exists for the processor itself [2]. The other hardware is not
well documented, which is why it takes a significant amount of efforts to
gather pieces of information from the Internet and conduct experiments
directly. The old books that dealt with hardware are DOS oriented and
seriously obsolete. The new hardware is hidden behind layers of unknown code.
In theory, the NakedCPU platform enables developers to
create task-specific applications using only needed components. For instance,
if we are talking about a large-scale database, there is no need to support
GUI, USB plug and play, audio cards, .NET and many other things. An additional
bonus to the NakedCPU platform is immunity to viruses. Like in biology, where
flexible viruses attack well-evolved organisms, the computer viruses attack
well developed operating systems. With the NakedCPU, on the other hand, a
particular task-specific solution can be very unique; hence the virus-creators
will simply have not enough information to explore potential security holes.
The original publication is available on my web site. Click the images:
Address Opcode Mnemonic
00000000 EB3C jmp short 00000003E
.............some remnants from FAT...............................
0000003E FA cli
0000003F 33C0 xor ax,ax
00000041 8ED0 mov ss,ax
00000043 BC007C mov sp,07C00
00000046 16 push ss
00000047 07 pop es
00000048 0E push cs
00000049 1F pop ds
0000004A E80000 call 00000004D
0000004D 89E5 mov bp,sp
0000004F 8B5E00 mov bx,[bp+000]
00000052 0F01976D01 lgdt q.[bx+0016D]
00000057 89DE mov si,bx
00000059 81C67301 add si,0173
0000005D B94000 mov cx,040
00000060 31FF xor di,di
00000062 FC cld
00000063 F3 repe
00000064 A4 movsb
00000065 BF0008 mov di,0800
00000068 89DE mov si,bx
0000006A 83C633 add si,033
0000006D B93B01 mov cx,013B
00000070 F3 repe
00000071 A4 movsb
00000072 0F01E0 smsw ax
00000075 0D0100 or ax,01
00000078 0F01F0 lmsw ax
0000007B EA00001000 jmp 00010:00000
-----from here 32-bit code segment ------------------------------
00000080 66B81800 mov ax,018
00000084 8ED0 mov ss,ax
00000086 BCFE030000 mov esp,03FE
0000008B 66B80800 mov ax,08
0000008F 8EC0 mov es,ax
00000091 E492 in al,092
00000093 0C02 or al,02
00000095 E692 out 092,al
00000097 66BAFB03 mov dx,03FB
0000009B B083 mov al,083
0000009D EE out dx,al
0000009E 66BAF803 mov dx,03F8
000000A2 66B80600 mov ax,06
000000A6 66EF out dx,ax
000000A8 66BAFB03 mov dx,03FB
000000AC B003 mov al,03
000000AE EE out dx,al
000000AF 31C0 xor eax,eax
000000B1 BF00020000 mov edi,0200
000000B6 B900020000 mov ecx,0200
000000BB F3 repe
000000BC AA stosb
000000BD BF00030000 mov edi,0300
000000C2 BE14010000 mov esi,0114
000000C7 0E push cs
000000C8 1F pop ds
000000C9 0F011E lidt q.[esi]
000000CC 83C606 add esi,06
000000CF B904000000 mov ecx,04
000000D4 F3 repe
000000D5 A5 movsd
000000D6 66B83800 mov ax,038
000000DA 8EC0 mov es,ax
000000DC 8ED8 mov ds,ax
000000DE 31FF xor edi,edi
000000E0 CD20 int 020
000000E2 66B82800 mov ax,028
000000E6 8EC0 mov es,ax
000000E8 8ED8 mov ds,ax
000000EA 31FF xor edi,edi
000000EC CD20 int 020
000000EE 6631C0 xor ax,ax
000000F1 8EC0 mov es,ax
000000F3 8ED8 mov ds,ax
000000F5 66BA2000 mov dx,020
000000F9 B011 mov al,011 //ICW1
000000FB EE out dx,al
000000FC B028 mov al,028 //ICW2
000000FE 42 inc edx //IRQ0 base addr 0x28
000000FF EE out dx,al
00000100 B004 mov al,04 //ICW3: Slave
00000102 EE out dx,al //connected to pin 2
00000103 B001 mov al,01 //ICW4
00000105 EE out dx,al
00000106 EA000000003000 jmp 00030:000000000
.............random bytes......................................
00000140 66BAFD03 mov dx,03FD
00000144 EC in al,dx
00000145 A801 test al,01
00000147 74FB jz short 000000144
00000149 66BAF803 mov dx,03F8
0000014D EC in al,dx
0000014E AA stosb
0000014F 50 push eax
00000150 66BAFD03 mov dx,03FD
00000154 EC in al,dx
00000155 A820 test al,020
00000157 74FB jz short 000000154
00000159 58 pop eax
0000015A 66BAF803 mov dx,03F8
0000015E EE out dx,al
0000015F C3 ret
00000160 57 push edi
00000161 B904000000 mov ecx,04
00000166 E8D5FFFFFF call 000000140
0000016B E2F9 loop 000000166
0000016D 5F pop edi
0000016E 8B0F mov ecx,[edi]
00000170 85C9 test ecx,ecx
00000172 7409 jz short 00000017D
00000174 51 push ecx
00000175 E8C6FFFFFF call 000000140
0000017A E2F9 loop 000000175
0000017C 59 pop ecx
0000017D CF iretd
0000017E AC lodsb
0000017F E8CBFFFFFF call 00000014F
00000184 E2F8 loop 00000017E
00000186 CF iretd
.............random bytes.........................................
00000194 FF01
00000196 0002
00000198 0000
0000019A E000
0000019C 1000
0000019E 008E0000
000001A2 FE00
000001A4 1000
000001A6 008E0000
000001AA 0000
000001AC 0000
000001AE 0000
000001B0 0000
000001B2 0000
000001B4 0000
000001B6 0000
000001B8 0000
000001BA FF01
000001BC 0000
000001BE 0000
000001C0 0000
000001C2 0000
000001C4 0000
000001C6 0000
000001C8 FF03
000001CA 0000
000001CC 00920000
000001D0 0A13
000001D2 0008
000001D4 009A4000
000001D8 FF03
000001DA 0004
000001DC 00924000
000001E0 FF0F
000001E2 00800B92
000001E6 0000
000001E8 007800
000001EB 0010
000001ED 92
000001EE 8000FF
000001F1 FF3B
000001F3 0900
000001F5 98
000001F6 40
000001F7 00FF
000001F9 FF3B
000001FB 0900
000001FD 92
000001FE 0000
#include "stdafx.h"
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
TCHAR destDisk[] = TEXT("\\\\.\\X:");
cerr << "\n firstsectwrite.exe E: nakedos_x_y.bin";
if (argc != 3)
{
cerr << "\nInput parameters error";
return -1;
}
if(_tcslen(argv[1]) != 2)
{
cerr << "\nInput parameters error";
return -1;
}
_tcscpy(&destDisk[4], argv[1]);
HANDLE hD=CreateFile(destDisk,GENERIC_WRITE, FILE_SHARE_WRITE, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING, NULL);
HANDLE hS=CreateFile(argv[2],GENERIC_READ, NULL, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if((INVALID_HANDLE_VALUE == hS) || (INVALID_HANDLE_VALUE == hD))
{
cerr << "error";
return -1;
}
BYTE buf[512];
BYTE bufproof[512];
DWORD dwCopied;
ReadFile(hS, buf, 512, &dwCopied, NULL);
WriteFile(hD, buf, 512, &dwCopied, NULL);
CloseHandle(hD);
CloseHandle(hS);
hD=CreateFile(destDisk,GENERIC_READ, FILE_SHARE_WRITE, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING, NULL);
if(INVALID_HANDLE_VALUE == hD)
{
cerr << "error";
return -1;
}
ReadFile(hD, bufproof, 512, &dwCopied, NULL);
if(!equal(buf, buf + 512, bufproof))
{
cerr << "write error";
return -1;
}
return.