You do not.
Not as a program that works at the user level: The operating system does not allow programs (in contrast to device drivers) to have access to the hardware - but allows access to abstracted layers of it.
At least the minimums, you have to say which operating system you are working on: Windows, Linux, Mac OS X or other - and make code to work inside it.
Windows
At the time of DOS and the first Windows - which could not prevent programs from directly accessing Hardware - maybe even XP, if not ME - you could have "physical" access to the disk by calling BIOS functions directly - the "int 13h "- These" int "s, or interrupts, deal with hardware events, but they were also a way to call an API - like a library - right in the BIOS for access to Hardware.
To access a "read sector" routine, your code had to load the parameters for the call into specific CPU registers, and then execute the "int 13h" machine instruction - the BIOS performed the routine - read the data, and transfer it to the memory area specified in the registers.
As this depends on the exact values in the registers, it generates encoded in the same Assembler - at most as Inline assembler code within a C function. Compilers always gave an alternative or another to write code that needed to do this. >
Nowadays, if you have a PC that allowed a legacy BIOS, and a floppy disk drive, it is possible that you can write assembler code by calling this routine directly, and put it in the boot sector the diskette. - PCs are compatible with the PCs of that time: you will write 16 bit assembler (this - your 8th generation i5 with 8mb of L1 cache, when it is turned on, you wake up thinking it is an 8086 with 1MB of memory at most - and special machine instructions are required to change the operating modes of the CPU.Good - it may be that with current UEFI systems this is no longer true - but if your boot BIOS is, that's it.)
In the absence of a floppy disk drive, you can try the same approah using DOSBOX , and effectively scheduling a virtual machine on the system DOS - it will be the best way for you to do what you want.
(Look - I searched for BIOS int 13 disk access to see if I found well structured information on how this works - but, bad news - all fragmented, and nothing that "starts from the beginning" to show you how you can do this from the beginning (with the processors, etc ...) - even in an emulated DOS environment). Here maybe at least you have the most documented int13h API: link
To access drives of the "32bits age" you may be able to use a Windows API directly - but, it will be uphill: link
Linux and the other Unixes:
These systems expose disk devices as if they were "a giant file" - a single file with the full size of the disk.
So, as a root user, and normal read, seek, and write calls to files, you move things directly to disk. This abstracts all part of the calculation of sectors, etc ... But .. since the times of the HDs of 512MB, some part of the Hardware already abstracts it for you of any form. (So it did not occur to me to give this explanation first when answering your question - and it comes out speaking of "as it was")
If you want to, for example, see the boot sector of your HD on Linux, just see the first 512 bytes of the / dev / sda file -
You can use a pendrive - it appears as a / dev / sdb block device - if you write a program that is valid machine code in the 8086 (16bit) assembler and copy to the first 512 bytes of that device, when booting the pendrive, ( shutting down UEFI boot, etc ...) - will be able to see your program running.
And finally - about this part of your question:
In theory, would it take some data, write in the sector, read the sector, copy the data to another sector and delete the sector data ??
With disk access as a "block device" in Unix you can do this - but if you do, the chance is that you will destroy the information contained in the disk files - why you have to respect the data structures of the file system that is on the disk.
Again, the file system used in DOS time is FAT - and is still used today in memory cards, etc ... is one of the simplest, and one of the only ones in which it is possible make an independent program to access the data without using the actual file system code itself.