Since this page is the top link that comes up when you enter "UFDPREP.EXE" in Google, I think this would be a good place to share this information. The following is (roughly) what UFDPREP.EXE does when it prepares a UFD (USB Flash Device). Notice especially the last step. All the other steps can be done by using standard tools such as FDISK and Format.
What "UFDPREP.EXE X: /y" does, is this:
- Open the volume (CreateFile "\\\\.\\X:")
- Lock the volume (FSCTL_LOCK_VOLUME)
- Dismount the volume (FSCTL_DISMOUNT_VOLUME)
- Find out which physical drive belongs to logical drive X: (IOCTL_VOLUME_GET_DISK_EXTENTS)
- Open the physical drive (CreateFile "\\\\.\\PhysicalDrive%u")
- Get the physical drive's geometry to determine drive size (IOCTL_DISK_GET_DRIVE_GEOMETRY_EX)
- Write a standard MBR with the usual Windows XP binary code to the physical drive (WriteFile)
- Change the partition table to MBR style, one used partition in FAT32 mode, starting at offset=512, length=(total size - 512) (IOCTL_DISK_SET_DRIVE_LAYOUT_EX)
- Reopen the volume(?) and format it with FAT32 using FormatEx (this is an undocumented system call, google for FMIFS.DLL)
- Patch the boot sector of the volume
The boot sector on the volume gets patched in two places:
- The drive ID at offset 0x40 (set to 0 by Format) gets replaced by 0x80
- The four bytes at offset 0xE6 (set to 0F 82 4A 00, representing an instruction "JB 7D34" in Starman3's disassembly) are overwritten by 66 90 66 90 ("XCHG AX, AX", effectively a no-op)
The patch appears to be the secret to successfully booting NTLDR based OSes. Without the patches, the CF card that I format via USB will not boot on my target system: the boot sector shows the "Disk Error" message. If I only patch the Drive ID, it hangs. If I patch both places, the NTLDR gets loaded correctly and my target system boots successfully.
By the way, only the first copy of the boot sector (sector 0) is modified, the backup copy (sector 6) is left in its original state as created by FormatEx.
I found this out by analyzing the data that gets written to a USB device (by using WinHex to wipe the device first, running UFDPREP and finding the differences with other manually prepared UFD's) and by using Process Monitor from sysinternals.com.
You can use this information for your own applications (which is what I did, but sorry, I'm not allowed to share my app) but use it at your own risk. Don't blame me if you wipe your Windows drive

.
===Jac