RAID has been around for decades, but it is still one of the most practical storage design decisions you will make in real infrastructure. Whether you are planning a small application server, a NAS, a database box, or a virtualization host running multiple VMs, the RAID level you choose directly affects:

• performance

• usable storage capacity

• fault tolerance

• rebuild risk

• operational downtime

The basic textbook definition is simple: RAID combines multiple disks into a single logical unit to improve speed, resilience, or both. But in real systems, the right answer is not “use the safest RAID.” The right answer is match the RAID level to the workload.

What RAID actually does

At a high level, RAID distributes data across multiple drives using one or more of these techniques:

• Striping: data is spread across disks to improve performance

• Mirroring: the same data is written to more than one disk for redundancy

• Parity: extra calculated information is stored so lost data can be rebuilt after a disk failure

That sounds abstract, so think of it this way:

• RAID 0 = speed first

• RAID 1 = safety through duplication (entire mirring)

• RAID 5 / 6 = balance of capacity and protection using parity

• RAID 10 = striping + mirroring for strong performance and resilience

RAID is not the same as backup

This is one of the most common mistakes in infrastructure planning.

RAID helps you stay online when a disk fails. It does not protect you from:

• accidental deletion

• file corruption

• ransomware

• bad application writes

• VM snapshot mistakes

• site-level failure

• controller failure in some scenarios

• human error

The four things that matter when evaluating RAID

Before looking at individual RAID levels, evaluate them through these four lenses.

1. Reliability

How many disk failures can the array tolerate before data is lost?

2. Performance

How well does it handle:

• sequential reads and writes

• random reads and writes

• mixed workloads

• rebuild activity

3. Capacity

How much of the raw disk space is usable after redundancy overhead?

4. Recovery behavior

How painful is the rebuild after a failed drive? Large arrays with parity can remain online, but rebuild times may be long and performance may drop sharply during recovery.

RAID levels in plain English

RAID 0 — Maximum speed, zero protection

How it works: data is striped across multiple disks with no mirror and no parity.

Strengths

• highest raw performance

• full usable capacity

• simple design

Weaknesses

• one failed disk can destroy the whole array

• not suitable for critical systems

Good fit

• temporary scratch storage

• cache or render workspace

• non-critical high-speed data

Bad fit

• production databases

• important application data

• VM hosts

RAID 1 — Simple mirroring

How it works: every block is duplicated to another disk.

Strengths

• easy to understand and manage

• very fast recovery after failure

• strong protection for small deployments

• often good for boot volumes and small critical servers

Weaknesses

• only 50% usable capacity

• write performance is not the main advantage

• storage cost is high per usable TB

Good fit

• OS volumes

• small business servers

• log servers

• low-complexity critical data

RAID 5 — Capacity-efficient parity

How it works: data is striped across disks and parity is distributed among them. The array can survive one disk failure.

Strengths

• good balance of capacity and resilience

• better capacity efficiency than RAID 1 or RAID 10

• common in general-purpose storage

Weaknesses

• parity calculations slow writes

• rebuilds can be stressful on large arrays

• performance may drop badly during degraded mode

• a second failure during rebuild can be catastrophic

Good fit

• read-heavy workloads

• file storage

• environments where capacity matters more than write latency

Use carefully for

• general VM workloads

• mixed application stacks

• larger disks where rebuild windows are long

RAID 6 — Safer parity for larger arrays

How it works: similar to RAID 5, but stores double distributed parity and can survive two disk failures.

Strengths

• stronger protection than RAID 5

• useful for larger disk pools

• better choice when rebuild risk is a concern

Weaknesses

• more parity overhead than RAID 5

• slower writes than RAID 5 and RAID 10

• usable capacity is reduced further

Good fit

• large-capacity storage arrays

• backup repositories

• archive and file-serving systems

• environments where availability matters more than peak write speed

RAID 10 — The practical favorite for performance-sensitive systems

How it works: mirrored pairs are created first, then data is striped across those pairs.

Strengths

• excellent random read and write performance

• strong fit for database and transactional workloads

• faster rebuild behavior than parity-heavy arrays

• widely preferred for virtualization and latency-sensitive workloads

Weaknesses

• 50% capacity overhead

• more expensive than RAID 5 or 6

• requires at least 4 disks

Good fit

• databases

• high-write applications

• busy VM hosts

• mixed production infrastructure

RAID comparison table

Why RAID decisions matter even more for VM hosts

This is the part many introductory articles skip.

A physical server usually runs one operating system and one main workload. A virtualization host is different. It stacks many workloads on the same storage backend:

• web servers

• databases

• file servers

• application servers

• monitoring tools

• backup proxies

• domain controllers

That means one storage issue can affect many VMs at once.

What changes when you run VMs?

1. Random I/O becomes more important

Even if each guest is small, many VMs together create a noisy mixed workload. Random reads and writes, bursty writes, metadata activity, guest paging, and application logs all pile onto the same datastore.

That is why a RAID level that looks “fine on paper” may feel slow in a VM host.

2. Latency matters more than headline throughput

For virtualization, low latency often matters more than peak MB/s. A parity-based array might have enough raw bandwidth, but still feel sluggish under write-heavy or mixed I/O.

3. Rebuild periods are more painful

When a parity array rebuilds, the whole storage pool stays busy. On a virtualization host, that means many VMs can experience degraded performance at the same time.

4. Snapshots and dynamic growth add overhead

Snapshots, differencing disks, and dynamically growing virtual disks can increase metadata work and I/O overhead. In busy hosts, these layers magnify storage bottlenecks.

Practical RAID guidance for VM environments

RAID 10 is usually the safest performance choice

If your host runs:

• databases

• ERP or CRM systems

• application servers

• mixed business VMs / NMS

• write-heavy workloads

then RAID 10 is usually the cleanest answer. It trades capacity for lower write penalty, better random I/O, and simpler rebuild behavior.

RAID 5 can work, but know the trade-off

RAID 5 may still be acceptable when:

• the environment is small

• workloads are mostly read-heavy

• capacity budget matters more than peak write performance

• controller cache and SSD performance are strong

But it is often not the first choice for busy, multi-VM production hosts.

RAID 6 is stronger for bigger pools

If you are working with larger capacity drives or bigger arrays and want better protection during rebuilds, RAID 6 is safer than RAID 5. The trade-off is heavier write overhead.

RAID 1 is fine for small hosts or boot volumes

A small two-disk mirror can still be perfectly reasonable for:

• hypervisor boot drives

• labs

• edge systems

• lightweight branch deployments

RAID 0 should not be used for production VM datastores

The performance looks attractive, but the blast radius is too high. One disk failure can take down every VM on that datastore.

VM-specific best practices beyond RAID level

The RAID level is only one part of the answer. For VM infrastructure, also pay attention to the storage stack above it.

Use the right virtual disk/controller format

For Hyper-V environments, Microsoft recommends:

• SCSI for non-OS disks

• VHDX instead of VHD on modern deployments

• fixed VHDX when you need the best resiliency and performance

Keep snapshot chains short

Long snapshot or differencing chains add lookup overhead and can hurt performance, especially for I/O-intensive VMs.

Use storage QoS where available

In shared environments, one “noisy neighbor” VM can consume disproportionate I/O. Storage QoS helps isolate workloads and preserve consistency.

Watch alignment, sector size and block sizing

Poor alignment or mismatched sector assumptions can quietly damage storage performance. This is especially important in virtual disk layers.

Separate workload tiers when possible

If budget allows, separate:

• boot volumes

• production VM datastores

• backup targets

• archive workloads

Not every workload needs the same RAID level.

Recommended RAID choices by use case

A simple decision framework

If you are unsure, use this logic:

Choose RAID 10 when:

• performance matters

• workloads are mixed or write-heavy

• VMs are important

• rebuild risk needs to be minimized

Choose RAID 5 when:

• capacity efficiency matters

• workloads are more read-heavy

• the environment is not extremely latency-sensitive

Choose RAID 6 when:

• disks are large

• rebuild risk worries you

• the array stores important bulk data

• you can tolerate slower writes

Choose RAID 1 when:

• simplicity matters

• the setup is small

• you need a reliable mirror

Avoid RAID 0 when:

• the data matters at all

Final takeaway

RAID is not just a storage chapter from a DBMS textbook. It is a live infrastructure decision that affects reliability, performance, and recovery behavior.

For modern systems, the best RAID choice depends on the workload:

• RAID 0 for speed-only temporary data

• RAID 1 for simple redundancy

• RAID 5 for balanced capacity in lighter workloads

• RAID 6 for larger, safer parity arrays

• RAID 10 for performance-sensitive and VM-heavy production systems

If your environment runs multiple virtual machines, do not judge RAID only by raw capacity. Judge it by latency, rebuild behavior, and the number of workloads sharing the same backend.

That is usually where the real answer becomes clear.

References

• VMware: vSphere 9.0 Performance Best Practices

• Microsoft Learn: Hyper-V storage I/O performance

To set up Jenkins, ensure the installation of the GitLab and NodeJS plugins. This article simplifies the automation process by utilizing basic shell commands for running tests and deploying applications to production.

Configuring Gitlab and Jenkins

Jenkins: Access Rights to GitLab

To integrate GitLab with Jenkins, it's necessary to create an access token in GitLab. This can be achieved by User menu > Settings > Access tokens

To set up the connection between Jenkins and GitLab, configure GitLab in Jenkins by adding the recently generated token. In Jenkins, navigate to Manage Jenkins > Configure system. Find the GitLab section in the configuration settings.

To include a previously generated token, click on "Add" in the Credentials input and select Jenkins. Within the credentials dialogue box, opt for GitLab API token from the Kind input, and paste the token obtained from GitLab into the API token input field.

Jenkins: Configure NodeJSInstaller

To enable the execution of npm scripts, it's essential to set up NodeJSInstaller. Navigate to Manage Jenkins > Global Tool Configuration > NodeJS installations.

Jenkins: Create CI build for Angular

To facilitate the execution of Angular tests and code style checks in Jenkins for the created merge request in GitLab, follow these steps:

1. Select the New item link on the Jenkins dashboard.

2. Provide a name for the job and opt for a Freestyle project.

   

3. Select the GitLab Connection recently established from the GitLab Connection segment.

   

4. Choose Git as your source code management. Enter your repository URL. Create new credentials on Jenkins. These credentials are for cloning the project. You use them to log in to Gitlab.

   

5. Subsequently, set up build triggers to specify the GitLab event that should initiate a build. In this specific instance, the angular-ci-build will be activated upon the creation of a new merge request.

   

   In this step, return to GitLab and establish a hook that will initiate this build by navigating to Settings > Integrations. Copy the URL supplied by Jenkins, insert it into the project hook form, and conclude by clicking on "Add webhook."

   

6. Specify the configured NodeJsInstaller in the global settings to enable the execution of npm commands.

   

7. Lastly, within the Build section, opt for "Add build step" and then select "Execute shell." Craft shell scripts to assess the code of the Angular app and execute tests.

   

Click Save, and the setup should be complete. At this stage, everything should function as intended.

Upon initiating a new merge request, GitLab is expected to activate angular-ci-build on Jenkins, and on the respective merge request page, you should observe a pending status.

Once Jenkins completes its process, the status on GitLab will be automatically updated. The color of the merge button will vary based on whether the build was successful or not.

Jenkins: Create CD Build for Angular

To enable the deployment of Angular to another Linux machine, follow these steps:

Opt for a distinct configuration for deployment. This build will be triggered upon the acceptance of a merge request.

Similar to the process for the CI build, establish a new GitLab hook that will invoke the Jenkins build endpoint.

This step mirrors the procedure in CI; we must specify the globally configured NodeJSInstaller.

In this step, there's a divergence from CI; this time, there's no need to conduct testing and linting checks. The focus is solely on building the application and transferring it to another machine using SSH.

To facilitate the SSH process, as illustrated in the example, it's imperative to generate a private and public key pair for the Jenkins user on the machine where Jenkins is operational. Retain the private key on the Jenkins machine, and transfer the public key to the remote machine.

Utilizing the SCP command, copy the build to the remote machine. However, it's noteworthy that Jenkins is restricted to placing it only in the user folder. In the final step, access the remote machine via SSH and relocate the files. (In this case to /var/www/html)

Voila, the application is deployed to the production server when the merge request is accepted through Jenkins.

Angular: Karma Unit Test Runner Configuration

To execute Angular tests on Jenkins, specific sections of the karma.conf file needs configuration. The following is the setup that introduces a customized launcher for running ChromeHeadless.

module.exports = function(config) {
  config.set({
    basePath: "",
    frameworks: ["jasmine", "@angular-devkit/build-angular"],
    plugins: [
      require("karma-jasmine"),
      require("karma-chrome-launcher"),
      require("karma-jasmine-html-reporter"),
      require("karma-coverage-istanbul-reporter"),
      require("@angular-devkit/build-angular/plugins/karma")
    ],
    client: {
      clearContext: false // leave Jasmine Spec Runner output visible in browser
    },
    coverageIstanbulReporter: {
      dir: require("path").join(__dirname, "../coverage/jenkins-test-app"),
      reports: ["html", "lcovonly", "text-summary"],
      fixWebpackSourcePaths: true
    },
    reporters: ["progress", "kjhtml"],
    port: 9876,
    colors: true,
    logLevel: config.LOG_INFO,
    autoWatch: true,
    browsers: ["Chrome", "ChromeHeadless"],
    singleRun: false,
    restartOnFileChange: true,
    customLaunchers: {
      ChromeHeadless: {
        base: "Chrome",
        flags: [
          "--headless",
          "--disable-gpu",
          "--no-sandbox",
          "--remote-debugging-port=9222"
        ],

      },
    }
  });
};

We can straightforwardly save our command in the package.json scripts section.

On Jenkins, we would execute our tests using the command npm run test:ci.

"scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "test:ci": "ng test --browsers=ChromeHeadless --watch=false",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

I hope you found pleasure in exploring this article and that it served as a useful resource in your efforts to automate Angular deployment and testing.

The idea of a program that replicates itself may have originated in the early days of computing, when programmers amused themselves by trying to write the shortest program that prints itself. In today’s world every organizations and individuals using computer and internet need to have a wide-ranging virus protection policy to combat the growing threats of computer viruses by means of anti-virus. This is due to the fact that a computer virus may corrupt or delete data on a computer. Computer viruses also spread by using downloads on the Internet. Computer viruses can be hidden in pirated software or in other files or programs that you may download. Boot sector viruses take advantage of the boot process of personal computers (PCs). Because most computers do not contain an operating system (OS) in their read-only memory (ROM), they need to load the system from somewhere else, such as from a disk or from the network (via a network adapter).

Keywords: BSV (Boot Sector Virus), FAT(File Allocation Table), OS(Operating System), WOS(Windows Operating System), MBR(Master Boot Record), Bootstrap Loader, RC(Recovery Console), BSOD(Blue Screen of Death), PBS(Partition Boot Sector).

INTRODUCTION

A biological virus (from the Latin for poison) is a shell filled with genetic material that it injects into a living cell, thereby infecting it. The cell then starts manufacturing copies of the virus. A computer virus behaves similarly. A computer virus is a malware, when executed, try to replicate itself into other executable code; when it succeeds, the code is said to be infected. The infected code, when run, can infect new code in turn. The self-replication into existing executable code is the key defining characteristic of virus. So it is the program that can copy itself and infects a computer without permission or knowledge of the user. In this paper we have discussed only about a special type of virus known as the BOOT SECTOR Virus. Before going in depth, the working definition of virus should be as under:

1. It is capable of propagating between computers on a network. This is the most important attribute of a computer virus and it is what distinguishes a virus from other types of malicious software.

2. It installs itself in a host computer without the owner’s knowledge or consent.

3. It has the potential to damage software on the host by altering or deleting files.

4. It can prevent legitimate users from using some or all of the computer’s resources.

5. In general it embeds itself in an executable file (its host), such that when the file is executed, the virus is also executed. The virus is hidden inside the host.

Boot Sector Viruses

A boot sector virus (BSV) is a computer virus that resides in the boot sector of a disk. Each time the disk is mounted, the boot sector is read and executed, causing the virus to be executed. The boot sector of a disk is normally the first sector of the disk, as its format depends on the operating system. Often, the boot sector occupies more than one disk sector. It may also include a table with information about the disk itself (such as maker, date of manufacture, model and serial numbers, size and number of tracks) and on the various partitions of the disk. The directory of a disk reflects the file structure of the disk and provides the user with all the information that’s normally needed about the files. However, in addition to the files listed in the directory, there is at least one program that’s not listed there. It resides in the boot sector of the disk and this is the program executed each time the disk is mounted and is responsible for OS Loading further.

Boot Sector Loader

A computer operates by executing a program. A computer without a program can do nothing. This implies that a newly-bought computer must have a program built into it. This program is called the bootstrap loader and is stored in read-only memory (ROM), which is nonvolatile (it keeps its content when the power is turned off). Each time the computer is booted (started or restarted), it executes the bootstrap loader. This short program reads the first part (the kernel) of the operating system from a disk or a CD and starts it. The kernel then reads the remainder of the operating system and stores it in memory.

The point is that the bootstrap loader is stored in ROM and is difficult and time consuming to replace. It should therefore be general and be able to load any version of any operating system—past, present, and future—from any bootable device. Currently, PCs run Windows or Linux OSs and each of these goes through newer versions all the time. Another complication arises because a bootable volume may be divided into several partitions, each of which may have a different operating system. Thus, the bootstrap loader should not be limited to loading just one type or one version of the operating system. The bootstrap loader starts by looking for a bootable volume (disk or CD) and it follows simple rules to determine which bootable volume to select when it finds more than one. The bootstrap loader then reads the volume’s master boot sector, loads it in memory, and executes a jump instruction to its beginning of boot sector. The boot sector contains a short program called the master boot record (MBR). This program knows about the various partitions of the volume and how to read the boot sector of each. It locates all the operating systems in the various partitions of the volume and lists them for the user to select one. Once a specific operating system has been selected on partition P, the MBR reads the partition boot sector (PBS) of P and executes it. The short program of the PBS reads and loads the kernel of the operating system, and it loads the rest.

The best place for a virus is in the bootstrap loader; because this program is the very first one to execute but it is difficult since this loader is made in a factory and its content is permanent (modern bootstrap loaders have firmware and can be modified when new versions of the operating system are released). The next best place for a virus is the MBR or one of the PBSs. A virus that’s hidden in these locations is called a boot sector infector or BSI. The precise organization of a disk depends on the operating system. A disk may have one bit in its boot sector informing the bootstrap loader or other operating system routines whether the disk is bootable or not. Alternatively, a nonbootable disk may have a program in its boot sector and the operating system may have to execute this program to find out whether the disk is bootable. In the latter case, a virus can hide in the boot sector of nonbootable disks. An important point to consider is that the virus doesn’t have to be physically located in the boot sector. The boot sector contains a loader program that reads other operating system routines and stores them in memory. It is therefore enough for the virus writer to write the virus as a file on the bootable disk and to modify the loader to load the virus from the disk while it loads other programs. Even though the virus is written on the disk, it may not appear in the disk directory. It may also be written in an extra track, especially formatted on the infected disk. Disk utilities and anti-virus software read the number of tracks from a table in the disk itself, and therefore know how many tracks to read and examine. An extra, undocumented track, either close to the edge of the disk or between existing tracks, may be an ideal place to hide a virus.

Figure 1 illustrates two variations on this technique. Part (a) of the figure shows a bootstrap loader located in track 0, sector 0 of a disk. Part (b) shows how a virus may move the original loader to a new, extra track and install itself instead of the loader. Part (c) shows another bootstrap loader that’s going to be disturbed a little (in part d) by the incoming BSV virus. The virus installs itself in the new track. It cuts a small part (x) of the loader, moves it to the end of the virus, and replaces it with a JUMP to the start of the virus. When the virus completes its execution, part x is executed, and then control is transferred to the bootstrap, to finish its execution.

IMPLICATIONS OF BOOT SECTOR VIRUS ON WINDOWS OPERATING SYSTEM

Boot sector viruses gain complete control of the master boot record or the DOS boot sector by replacing the operating system contents with that of its own. This allows the virus to spread fast and cause damages like to redirect disk reads, moving or damaging the master boot record to another location which further results the system to crash. The hard disk drive is partitioned into logical partitions. Each drive consists of four logical parts--Boot Sector, File Allocation Table (FAT), Directory and Data space. Of these, the Boot Sector contains information about how the disk is organized. That is, how many sides does it contain, how many tracks are there on each side, how many sectors are there per track, how many bytes are there per sector, etc. The files and the directories are stored in the Data Space. The Directory contains information about the files like its attributes, name, size, etc. The FAT contains information about where the files and directories are stored in the data space i.e. it is the index of all the files on the drive. When a file/directory is created on the disk, instead of allocating a sector for it, a group of sectors is allocated. This group of sectors is often known as a cluster. How many sectors together form one cluster depends upon the capacity of the disk. So, FAT contains information about the space used by each individual file, the unused disk space and the space that is unusable due to defects in the disk.

Boot sector virus spreads in the WOS by either by infecting the Master Boot Record (MBR) so that system is unable to boot itself. Another type of boot sector virus makes copies of itself to 3 blocks on a floppy diskette or hard drive and these blocks are marked bad in the File Allocation Table (FAT), so that they cannot be overwritten. Being so destructive in nature, virus completely destroys the information or data present on the hard disk. After the virus has encrypted the entire disk, the only way to get rid of this virus is to re-format the system. But, formatting removes all the data from the hard drive, which ultimately results in data loss.

One may receive a "Stop 0x0000007B" error message (often known as Blue Screen Of Death or BSOD), Figure(2), if computer is infected with a boot-sector virus which means "inaccessible boot device": Windows is not able to read from the device it is supposed to be booting from. That device in general be hard drive - but if one getting this during Windows installation, it could be something wrong.

Examples: Michelangelo, Disk Killer or Ogre, Brain, W32/ (A boot-sector virus infects various versions of the 32-bit Windows operating system).

On the other hand if everything is well in WOS then Loader with help of assembly instruction dw 0xAA55 simply puts the hexadecimal word "0xAA55" in memory, and org 0x7C00 puts the current memory address at 0x7c00, so any instruction after this will start at 0x7c00(assuming 16-bit storage) to load WOS.

(The hex value 0xAA55 is used as a key signature for boot sector, that mark it the active partition to load the OS startup code in memory to load boot sector in memory. dw 0xAA55 is the signature found at the end of the boot sector .The value 0x7C00 is the memory location where the boot sector code is loaded by the BIOS to execute the code.)

Protection:

1. To protect WOS from any type of virus infection and possibly recover is to have anti-virus software on computer.

System using versions earlier to Windows XP use fdisk /mbr command, to fix the boot sector error, in MS-DOS during booting process. It should be noted that in WOS repartitioning with Fdisk does not rewrite the MBR and can only create re -partitions. But by using additional parameter called /mbr makes to write the master boot record to the hard disk without altering the partition table information using BIOS calls.

From Win XP onwards, where NTLDR is a boot loader, essential disk maintenance tools have been moved to the Recovery Console, which is available when one boot it from the original XP CD. Once accessed in the RC, use the command FIXMBR, which is the equivalent of fdisk /mbr (it writes a fresh copy of the MBR).

PROBLEMS IN BSV DETECTION

The possible problems in locating the BSVs are as under:

1. BSV is so hazardous that it can exploit interrupts to hide itself and also can modify one of them. The task to detect it is too difficult. Suppose somebody wants to locate this virus on the disk. Then he has to read the boot sectors and examine them, but the (memory resident) virus can (and normally does) defeat that. The virus modifies some of the interrupt routines and also the part of the operating system responsible for disk input/output (in the old DOS operating system this part was called BIOS). If this is done properly, the virus is invoked by the BIOS routines each time a program wants to read a sector. The virus then examines the read command, and if the command wants to read a boot sector (sector 0 of track 0), the virus changes the disk address of the read operation from (0, 0) to where it has hidden the original boot sector. An associated problem faced by this type of virus is secondary infection. Before infecting a new disk, the virus has to make sure the disk hasn’t been infected already..Thus, the virus must contain a unique fingerprint or signature.

2. The virus can hide the original boot sector in one of the free sectors (if any) on the disk. The virus uses some of the free sectors, removes them from the chain, and declares them bad. An alternative is to create an extra cylinder on the disk. The capacity of a cylinder is larger than what a virus needs and its presence cannot be detected by the operating system because it receives the number of cylinders from the disk’s header. Modern hard drives have large capacities in a small volume, so any added cylinder would be too close to the edge of the disk and would be unreliable. Older disks, both hard and floppy, were more amenable to this technique. It takes an experienced virus detective to foil such a sophisticated virus.

3. The BSV should establishes itself in memory (if it is not located there already) by modifying one or more interrupt-handling routines, especially the routine that is called when a removable disk is inserted. This way the virus will be able to infect the boot sectors of new disks inserted into the computer.

4. The computer owner can prepare in advance a copy of the boot sector, and later compare it to the boot sector of a suspicious disk. However, a well-designed virus can often defeat this simple check because of the way disks are read and checked.

5. Furthermore in order to read the boot sector and print it, display it, or compare it to a list of instructions, a program is needed. The program should work by invoking operating system routines (sometimes called basic input/output system or BIOS) and the point is that the program can able to modify these routines. Specifically, the routines can be modified such that when they are asked to read the boot sector, they will provide a copy of the original, non-infected sector that had been hidden on the disk by the virus. The security expert can take the suspect disk to another computer and try to read the boot sector there, but the virus may be executed from the boot sector (and modify the BIOS routines) as soon as the disk is inserted into the new computer. The disk should therefore be read in a different type of computer or in the same platform but under an operating system that the virus doesn’t recognize. An alternative is for a security expert to write low-level disk routines, similar to the ones used by BIOS, and read the disk with these routines.

CONCLUSIONS

A boot sector virus embeds itself in the boot sector of a disk (floppy, zip, or hard disk) or a CD, and becomes memory resident when the computer is booted from the disk (if the disk is bootable) or when the disk is inserted into a disk drive and is read. The virus stays in memory while the computer is on, so it can infect any disk mounted in the computer. And this is the fact that this virus that it is easy to detect, because it (or at least its first part) is located at the same position on every infected disk. Furthermore, since BSV can infect hard disks so one has to avoid its propagation by using infected removable disk (a floppy disk, a zip cartridge, or other removable media) from computer to computer. Some BSV itself does not locate themselves in the boot sector but hides elsewhere (generally in extra track) on the disk and be loaded by the loader in the boot sector when the disk is mounted. Such a virus modifies the boot sector, but only in an insignificant way, by adding a few instructions that load the virus. The virus itself may be hidden in an extra track or in unused disk space but in this case the virus may be erased when a new file is written on the disk.

Most programs (executable files) never change their content. The program does not modify itself when executed. The same is true for the boot sectors on disk drives. Such sectors contain programs that load files from the disk, and those programs are always the same (they change only when new versions of the operating system are installed). It is therefore relatively easy to write an anti-virus program that will scan all the executable files on a disk, store their sizes in a table, and use this table in future executions to locate those executable files whose sizes have changed. This anti-virus program should be run periodically, to notify the user of any changes. In WOS, DOS 6.22 Msav.exe will clean the MBR and RAM of the computer. However Mac OS and Linux both have safeguard built in to protect you from these problems.

Authors

• Mehul Minat

• Devarshi Doshi

• Why should you customize PowerShell?

As developers we tend to use Git, to be more specific Git CLI. Natively PowerShell doesn't show much information e.g. which branch we are working on. Using some modules and a terminal we can get different themes for our PowerShell.

• What is Windows Terminal (WT)

Windows Terminal is a terminal application with shells like Command Prompt, PowerShell, and WSL all in one application. Its main features include multiple tabs, panes, custom themes, styles, and configurations.

Tools / Module Used

• Windows Terminal

• oh-my-posh (for PowerShell theme)

• posh-git (for git autocompletion, branch name,...)

• Powerline Fonts (Nerd Font Recommended or Cascadia PL)

• git-bash (assumed to be already installed)

Steps at a glance

1. Install Windows Terminal

2. Install Powerline Fonts

3. Install Required Modules

4. Add modules and desired theme to profile

5. Configure PowerShell to run scripts

6. Add font family in JSON file of terminal

Detailed Steps

Step 1: Install Windows Terminal

• Go to Microsoft Store and install Windows Terminal.

  

• After installing it will appear in the start menu as well.

TIP: Windows Terminal can be opened from a run using wt like cmd

Step 2: Install Fonts

• Any Nerd Font will work with the standard themes of Oh My Posh, but recommended is MesloLGM Font.

• Get MesloLGM Fonts here

Cascadia Font is also compatible but some glyphs are not supported yet you need to patch with custom Unicode manually.

• Install MesloLGM Windows Compatible fonts

NOTE: Install font for all users by right-clicking and install for all users

Step 3: Install Modules

• Using PowerShell, install oh-my-posh and posh-git.

You may install these using Terminal itself

Install-Module posh-git -Scope CurrentUser

Install-Module oh-my-posh -Scope CurrentUser

• You need to press A in PowerShell while installation of both modules to install from the repository. See the image below 👇

  

Step 4: Configure PowerShell Profile

• Enter the below-shown command in PowerShell.

notepad $PROFILE

• If there is no file profile file, then a dialog box will be prompted to create one, hit yes.

• Now inside PowerShell_profile.ps1 file which is currently opened, add the following lines👇

Import-Module posh-git
Import-Module oh-my-posh
Set-PoshPrompt -Theme paradox

• Save the file and close the notepad.

You can change the theme later on as you want, the cover photo is using aliens theme.

Changing themes will be covered in another blog.🙂

Step 5: Configure PowerShell to run scripts

• We need to change the execution policy so that we can run our profile script(the one created in the above step).

• To change execution policy open new PowerShell window as administrator.

  

There will be some errors when you open a new PowerShell window, that is due to restricted execution policy but after executing the below step it won't appear next time.

• Enter the below-shown command(to change policy to unrestricted)

Set-ExecutionPolicy Unrestricted

Step 6: Add Font Family in JSON file of Terminal

• Open Settings of Terminal. From the Dropdown menu adjacent to the + button.

• Or Use ctrl + , as a shortcut to open settings of terminal.

• Now click on the bottom left button labeled as Open JSON File.

• On clicking the button JSON file would be opened in the desired editor, if VS Code is available then it would be opened in that else another editor would be chosen.

• Now add Font Family by Adding the below code in the default section of the JSON file.👇

"fontFace": "MesloLGM NF"

• Note: You must add the above code in the default section only. Don't alter the other code written, we will discuss customizing WT using JSON later in detail, in another blog.

  

Congrats🎉, You have customized the Terminal.

Now change to a git initialized directory / any cloned repository, you will be seeing an extra-label indicating on what branch you are working on.

Extra Themes

• To check all available themes head over to Oh-My-Posh | Themes

• You may check-in PowerShell as well using :

Get-PoshThemes

• For changing theme open the profile file using notepad $profile and change the theme by changing the old theme to the new one.

You can also try theme by temporarily changing theme in PowerShell Using Set-PoshPrompt -Theme <themename> for e.g. Set-PoshPrompt -Theme mt

React 🤟, Comment and Share

Follow Me, More cool stuff on its way.