A boot-sector in an IBM-compatible environment is intended to hold 510
bytes (the last two bytes being a signature for validation) of code and data
sufficient to locate and load the next stage for the boot. For a standard
DOS disk, the code would parse the FAT12 file-system in order to detect
the presence of the files named IBMBIO.COM or IO.SYS, and
IBMDOS.COM or MSDOS.SYS, and then to load IBMBIO.COM or
IO.SYS file (which in turns loads the IBMDOS.COM or MSDOS.SYS
file). There was very little spare space in the boot sector for a detailed error
message if either file could not be located. Non-DOS systems were free to
perform direct disk activity or parse their own file-systems, of course, but
the size limit remained.
Given such a constrained environment, it’s often overlooked as a
target for a function other than booting the system. However, over the
years, two particular groups of people found alternative uses for it. One
group was the virus writer. The other group is the demo maker.
Virus writers created “boot-sector” viruses that activated when the
infected disk was booted, resided in memory, and then infected other floppy
disks as they were inserted into the floppy drive. It was common for bootsector viruses to copy the original boot-sector to another location on the
disk, and then to replace the original code with the virus-specific code.
Early boot-sector viruses would copy the original boot-sector to the end of
the disk, hoping that it was not in use already. This technique was not used
!vfor very long because booting such an infected floppy disk would have a
noticeable delay and unusual sound while the drive arm moved to the end
of the disk and then back again to resume loading.
The replacement technique relied on the fact that regular DOS disks
carry two copies of the File Allocation Table (FAT), one immediately after
the other, and both within the first track of the disk. The first copy of the
FAT is used as the master version. The second is a back-up which can in
some cases enable undeletion of files and repair of certain disk errors.
Virus writers decided that the back-up copy of the FAT would not be used
very often, and claimed the copy as free space. That became the location
for storing the original boot-sector, along with any additional code that the
virus needed as its second stage. Using this location avoided the drive arm
movement during the boot, making the boot seem very similar between an
uninfected disk and an infected one.
As hard disks became more common and larger capacity, they were
often “partitioned” into sections with particular purposes, or to avoid a
limitation of the BIOS disk-capacity description. The partitions could
allow multi-boot systems – one environment per partition. Each of the
partitions carried its own boot sector which knew how to parse the format
of the data in its partition. Virus writers often targeted the hard disk’s
Master Boot Record (MBR) rather than the boot sector of individual
partitions. The MBR is used to select the partition of interest and then to
pass control to that partition’s boot sector to boot the contents of that
partition, so it is the first code that runs, and it is always executed. In
contrast, a partition’s boot-sector might be executed only rarely, or
potentially not at all if the partition shares the same disk format as another
partition which is booted instead. A virus in a MBR could still infect floppy
disk as they were inserted to the floppy drive.
Boot-sector viruses spread freely and widely among pirated disks,
since it was not common for a copied disk to be write-protected. They
survived until floppy drives ceased to be shipped with new PCs. Despite
that, the MBR lives on. As I write this in 2019, the BIOS in IBM-
!vicompatible PCs still carries the code to allow a system to boot from the
MBR.
That leaves the demo maker. For almost as long as there have been
computers, there have been demos (short for demonstration programs) for
computers. As hardware improved in speed and capability, the size of
demos increased as more assets could be manipulated and take advantage
of what was offered. Many demos moved from real-time generation of
objects with tracked music, to essentially videos with pre-generated textures
and MP3 music of multiple-megabytes in size. However, there has always
been smaller groups of demo makers who target older machines or older
environments.
The interest in size-coding has been heightened by demo
competitions. PC 64kb competitions appeared in 1991, followed by Amiga
40kb competitions in 1992, and PC 4kb competitions in 1994. It wasn’t
until 2012 that PC 1kb competitions appeared. 1kb files are still suitable for
Windows environments, or an Amiga boot-block. Sub-1kb competitions are
effectively limited to a .COM file in the DOS environment, which presents
some difficulties to get them to run on modern hardware. Conveniently,
though, the DOS environment is a very close match to the MBR
environment, the primary difference being the initial value of the segment
registers and general-purpose registers. Thus, the MBR is the perfect place
for a small demo which does not require booting DOS.
It might sound easy to target smaller file sizes, since there’s less code
to write, but in fact it can be extremely challenging. The difficulty comes
from the fact that such small programs are still expected to demonstrate
amazing effects, so instead of taking the easy way and carrying huge assets,
these small demos have to rely on coding tricks to generate visual elements
on-the-fly. The smaller the program, the harder it gets.
So what can we do in an MBR? It turns out that it’s both a little and
a lot. When the code in the MBR is executing, there is no operating system
present. It means that there are no corresponding services offered, so we
have no easy access to the GPU or the sound card or high-resolution video
modes. Instead, we have only the most basic hardware support – there are
!viibuilt-in functions to place text and pixels on the screen in various lower
resolution video modes, read low-resolution timers, and read additional
data from the disk (but that would be cheating). We can interact directly
with the hardware, so we have access to high-resolution timers, and we can
operate the speaker. From there, we can draw pictures and play music, so
we can make demos.
In 510 bytes, we can display rotating flat-shaded vector balls, explore
dot-vector landscapes, fly over cityscapes, be hypnotized by raster bars,
zoom into fractals, or experience the illusion of movement created by color
cycling… but wait! That’s not all. We can interact with the user. In short,
we can make games! Not just any games, but good games. We can make
variations of Tetris, Space Invaders, Puck-Man, Robotron, Snake…
All in 510 bytes.
Peter Ferrie
Distinguished Engineer.
Symantec Corp.
July 24, 2019
section .text The .text section is where the executable code resides, such as instructions for the processor to execute. Assemblers and linkers treat this section as the code segment.
This tells the assembler that the following label (in this case, _start) is something that can be accessed by external files, like the linker. It essentially makes the _start label a global symbol.
_labelLabel:
_start is commonly used as the entry point of an assembly program. It’s where the execution begins. By convention, when you create an assembly program, you define this label, and the linker expects it.
nasm เป็นตัวแปลงภาษา assembly (human-readable low-level instructions) into machine code
-f elf32 This specifies the output format of the object file as 32-bit ELF (Executable and Linkable Format). ELF is commonly used on Linux systems.
ex1.asm This is the input file, which contains your assembly code.
-o ex1.o This specifies the output file name as ex1.o, the object file that will be generated
Terminal window
ld-melf_i386ex1.o-oex1
ld: Invokes the linker to combine the object file and any necessary libraries into a single executable file.
-m elf_i386: Specifies the target as 32-bit ELF format (important for 32-bit programs). If you’re on a 64-bit system, this ensures compatibility for running 32-bit code.
ex1.o: The input object file created by NASM during the assembly step.
-o ex1: Specifies the name of the final output executable (ex1).
Terminal window
./ex1
เวลารันโปรแกรมออกมา มันจะไม่ขึ้นอะไรบนจอ
Terminal window
echo$?
คำสั่งนี้จะทำให้รู้ว่า exit status ของคำสั่งล่าสุดคืออะไร จะใช้ใน unix กับ linux
