I can't manage to find out why there are sometime some .words missing in my assembly code when I run objdump. What do the "..." alone on a line represent?
Inside of the objdump output of -d or -D (disassemble), there will often be multiple instances of lines containing only an ellipsis. This is only because all the bytes between the above and below bytes are all null (0x00).
Below is the output of a disassembled 32bit program. Between the offset of 00234(+4) and 00240 are all 0x00 inside of the executable file.
40022c: 00000034 0x34
400230: 0000016a 0x16a
400234: 000001ac 0x1ac
...
400240: 00000098 0x98
400244: 00000000 nop
400248: 000000a9 0xa9
...
400254: 000000cf 0xcf
Looking at the application we disassembled, you can see that where the ellipsis occurs is all null bytes. No point in outputting these to the user multiple times, so objdump simply removes them. The bold text is where the ellipsis occur. I should also note, that if there is only one section (32 / 64bits) of null bytes, objdump will show this as nop or similar depending on machine.
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000220 34 00 00 00 4...
00000230 6A 01 00 00 AC 01 00 00 00 00 00 00 00 00 00 00 j...¬...........
00000240 98 00 00 00 00 00 00 00 A9 00 00 00 00 00 00 00 ˜.......©.......
00000250 00 00 00 00 CF 00 00 00 ....Ï...
I've used a -z argument to objdump which suppresses hiding of some zero information. You should see the .word arguments with zeroes.
This seems to be useful when you're passing the output of objdump to another program.
Related
I am writing a small x86-64 hobby OS I boot with UEFI. I am currently writing a driver for the Intel's xHC. I am at a point where I can address USB devices and have a Transfer Ring allocated for Endpoint 0 of each device. I then use a GET_DESCRIPTOR request to get the configuration descriptor of each device. I ask QEMU to emulate a USB keyboard and a USB mouse. I thus get 2 different descriptors which are the following:
user#user-System-Product-Name:~$ hexdump -C result.bin
00000000 09 02 22 00 01 01 06 a0 32 09 04 00 00 01 03 01 |..".....2.......|
00000010 02 00 09 21 01 00 00 01 22 34 00 07 05 81 03 04 |...!...."4......|
00000020 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000 09 02 22 00 01 01 08 a0 32 09 04 00 00 01 03 01 |..".....2.......|
00001010 01 00 09 21 11 01 00 01 22 3f 00 07 05 81 03 08 |...!...."?......|
00001020 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00002000
Basically, I ask GDB to output the content of RAM where I placed the descriptors in the file result.bin. Then I hexdump the content of result.bin in the console. Here you can see the configuration of the USB mouse first. Then, 1 page later, the configuration of the USB keyboard.
The configuration descriptor of the mouse is 09 02 22 00 01 01 06 a0 32. It is followed with 2 interface descriptors: 09 04 00 00 01 03 01 02 00 and 09 21 01 00 00 01 22 34 00. Those are followed by one endpoint descriptor: 07 05 81 03 08 00 07.
In the first interface descriptor for both the mouse and the keyboard, it is indicated that there is one endpoint descriptor (indicated by the bNumEndpoints field of the descriptor which is byte number 4 indexed from 0). I would expect that the following descriptor is the endpoint descriptor. Instead, I get a second interface descriptor (indicated by the fact that it has a length of 9 bytes instead of 7 and by the values of the different fields).
As stated on https://wiki.osdev.org/Universal_Serial_Bus:
Each CONFIGURATION descriptor has at least one INTERFACE descriptor, and each INTERFACE descriptor may have up to 15 ENDPOINT descriptors. When the host requests a certain CONFIGURATION descriptor, the device returns the CONFIGURATION descriptor followed immediately by the first INTERFACE descriptor, followed immediately by all of the ENDPOINT descriptors for endpoints that the interface defines (which may be none). This is followed immediately by the next INTERFACE descriptor if one exists, and then by its ENDPOINT descriptors if applicable. This pattern continues until all the information within the scope of the specific configuration is transfered.
Why do I get 2 interface descriptors followed by the endpoint descriptor in my case? Is it a QEMU bug or is it something I should expect?
You're not accurately describing the binary data that I see in your shell output.
The dump starts with 9-byte descriptor of type 2 so that is your device descriptor:
09 02 22 00 01 01 06 a0 32
Then there is a 9-byte descriptor of type 4, so that is an interface, and it has bNumEndpoints set to 1:
09 04 00 00 01 03 01 02 00
Then there is another 9-byte descriptor of type 0x21. I don't recognize that code off the top of my head, but it probably is something standard:
09 21 01 00 00 01 22 34 00
Then we have a 7-byte descriptor of type 5, so that is an endpoint descriptor:
07 05 81 03 04 00 07
After reading RFC 1951 and manually wrote a simple gzip file that contains non-compressed data. The uncompressed data file only has one character 'a' with no additional spaces or line breaks. The content of the gzip file is
1f 8b 08 00 00 00 00 00 00 03 01 80 00 7f ff 86 43 be b7 e8 01 00 00 00.
When I was trying to unzip it under Linux system, it gave me an error "gzip: xxx.gz: unexpected end of file".
I think I followed the deflate format of non-compressed data block mentioned in 3.2.4. After 10 bytes gzip header,
01: BFINAL=1 and BTYPE=00
8000: LEN=1
7fff: NLEN
86: a
Followed by CRC and Size.
Can anyone point out anything wrong or missing in the gzip file? Thanks a lot.
8000 is length 128, not 1. 0100 would be length 1. (Interestingly, you managed to correctly represent the total uncompressed length at the end as 01 00 00 00.)
Also an a is hex 61, not 86.
So the correct stream would be:
1f 8b 08 00 00 00 00 00 00 03 01 01 00 fe ff 61 43 be b7 e8 01 00 00 00
I would like to take some jbig2 data out of a pdf file and load it using libjbig2dec (http://sourceforge.net/projects/jbig2dec)
For some reason the jbig2 data in the pdf file starts with this:
00000000 00 00 00 00 30 01 01 00 00 00 13 00 00 0a 5e 00
00000010 00 0f c3 00 00 2e 23 00 00 2e 23 00 00 00 00 00
00000020 00 01 26 01 01 ff ff ff ff 00 00 0a 5e 00 00 0f
00000030 c3 00 00 00 00 00 00 00 00 00 00 03 ff fd ff 02
00000040 fe fe fe ab f3 d0 fe 9e 92 d8 9f 63 ae 67 79 b8
00000050 81 ff 57 33 90 a4 ee c2 af c8 80 dc 0d 60 1e 86
But a valid jbig2 file should start with this magic:
0x97, 0x4a, 0x42, 0x32, 0x0d, 0x0a, 0x1a, 0x0a
What's going on here?
pdf format strips the header and the tail of the jbig2 file as specified in PDF, Version 1.7 (ISO 32000-1:2008) section 7.4.7 JBIG2Decode Filter
Further, some pdf files contain jbig2 streams with last segment of unspecified size (ff ff ff ff). libjbig2dec can not handle this.
Some PDFs are missing JBIG2 header and here is one of well known stream for jb2 file format.
974A42320D0A1A0A0100000001000000003E00010000006820000000536F7572636500506F776572204A4249472D3220456E636F646572202D2054686520556E6976657273697479206F66204272697469736820436F6C756D626120616E6420496D61676520506F77657220496E632E0056657273696F6E00312E302E3000000000
I added the above stream to header of rough data, and it was decoded well.
Consider the following hexedit display of an ELF file.
00000000 7F 45 4C 46 01 01 01 00 00 00 00 00 .ELF........
0000000C 00 00 00 00 02 00 03 00 01 00 00 00 ............
00000018 30 83 04 08 34 00 00 00 50 14 00 00 0...4...P...
00000024 00 00 00 00 34 00 20 00 08 00 28 00 ....4. ...(.
00000030 24 00 21 00 06 00 00 00 34 00 00 00 $.!.....4...
0000003C 34 80 04 08 34 80 04 08 00 01 00 00 4...4.......
00000048 00 01 00 00 05 00 00 00 04 00 00 00 ............
How many section headers does it have?
Is it an object file or an executable file?
How many program headers does it have?
If there are any program headers, what does the first program header do?
If there are any section headers, at what offset is the section header table?
Strange, this hexdump looks like your homework to me...
There are 36 section headers.
It is an executable.
It has 8 program headers.
As you can tell by the first word (offset 0x34: 0x0006) in the first program header, it is of type PT_PHDR, which just informs about the characteristics of the program header table itself.
The section header table begins at byte 5200 (which is 0x1450 in hex).
How do I know this stuff? By dumping the hex into a binary and reading it with readelf -a (because I am lazy). Except for question no. 4, which I had to figure out manually by reading man 5 elf.
I have a problem writing to HID device;
Below are two logs made with Snoopy.
The first one is made using original demo SW of device manufacturer and the second is my SW log.
My software doesn't work with this device but works with another HID device.
Original software:
9 ??? down n/a 27.868 BULK_OR_INTERRUPT_TRANSFER 06 16 19 17 00 00 00 00
URB Header (length: 72)
SequenceNumber: 9
Function: 0009 (BULK_OR_INTERRUPT_TRANSFER)
TransferFlags: 0x00000002
TransferBuffer: 0x00000040 (64) length
0000: 06 16 19 17 00 00 00 00 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9 ??? up n/a 27.874 BULK_OR_INTERRUPT_TRANSFER - 0x00000000
URB Header (length: 72)
SequenceNumber: 9
Function: 0009 (BULK_OR_INTERRUPT_TRANSFER)
TransferFlags: 0x00000002
No TransferBuffer
My software:
9 out down n/a 22.224 CLASS_INTERFACE 06 16 19 17 00 00 00 00
URB Header (length: 80)
SequenceNumber: 9
Function: 001b (CLASS_INTERFACE)
PipeHandle: 00000000
SetupPacket:
0000: 22 09 00 02 00 00 00 00
bmRequestType: 22
DIR: Host-To-Device
TYPE: Class
RECIPIENT: Endpoint
bRequest: 09
TransferBuffer: 0x00000040 (64) length
0000: 06 16 19 17 00 00 00 00 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9 out up n/a 22.227 CONTROL_TRANSFER - 0x00000000
URB Header (length: 80)
SequenceNumber: 9
Function: 0008 (CONTROL_TRANSFER)
PipeHandle: 877af60c
SetupPacket:
0000: 21 09 00 02 00 00 40 00
bmRequestType: 21
DIR: Host-To-Device
TYPE: Class
RECIPIENT: Interface
bRequest: 09
No TransferBuffer
Code used to send the data looks like this:
hiddata.ReportID := 0;
hiddata.Data[0] := 6;
hiddata.Data[1] := $16;
hiddata.Data[2] := $19;
hiddata.Data[3] := $17;
for I := 4 to 64 do
hiddata.Data[I] := $0;
b := HidD_SetOutputReport(HidHandle, #hiddata, 65);
HidHandle is correct and variable "b" is True after execution.
Any ideas?
What I'm doing wrong?
Original:
Function: 0009 (BULK_OR_INTERRUPT_TRANSFER)
Your program:
Function: 0008 (CONTROL_TRANSFER)
HID spec allows both IIRC, but it seems your Hardware is picky and only works when using the interrupt endpoint.