Windows is writting a disk signature (serial number) to the Master boot record, if the two addresses 01B8 (4 bytes) and 01BC (2 bytes) are zeros.
You can export the first 512 bytes from the drive with dd. Then open diskmgmt.msc. After that, the disk should be initialized and the disk signature was written. Export again the first 512 bytes to another file and do a hexdiff of the two files. You'll see the different bytes in the above mentioned addresses.
Can I disable this behaviour in Windows, e.g. in the registry?
I'm on Windows 7.
diffs:
raw - signature zero
0000 01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 ........ .......
windows altered - signature filled in 01B8 (4 bytes)
0000 01B0: 00 00 00 00 00 00 00 00 72 44 E7 89 00 00 00 20 ........ rDþë...
Setting the disk to the offline state, does the trick.
diskpart
list disk
select disk N
offline disk
exit
Related
I am trying to use the webusb api to connect my USB device which basically is a digitizer. the usb version is 2.0.
I have successed to request the device in chrome but failed to open the device with the error Access Deny.
request device
the usb device has 3 interface: 2 HID and 1 USB (winusb loaded). here is the information shown in xusb:
Using libusb v1.0.23.11397
Opening device 2D80:1010...
libusb: warning [hid_open] could not open HID device in R/W mode (keyboard or mouse?) - trying without
Device properties:
bus number: 1
port path: 14 (from root hub)
speed: 12 Mbit/s (USB FullSpeed)
Reading device descriptor:
length: 18
device class: 0
S/N: 3
VID:PID: 2D80:1010
bcdDevice: 0100
iMan:iProd:iSer: 1:2:3
nb confs: 1
Reading BOS descriptor: 1 caps
Unknown BOS device capability 05:
Reading first configuration descriptor:
nb interfaces: 3
interface[0]: id = 0
interface[0].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 03.01.01
endpoint[0].address: 81
max packet size: 0040
polling interval: 01
interface[1]: id = 1
interface[1].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 03.01.01
endpoint[0].address: 82
max packet size: 0040
polling interval: 01
interface[2]: id = 2
interface[2].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: FF.00.00
endpoint[0].address: 83
max packet size: 0040
polling interval: 00
Claiming interface 0...
Claiming interface 1...
Claiming interface 2...
Reading string descriptors:
String (0x01): ""
String (0x02): ""
String (0x03): "******"
Reading Extended Compat ID OS Feature Descriptor (wIndex = 0x0004):
libusb: warning [hid_submit_control_transfer] unsupported HID control request
libusb: warning [hid_submit_control_transfer] unsupported HID control request
00000000 28 00 00 00 00 01 04 00 01 00 00 00 00 00 00 00 (...............
00000010 02 01 57 49 4e 55 53 42 00 00 00 00 00 00 00 00 ..WINUSB........
00000020 00 00 00 00 00 00 00 00 ........
Reading Extended Properties OS Feature Descriptor (wIndex = 0x0005):
libusb: warning [hid_submit_control_transfer] unsupported HID control request
libusb: warning [hid_submit_control_transfer] unsupported HID control request
00000000 8e 00 00 00 00 01 05 00 01 00 84 00 00 00 01 00 ................
00000010 00 00 28 00 44 00 65 00 76 00 69 00 63 00 65 00 ..(.D.e.v.i.c.e.
00000020 49 00 6e 00 74 00 65 00 72 00 66 00 61 00 63 00 I.n.t.e.r.f.a.c.
00000030 65 00 47 00 55 00 49 00 44 00 00 00 4e 00 00 00 e.G.U.I.D...N...
00000040 7b 00 31 00 44 00 34 00 42 00 32 00 33 00 36 00 {.1.D.4.B.2.3.6.
00000050 35 00 2d 00 34 00 37 00 34 00 39 00 2d 00 34 00 5.-.4.7.4.9.-.4.
00000060 38 00 45 00 41 00 2d 00 42 00 33 00 38 00 41 00 8.E.A.-.B.3.8.A.
00000070 2d 00 37 00 43 00 36 00 46 00 44 00 44 00 44 00 -.7.C.6.F.D.D.D.
00000080 44 00 37 00 45 00 32 00 36 00 7d 00 00 00 D.7.E.2.6.}...
Releasing interface 0...
Releasing interface 1...
Releasing interface 2...
Closing device...
the first hid interface is used to report digitizer which i think it is already claimed by the system. I guess that is the issue because I have tried to remove the two hid interface and repeat the process. this time the device was opened successfully.
however the same issue is not presented on Mac OS.
so i am wonder if anyone has any suggestion to solve the issue on windows?
It is possible that this is a Chrome issue. I have been working on a new backend for connecting to USB devices on Windows that should be more reliable, especially for complex composite devices.
Please install Chrome canary-channel (at least version 84.0.4110.2) from https://www.google.com/chrome/canary/ and try turning on the “Enable new USB backend” in flag in chrome://flags.
Let me know if this resolves the issue.
I am trying to read the plain 2048 byte sized data sectors from a data CD on OS X.
But when I open a device such as "/dev/disk8", I get sectors of 2352 in size, with a 16 byte header before each sector's actual Mode1 data.
Even with the BSD tools such as hexdump this can be seen, when reading an older CD made by Apple:
$ hexdump -n 512 -C /dev/disk8
00000000 00 ff ff ff ff ff ff ff ff ff ff 00 00 02 00 01 |................|
00000010 45 52 08 00 00 05 00 00 00 01 00 01 00 00 00 00 |ER..............|
00000020 00 04 00 00 00 10 00 05 00 01 00 00 00 1e 00 19 |................|
00000030 ff ff 00 00 00 41 00 05 07 01 00 00 00 4f 00 1f |.....A.......O..|
00000040 f8 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
The actual sector's data starts here at offset 0x10 with "ER". But the "ER" should be at offset 0.
How can I make this work in my own application without having to remove the extra data in a separate step?
I looked at the various ioctl functions in "IOCDMediaBSDClient.h" and "IOCDTypes.h", but I could not find one that lets me specify that I want to get only the plain data content from the sectors.
I also believe that my existing code which I wrote about 15 years ago, was able to handle this as desired back then, but something has changed in OS X since then, breaking my old code. And now I cannot figure out how to fix that. That code uses ioctl with DKIOCCDREAD, with parameters sectorArea=kCDSectorAreaUser and sectorType=kCDSectorTypeMode1. But that gives me the 16 byte header just like a normal read call does, even though Mode1 means that I should be getting 2048 byte sectors without any headers, as far as I understand it.
As established in the comments section, the answer seems to be to to use the character device (rdisk), not the block device (disk) node. The distinction is not well documented as far as I'm aware, and for hard drives and SSDs is actually quite small - in most cases you can use either. For optical discs it's significantly different, for whatever reason.
I looked into this some time ago, but I forget the details of it, unfortunately. If you're interested in this, you'll find the implementation in the "IOStorageFamily" and "IOCDStorageFamily" source code bundles on Apple's https://opensource.apple.com/ site.
The code files you're after are the ones relating to "BSD clients" - IOMediaBSDClient.cpp/.h in IOStorageFamily, and IOMediaBSDClient.cpp/.h for CDs specifically. The block ("disk") device's ioctls are first handled in dkioctl_bdev() and then forwarded on to the generic dkioctl(), which in turn calls the IOCDMediaBSDClient::ioctl() method. The character device ("rdisk") uses dkioctl_cdev() instead.
I am in the process of learning Assembly, and I tried writing my own bootloader. It works fine on VirtualBox , but it doesn't work on a actual PC.
On pc 'Hello World!' doesn't get printed.
This is the code is use:
BITS 16
ORG 0x7C00
jmp boot_sector
;------------------------------
OEMLabel db "FLOPPYDR"
BytesPerSector dw 512
SectorsPerCluster db 1
ReservedForBoot dw 1
NumberOfFats db 2
RootDirEntries dw 224
LogicalSectors dw 2880
MediumByte db 0xF0
SectorsPerFat dw 9
SectorsPerTrack dw 18
Sides dw 2
HiddenSectors dd 0
LargeSectors dd 0
DriveNo dw 0
Signature db 41
VolumeID dd 0x00
VolumeLabel db "FLOPPYDRIVE"
FileSystem db "FAT12"
;##############################
boot_sector:
;##############################
mov ax, 0x0000 ; Set up the stack
mov ss, ax ; Is this done correctly?
mov sp, 0x7C00 ; (I dont quite understand)
int 0x10 ; Set video mode
int 0x13 ; Reset the drive
mov ah, 0x02 ; Read more sectors
mov al, 2 ; Read two extra sectors,
mov bx, main_sector ; starting from the second.
mov ch, 0 ;
mov cl, 2 ; dl has been set already (?)
mov dh, 0 ;
int 0x13 ;
mov [bootdev], dl ; Store original dl in bootdev
jmp main_sector ; Go to the main sector (0x200 I think)
times 510 - ($ - $$) db 0 ; Fill in the rest of the sector with 0s
dw 0xAA55 ; and 0xAA55 at the end for signature
;##############################
main_sector:
;##############################
jmp Start
;------------------------------
bootdev db 0
msg db 'Hello World!', 10, 13, 0
;------------------------------
print_string:
mov ah, 0x0E
mov bh, 0
cmp al, 0
jne .loop
mov bl, 0x0F
.loop:
lodsb
cmp al, 0
je .end
int 0x10
jmp .loop
.end:
ret
;------------------------------
Start:
mov si, msg
call print_string
hlt
times 512 - ($ - main_sector) db 0
I've also commented in some questions, but these are not my main question (well, maybe me not knowing the answer causes the problem). Why doesn't this work on a real PC?
To compile I use nasm -f bin boot.asm -o boot.bin and to create a virtual floppydisk file I use mkfile 1474560 floppy.flp
Then I open up floppy.flp using HexEdit and replace the first 64 lines (0x00 - 0x3F) with the content of the boot.bin file (opened using HexEdit).
E9 38 00 46 4C 4F 50 50 59 44 52 00 02 01 01 00
02 E0 00 40 0B F0 09 00 12 00 02 00 00 00 00 00
00 00 00 00 00 00 29 00 00 00 00 46 4C 4F 50 50
59 44 52 49 56 45 46 41 54 31 32 B8 00 00 8E D0
BC 00 7C CD 10 CD 13 B4 02 B0 02 BB 00 7E B5 00
B1 02 B6 00 CD 13 88 16 03 7E E9 A3 01 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA <-- End of first sector
E9 24 00 00 48 65 6C 6C 6F 20 57 6F 72 6C 64 21
0A 0D 00 B4 0E B7 00 3C 00 75 02 B3 0F AC 3C 00
74 04 CD 10 EB F7 C3 BE 04 7E E8 E6 FF F4 00 00 (The rest is just 0's).
This is the Terminal when I burn floppy.flp to the USB drive:
Last login: Wed Sep 23 12:10:48 on ttys000
MacBook-Air:~ sasha$ cd ~/Desktop
MacBook-Air:Desktop sasha$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: Apple_HFS 209.7 MB disk0s1
2: Apple_CoreStorage 120.5 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD *120.1 GB disk1
Logical Volume on disk0s2
8CD6A846-395D-4C97-A5DE-0A7ABA9F1C99
Unencrypted
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: Apple_partition_scheme *17.1 MB disk2
1: Apple_partition_map 32.3 KB disk2s1
2: Apple_HFS Flash Player 17.1 MB disk2s2
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: FLOPPYDRIVE *1.0 GB disk3
MacBook-Air:Desktop sasha$ diskutil unmountdisk /dev/disk3
Unmount of all volumes on disk3 was successful
MacBook-Air:Desktop sasha$ sudo dd bs=512 if=floppy.flp of=/dev/disk3
Password:
2880+0 records in
2880+0 records out
1474560 bytes transferred in 0.843982 secs (1747146 bytes/sec)
MacBook-Air:Desktop sasha$
I've written about bootloaders at some length recently on Stackoverflow. Most issues that involve the situation where it works on one emulator or VM but not on another (or physical hardware) usually come down to making false assumptions about the state of the segment registers when the BIOS jumps to your code. Under some emulators the segment registers may have more sane values in them, but that usually isn't the case. From my previous answer I had these two tips that seem to apply here:
When the BIOS jumps to your code you can't rely on DS,ES,SS,SP registers having valid or expected values. They should be set up appropriately when your bootloader starts.
The direction flag used by lodsb, movsb etc could be either set or cleared. If the direction flag is set improperly SI/DI registers may be adjusted in the wrong direction. Use STD/CLD to set it to the direction you wish (CLD=forward/STD=backwards). In this case the code assumes forward movement so one should use CLD. More on this can be found in an instruction set reference
Your assembly code is set to compile and link assuming an origin point of 0x7C00 (via ORG 0x7C00). Your code that accesses variables like msg and bootdev will be made with the assumption that their memory address will be absolute within the segment (DS). This means that if you have an invalid DS segment then you could be addressing variables, data, and labels at the wrong locations. As an example:
mov [bootdev], dl
has an implicit reference to DS and is equivalent to addressing it with an explicit DS segment:
mov [ds:bootdev], dl
If DS has some random value in it then you'll likely be accessing memory in places you don't expect. For some environments DS might just be zero so your code will work.
How do you know which segment to use? The bootloader is loaded by the BIOS at physical memory 0x0000:0x7C00(segment:offset) . Your origin point (Set with ORG directive) matches the offset so that means in your case DS should be set to zero.
In your code ES should also be set to zero. The reason is that INT 0x13 AH=0x02 (disk read) says:
ES:BX Buffer Address Pointer
Imagine if ES is set to random garbage, the disk read will likely read into memory you didn't intend. So just like DS, ES must also be set. You've written your bootloader and kernel in the same file with the origin point of 0x7C00 so again you just need to use an ES segment set to zero.
When setting up your stack you can set ES and DS appropriately.
mov ax, 0x0000 ; Set up the stack
mov ss, ax ; Is this done correctly?
mov sp, 0x7C00 ; (I dont quite understand)
mov ds, ax ; Set DS to 0 because that is what your code needs
mov es, ax ; ES the same as DS.
cld ; Read my tip #2
You did ask if you set your stack properly. There is nothing wrong with it. Your instructions effectively set up a a stack that grows downward from 0x0000:0x7C00 just below the area occupied by your bootloader. That leaves about 27kb (0x7C00-0x1000) of stack space. 4k is plenty for BIOS calls and your current code. The first 0x1000 of memory are generally for interrupt table/BIOS data area etc.
One other bug I noticed in your code was when you try to reset the disk drive:
int 0x10 ; Set video mode
int 0x13 ; Reset the drive
You set AX to zero above these 2 lines. INT 0x10 AH=0x00 (set video mode) has the side effect of returning information in AX. Since AX can be clobbered your call to INT 0x13 AH=0x00 will likely be wrong. You need to clear AH (or all of AX) prior to calling int 0x13 to reset the drive. The code should look like:
int 0x10 ; Set video mode
xor ax,ax ; clear AX (AH=0)
int 0x13 ; Reset the drive
There is a minor issue at the top of your program and would likely only be a problem if you put this bootloader on a properly formatted FAT12 disk image and tried to mount it in your OS. You have:
jmp boot_sector
;------------------------------
OEMLabel db "FLOPPYDR"
The disk structure you have within your bootloader should have OEMLabel starting from the 4th byte. jmp boot_sector could be encoded as a 2 or 3 byte instruction by NASM. Use short to force a 2 byte encoding followed by a NOP (1 byte instruction). This will place OEMLabel at the 4th byte in the file. It could look like this:
jmp short boot_sector
nop
;------------------------------
OEMLabel db "FLOPPYDR"
Alternatively you can encode a JMP that may be 2 or 3 bytes when encoded and pad it with NOP if necessary using NASM's TIMES directive so that OEMLabel always starts at the 4th byte:
jmp boot_sector
times 3-($-$$) nop
;------------------------------
OEMLabel db "FLOPPYDR"
A trick to avoid using hexedit to manually insert the bootloader code at the beginning of a disk image is to use dd. You can use dd to overwrite the first 1024 bytes and keep the rest intact. Try dd if=boot.bin of=floppy.flp bs=512 count=2 conv=notrunc . This should open up floppy.flp write 2 512 byte sectors containing the 1024 bytes from boot.bin without truncating the file (conv=notrunc)
When a bootloader is started the contents of almost all registers (including segment registers) is "undefined". The only register that actually does have a known value is DL (which contains the BIOS' drive number for the disk).
All instructions that refer to memory use an implied or explicit segment register. For example, both mov [bootdev], dl and lodsb rely on the (implied) DS segment register, which is never set and is still undefined.
Like all undefined values, it's possible (due to pure luck) for them to be a value that makes things work by accident. Your code would work if the BIOS happened to leave the value 0x0000 in DS.
On my x86 Linux system reading from different locations in PCI configuration space using setpci seems to give completely different answers for some registers when compared to output from lspci -xxxx.
For example, I pick an arbitrary device on my bus and do lspci -s 00:1f.3 -xxxx and get:
00: 86 80 22 1e 03 00 80 02 04 00 05 0c 00 00 00 00
10: 04 40 51 d0 00 00 00 00 00 00 00 00 00 00 00 00
20: a1 ef 00 00 00 00 00 00 00 00 00 00 28 10 8b 05
...
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 87 0f 04 08 00 00 00 00
Now, the output from setpci -s 00:1f.3 0x40+0.l is 02800003 which is consistent with the output above. However, the output from setpci -s 00:1f.3 0xf8+0.l is ffffffff which from the dump above I would have expected to be 08040f87.
Can someone please help shed some light on what is going on here. I'm new to the world of PCI debugging, so I may be missing something obvious here.
Thanks in advance.
man setpci
setpci is a utility for querying and configuring PCI devices.
Root privileges are necessary for almost all operations, excluding reads of the standard header of the configuration space on some operating systems. Please see lspci(8) for details on access rights.
Try as a Super-user
I am pretty new to Visual Studio C++. I am trying to load a bmp file from my system with specific path and show it on picture control in mfc, but m unable to do so. Can any one guide me here. I tried the following but i am getting an error..
Code:
filePath = "images/0000.4d.bmp";
ASSERT(filePath);
HBITMAP hBitmap= NULL;
hBitmap = (HBITMAP) LoadImage (
0,
filePath,
IMAGE_BITMAP,
0, 0,
LR_LOADFROMFILE | LR_CREATEDIBSECTION | LR_DEFAULTSIZE);
IDB_PICTURE2.LoadBitmapW(MAKEINTRESOURCE(hBitmap));
m_picture.SetBitmap(IDB_PICTURE2);
The error occurs when I am trying to load the bmp file. Thank you.
Error:
Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {525} normal block at 0x0034B848, 54 bytes long.
Data: < x > 84 CF B1 78 12 00 00 00 12 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp(4500) : {518} client block at 0x0034B708, subtype c0, 56 bytes long.
a CObject object at $0034B708, 56 bytes long
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {511} normal block at 0x0034B1C8, 42 bytes long.
Data: < x > 84 CF B1 78 0C 00 00 00 0C 00 00 00 01 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\occmgr.cpp(195) : {510} normal block at 0x0034B170, 24 bytes long.
Data: < > E8 03 00 00 00 00 00 00 E9 03 00 00 00 00 00 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\occmgr.cpp(181) : {509} normal block at 0x0034B120, 16 bytes long.
Data: < > FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00
c:\documents and settings\raja hadi ashraf\my documents\visual studio 2010\projects\mirrorimage\mirrorimage\mirrorimage.cpp(59) : {505} client block at 0x0034AFB0, subtype c0, 12 bytes long.
a CObject object at $0034AFB0, 12 bytes long
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(156) : {494} normal block at 0x0034CDF8, 22 bytes long.
Data: < x > 84 CF B1 78 02 00 00 00 02 00 00 00 01 00 00 00
Object dump complete.
The program '[0x62C] mirrorImage.exe: Native' has exited with code 3 (0x3).
First test that your hBitmap that it's not NULL then just call:
m_picture.SetBitmap( hBitmap );
Other:
IDB_PICTURE2 is just a #define in your resource.h file. At compile time it'll just be replaced with a number, ie it's not a class you can call methods on.
MAKEINTRESOURCE is for converting a resource id into a LPCTSTR for use with methods. It does not turn a hBitmap into a resource.
The 'error' you list is just some debug information. It's not the actual error. If LoadBitmap returns NULL call GetLastError for extra information.