A little help with dd

impact0r · 02-01-2014, 10:53 AM

Well, it worked for someone else so I would like to try it.
Which one would that be in schneidz's code line?

Z038 · 02-01-2014, 11:01 AM

In schneidz's example, you would change the x'48' in the second byte (byte 1 indexed from 0) to x'49', that is, b'01001000' to b'01001001'

But I am pretty sure that is not going to work for you. The bit would need to be turned on in the response data that is returned for the SCSI Inquiry command, and that almost certainly comes from the USB internal firmware, which you can't edit, not from data that is stored on the device itself. I could be wrong, but that's what I think.

EDIT: Read this: http://www.prime-expert.com/articles...ge-devices.php

schneidz · 02-01-2014, 11:05 AM

Code:

byte#:0         1         2
      EB        48        90
      11101011  01001000  10010000 
bit #:76543210  76543210  76543210
...

not sure... my interpretation based on the microsoft website it should be x48 -> xc8.

Z038 · 02-01-2014, 11:10 AM

Well, if you count the bits from the right, then you are correct, schneidz. I am a big-endian mainframe guy, so bits and bytes are numbered from the left (lower address to higher address). In other words, I would number this way:

Code:

byte#:0         1         2
      EB        48        90
      11101011  01001000  10010000 
bit #:01234567  01234567  01234567
...

Which would make it x'49'.

schneidz · 02-01-2014, 11:18 AM

Quote:

Originally Posted by Z038

Well, if you count the bits from the right, then you are correct, schneidz. I am a big-endian mainframe guy, so bits and bytes are numbered from the left (lower address to higher address).

Which would make it x'49'.

Code:

byte#:1         2         3
      EB        48        90
      11101011  01001000  10010000 
bit #:12345678  12345678  12345678
...

but if microsoft is considering byte-1 to be the first byte then xeb would remain the same in my example.

impact0r · 02-01-2014, 11:19 AM

Quote:

Originally Posted by Z038

Well, if you count the bits from the right, then you are correct, schneidz. I am a big-endian mainframe guy, so bits and bytes are numbered from the left (lower address to higher address). In other words, I would number this way:

Code:

byte#:0         1         2
      EB        48        90
      11101011  01001000  10010000 
bit #:01234567  01234567  01234567
...

Which would make it x'49'.

I still don't get it.

Quote:

00000000 FA B8 00 10 8E D0 BC 00 B0 B8 00 00 8E D8 8E C0 FB BE 00 7C ...................|
00000014 BF 00 06 B9 00 02 F3 A4 EA 21 06 00 00 BE BE 07 38 04 75 0B .........!......8.u.
00000028 83 C6 10 81 FE FE 07 75 F3 EB 16 B4 02 B0 01 BB 00 7C B2 80 .......u.........|..
0000003C 8A 74 01 8B 4C 02 CD 13 EA 00 7C 00 00 EB FE 00 00 00 00 00 .t..L.....|.........

The red one is 0x49. Is it really that far from the beginning? If I read your table right, then this is Byte 19, bit 2 and 3.

jlinkels · 02-01-2014, 11:29 AM

In scheidz' /dev/sda the first byte is 0x48. So it is in mine. But it does not have to be that way on your device. He was using the 0x48 as an example.

Still, nowhere in the description of the MBR (and that really is the first bytes on your device) there is any reference to something which has to have a certain value on byte 1.
http://en.wikipedia.org/wiki/Master_boot_record

jlinkels

Z038 · 02-01-2014, 11:44 AM

Quote:

Originally Posted by schneidz

Code:

byte#:1         2         3
      EB        48        90
      11101011  01001000  10010000 
bit #:12345678  12345678  12345678
...

but if microsoft is considering byte-1 to be the first byte then xeb would remain the same in my example.

They are counting from 0, not from 1. They say "Bit 7 of byte 1 (indexed from 0) is the Removable Media Bit (RMB)."

With respect to bit and byte order on big versus little-endian systems, I found this article Byte and Bit Order Dissection from Linux Journal that says this:

Quote:

Bit order usually follows the same endianness as the byte order for a given computer system. That is, in a big endian system the most significant bit is stored at the lowest bit address; in a little endian system, the least significant bit is stored at the lowest bit address.

and gives this example:

Code:

Write Integer for Big Endian System

byte  addr       0         1       2        3
bit  offset  01234567 01234567 01234567 01234567
     binary  00001010 00001011 00001100 00001101
        hex     0a       0b      0c        0d

Write Integer for Little Endian System

byte  addr      3         2       1        0
bit  offset  76543210 76543210 76543210 76543210
     binary  00001010 00001011 00001100 00001101
        hex     0a       0b      0c        0d

I notice in your example that your bit and byte order are opposite from each other. To be honest, I am really only comfortable with big-endian ordering. In a little-endian context, I understand how integers are stored in memory, as in the example above, but I'm never really sure what is meant when someone gives an offset from a particular address on a little-endian system.

All this is academic. I don't believe the OP can flip the removable media bit by writing to the first two bytes of the device.

---------- Post added 02-01-14 at 11:45 AM ----------

Quote:

Originally Posted by impact0r

I still don't get it.

The red one is 0x49. Is it really that far from the beginning? If I read your table right, then this is Byte 19, bit 2 and 3.

No, I was referring to the value of the second byte (byte 1), not the offset.

schneidz · 02-01-2014, 11:54 AM

the shotgun approach would be to make the first few bytes of device xff's (but i am not sure what harm that would do).

also i was using calculator to convert hex -> bin and it shows the 0-bit on the rite.

Z038 · 02-01-2014, 12:02 PM

Quote:

Originally Posted by schneidz

the shotgun approach would be to make the first few bytes of device xff's (but i am not sure what harm that would do).

That would overwrite the first few bytes of the MBR. It will not accomplish the OP's goal.

schneidz · 02-01-2014, 12:07 PM

Quote:

Originally Posted by Z038

That would overwrite the first few bytes of the MBR. It will not accomplish the OP's goal.

then lets overwrite the whole drive with xff's (<@

)

to op: what microsoft probably intended was make sure this bit is equal to '1':

Code:

byte#:0         1         2
      EB        48        90
      11101011  01001000  10010000 
bit #:01234567  01234567  01234567
...

this is what my drive has as the first few bytes (yours will probably be different).

Z038 · 02-01-2014, 12:12 PM

Quote:

Originally Posted by impact0r

I need to write a zero on Bit 7 of byte 1 (indexed from 0) of my USB stick.

This is so that windows systems can see multiple partitions on it.

I have been trying to figure out a dd command to do that, but I can't make this out.

Any suggestions?

The removable media bit is not in a data area that you can access with the dd command or a hex editor. Some drive manufacturers provide a utility for flipping the bit, and some don't. See this link, as an example: http://superuser.com/questions/39117...ives-to-bootit

.

schneidz · 02-01-2014, 01:23 PM

Quote:

Originally Posted by impact0r

I still don't get it.

Code:

00000000 FA B8 00 10 8E D0 BC 00 B0 B8 00 00 8E D8 8E C0 FB BE 00 7C ...................|
00000014 BF 00 06 B9 00 02 F3 A4 EA 21 06 00 00 BE BE 07 38 04 75 0B .........!......8.u.
00000028 83 C6 10 81 FE FE 07 75 F3 EB 16 B4 02 B0 01 BB 00 7C B2 80 .......u.........|..
0000003C 8A 74 01 8B 4C 02 CD 13 EA 00 7C 00 00 EB FE 00 00 00 00 00 .t..L.....|.........

The red one is 0x49. Is it really that far from the beginning? If I read your table right, then this is Byte 19, bit 2 and 3.

i see that the 0th byte of your drive is equal to xfa... maybe change it to xfb ?

schneidz · 02-01-2014, 01:32 PM

Quote:

Originally Posted by Z038

The removable media bit is not in a data area that you can access with the dd command or a hex editor. Some drive manufacturers provide a utility for flipping the bit, and some don't. See this link, as an example: http://superuser.com/questions/39117...ives-to-bootit

.

good point if this register is part of the microcontroller or eeprom of the device then it is not accessible by our means. we would need something similar to what the manufacturer uses to program that particular register.