UDS SID2E & SID22 - service

In SID2E and SID22 is there a condition where the length of the entire frame will exceed 7 bytes?
If yes then how it will send or write tha data bytes?

Yes, it is a common use-case in UDS that the response to SID 0x22 (ReadDataByIdentifier) or the request to SID 0x2E (WriteDataByIdentifier) exceeds 7 bytes in length. For this purpose a message consisting of multple CAN frames is
sent, utilizing the Transport-Layer (ISO-TP, ISO 15765-2).
Consider a normal single frame message, where the high-nibble of the first byte is 0x0 i.e.
0x7E0 0x03 0x22 0xF1 0x90
0x7E8 0x04 0x62 0xF1 0x90 0x01
Here the payload is within 7 bytes (in both request and response), so the low-nibble of the first byte tells us the exact length (0x03 in the request, 0x04 in the response). As the complete message fits within a single CAN frame, nothing else is required. But to send a longer diagnostic message, it needs to be splitted across multple CAN frames (segmentation). For this 3 different types of messages are required:
A first frame is sent to the receiver to start the transmission.
This contains the length (up to 4095 bytes) of the complete payload
data and the first 6 bytes of the message. The high-nibble 0x1 of
the first byte indicates that the message is a first frame.
A flow control frame confirming receiving of the first frame is
replied to the sender of the first frame. It contains additional
information like expected STmin timing and block-size. The
high-nibble 0x3 of the first byte indicates that the message is a
flow control frame.
One or more consecutive frames are sent to the receiver, which
contain up to 7 bytes of the remaining payload - together with a
counter to ensure the data can be desegmented in the correct order.
The high-nibble 0x2 of the first byte indicates that the message is
a consecutive frame.
Now consider the following scenario: The tester application sends the single frame 0x7E0 0x03 0x22 0xF1 0x90 as request. The ECU may want to send the response 0x62 0xF1 0x90 0x01 0x02 0x03 0x04 0x05 (8 bytes payload) to the tester application.
So the ECU will first send the first frame:
0x7E8 0x10 0x08 0x62 0xF1 0x90 0x01 0x02 0x03
And wait for a flow control frame from the tester application:
0x7E0 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Then the ECU will continue to send consecutive frames until the
complete message is transmitted:
0x7E8 0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00
For the SID 0x2E (WriteDataByIdentifier) it will be very similar, just the roles are reversed as typically the tester application wants to send the long message in the request and the ECU will reply with the flow control message. i.e.
0x7E0 0x10 0x08 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0 0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00
0x7E8 0x03 0x6E 0xF1 0x90 0x00 0x00 0x00 0x00
If more than one consecutive frame is required, the first byte will simply be increased from 0x21 up to 0x2F and then start again from 0x20 to count up.
0x7E0 0x10 0x76 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0 0x21 0x04 0x05 0x06 0x07 0x08 0x09 0x0A
0x7E0 0x22 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11
...
0x7E0 0x2F 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0x7E0 0x20 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

Related

Pymodbus Asynchronous Server with RTU framer not working

I'm trying to implement a modbus asynchronous serial server with the library Pymodbus. I'm using a ModbusRtuFramer as a frame template. Unfortunately, when I send a command, it looks like the bytes are splitted and the frame is not recognized. I post both the code and the log.
StartSerialServer(context, identity=identity,
framer=ModbusRtuFramer,
port='/dev/ttyS2',
timeout=0.1,
baudrate=9600,
bytesize=8,
parity='N',
stopbits=1)
I send the command 03102c0002 (read 2 holding registers starting from address 102c. The log says:
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame - [b'\x01'] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x10 0x2c
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x3 0x10 0x2c
DEBUG:pymodbus.server.asynchronous:Data Received: 0x0 0x2 0x1 0x2
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x0 0x2 0x1 0x2
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame - [b'\x01'] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x10 0x2c
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x3 0x10 0x2c
DEBUG:pymodbus.server.asynchronous:Data Received: 0x0 0x2 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x0 0x2 0x1
DEBUG:pymodbus.server.asynchronous:Data Received: 0x2
DEBUG:pymodbus.framer.rtu_framer:Frame - [b'\x02'] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x2 0x1
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x10 0x2c 0x0
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x3 0x10 0x2c 0x0
DEBUG:pymodbus.server.asynchronous:Data Received: 0x2 0x1 0x2
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x2 0x1 0x2
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame - [b'\x01'] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x10 0x2c
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x3 0x10 0x2c
DEBUG:pymodbus.server.asynchronous:Data Received: 0x0 0x2 0x1 0x2
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x0 0x2 0x1 0x2

HID descriptor + report for iOS Home button?

I'm trying to use an Arduino to create a single-button Bluetooth keyboard and struggling to construct a valid HID descriptor. I've been able to send key events to my iOS device using the default generic desktop keyboard HID descriptor, but once I try using the following HID descriptor I'm unable to trigger a home button event (AC Home: 0x0223) when I send HID reports to toggle bit 0 from 0 → 1 → 0:
0x05, 0x0c, // USAGE_PAGE (Consumer Devices)
0x09, 0x01, // USAGE (Consumer Control)
0xa1, 0x01, // COLLECTION (Application)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x25, 0x01, // LOGICAL_MAXIMUM (1)
0x75, 0x01, // REPORT_SIZE (1)
0x95, 0x01, // REPORT_COUNT (1)
0x0c, 0x02, 0x23 // USAGE (AC Home)
0x81, 0x06, // INPUT (Data,Var,Rel)
0x95, 0x07, // REPORT_COUNT (7 bytes of padding)
0x81, 0x03, // INPUT (Cnst,Var,Abs)
0xc0 // END_COLLECTION
Am I missing something in the construction of my HID descriptor? Is AC Home not the correct usage ID for the home button in iOS?
Any help would be greatly appreciated!
Yes there is a small error in your descriptor:
0x0c, 0x02, 0x23 // USAGE (AC Home)
should be:
0x0a, 0x23, 0x02 // USAGE (AC Home)
Your current descriptor decodes as:
//--------------------------------------------------------------------------------
// Decoded Application Collection
//--------------------------------------------------------------------------------
/*
05 0C (GLOBAL) USAGE_PAGE 0x000C Consumer Device Page
09 01 (LOCAL) USAGE 0x000C0001 Consumer Control (Application Collection)
A1 01 (MAIN) COLLECTION 0x01 Application (Usage=0x000C0001: Page=Consumer Device Page, Usage=Consumer Control, Type=Application Collection)
15 00 (GLOBAL) LOGICAL_MINIMUM 0x00 (0) <-- Info: Consider replacing 15 00 with 14
25 01 (GLOBAL) LOGICAL_MAXIMUM 0x01 (1)
75 01 (GLOBAL) REPORT_SIZE 0x01 (1) Number of bits per field
95 01 (GLOBAL) REPORT_COUNT 0x01 (1) Number of fields
0C (ERROR) <-- Error: Item (0C) is not a MAIN, GLOBAL or LOCAL item
02 2381 (MAIN) <-- Error: Item (02) is not a MAIN item. Expected INPUT(8x) OUTPUT(9x) FEATURE(Bx) COLLECTION(Ax) or END_COLLECTION(Cx) (where x = 0,1,2,3).
06 9507 (GLOBAL) USAGE_PAGE 0x0795 Reserved
81 03 (MAIN) INPUT 0x00000003 (1 field x 1 bit) 1=Constant 1=Variable 0=Absolute 0=NoWrap 0=Linear 0=PrefState 0=NoNull 0=NonVolatile 0=Bitmap
C0 (MAIN) END_COLLECTION Application
*/
//--------------------------------------------------------------------------------
// Reserved inputReport (Device --> Host)
//--------------------------------------------------------------------------------
typedef struct
{
// No REPORT ID byte
// Collection: CA:ConsumerControl
uint8_t : 1; // Pad
} inputReport_t;
After the above change is implemented it looks in better shape:
//--------------------------------------------------------------------------------
// Decoded Application Collection
//--------------------------------------------------------------------------------
/*
05 0C (GLOBAL) USAGE_PAGE 0x000C Consumer Device Page
09 01 (LOCAL) USAGE 0x000C0001 Consumer Control (Application Collection)
A1 01 (MAIN) COLLECTION 0x01 Application (Usage=0x000C0001: Page=Consumer Device Page, Usage=Consumer Control, Type=Application Collection)
15 00 (GLOBAL) LOGICAL_MINIMUM 0x00 (0) <-- Info: Consider replacing 15 00 with 14
25 01 (GLOBAL) LOGICAL_MAXIMUM 0x01 (1)
75 01 (GLOBAL) REPORT_SIZE 0x01 (1) Number of bits per field
95 01 (GLOBAL) REPORT_COUNT 0x01 (1) Number of fields
0A 2302 (LOCAL) USAGE 0x000C0223 AC Home (Selector)
81 06 (MAIN) INPUT 0x00000006 (1 field x 1 bit) 0=Data 1=Variable 1=Relative 0=NoWrap 0=Linear 0=PrefState 0=NoNull 0=NonVolatile 0=Bitmap
95 07 (GLOBAL) REPORT_COUNT 0x07 (7) Number of fields
81 03 (MAIN) INPUT 0x00000003 (7 fields x 1 bit) 1=Constant 1=Variable 0=Absolute 0=NoWrap 0=Linear 0=PrefState 0=NoNull 0=NonVolatile 0=Bitmap
C0 (MAIN) END_COLLECTION Application
*/
//--------------------------------------------------------------------------------
// Consumer Device Page inputReport (Device --> Host)
//--------------------------------------------------------------------------------
typedef struct
{
// No REPORT ID byte
// Collection: CA:ConsumerControl
uint8_t CD_ConsumerControlAcHome : 1; // Usage 0x000C0223: AC Home, Value = 0 to 1
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
} inputReport_t;
...the HID descriptor was decoded with hidrdd (freeware) from github or sourceforge

x86-64 encoding for MOV instruction, weird case

I disassemble ( with objdump -d ) this opcode (c7 45 fc 05 00 00 00) and get this (mov DWORD PTR [rbp-0x4],0x5). then i try to decode myself and i think it should be (mov DWORD PTR [ebp-0x4],0x5) . Why it is RBP register but not EBP register ? am i missing something ?
Here what i have try:
First i look at the mov opcode for C7 opcode.
C7 /0 iw | MOV r/m16,imm16
C7 /0 id | MOV r/m32,imm32
REX.W + C7 /0 id | MOV r/m64,imm32
so there is no REX.W prefix here, and there also no +rb,+rw,+rd,+ro here. /0 mean ModR/M byte only use r/m register, reg/opcode field can safely ignore here. so 0x45 translate to [EBP]+disp8 (using table2-2. 32-bit addressing forms with the modR/M byte in Volume 2/chapter 2 ). disp8 is 0xfc -> -4. and the rest of the opcode is (05 00 00 00) is imm32.
In 64 bit mode, the default address size is 64 bit: without the address size override prefix (that's 67h, not REX.W) the 64 bit variants of registers will be used in address calculation. That's nice, you almost always want a 64 bit address calculation in 64 bit mode, if that was not the default then there would be a lot of wasted prefixes. The REX.W prefix does not affect address size but "operation size", REX.W + C7 ... is the encoding for mov QWORD PTR [...], imm32.
So, when assembling for 64 bit mode, mov DWORD PTR [ebp-0x4],0x5 would be encoded as 67 c7 45 fc 05 00 00 00, and when disassembling c7 45 fc 05 00 00 00 for 64 bit mode it means mov DWORD PTR [RBP-0x4],0x5.
An interesting consequence of these defaults is that the shortest forms of lea use a 64 bit address but a 32 bit destination, which looks a bit wrong at first.

Windbg dump analysis: what causes error 0x80004002 while asking for handle information?

I'm debugging the memory dump of a process, of which I assume the number of handles becoming too large. When I open the dump in Windbg, I see following error/warning message (I don't know if this is relevant to my question) :
Dir entry 8, HandleDataStream stream has too many elements (0xfefffd > 0x400000)
While launching the Windbg !handle extension command, I see following error message:
0:000> !handle
ERROR: !handle: extension exception 0x80004002.
"Unable to read handle information"
I have already launched that same extension command on other memory dumps of the same process (maybe another version). Hence I don't understand the relevance of most Google results of that error code (something about a wrong interface).
Does anybody know what might cause the mentioned error code and what I can do in order to see the amount of handles in my application dump?
For your information, I'm not interested in every single handle, just the total amount of them.
Edit after first comments
The results of .dumpdebug are the following: (only handle related)
0:000> .dumpdebug
----- User Mini Dump Analysis
MINIDUMP_HEADER:
Version A793 (62F0)
NumberOfStreams 13
Flags 61826
0002 MiniDumpWithFullMemory
0004 MiniDumpWithHandleData
...
Stream 8: type HandleDataStream (12), size 27D7FF98, RVA 101DEF6C
Dir entry 8, HandleDataStream stream has too many elements (0xfefffd > 0x400000)
Stream 9: type CommentStreamW (11), size 000001A0, RVA 000102E0
'
*** "C:\Internal\Tools\Procdump\procdump.exe" -ma -accepteula 18732 C:\Dumps\Own_Application_PID_18732_2019_02_07_11_38_02_777_NOW.dmp
*** Manual dump'
(The results of .dumpdebug and Dumpchk.exe are very similar, I decided not to add them too)
Edited after chdump.py result
Hereby the result (partially) of chdump.py:
MINIDUMP_HEADER EXCLUDING SIGNATURE
version 0xa793
internal version 0x62f0
Number of Streams 0xd
Stream Directory RVA 0x20
CheckSum 0x0
u.TimeDateStamp 2019-02-07 11:45:24
Flags 0x61826
MINIDUMP_DIRECTORY
StreamType DataSize RVA
0x3 0x754 0x434
0x11 0x9cc 0xb88
0x4 0x1588 0x1554
0x13 0x290 0x2adc
0x9 0x12250 0x37fc9f84
0x10 0x6b080 0x37f5ef04
0x7 0x38 0xbc
0xf 0x340 0xf4
0xc 0x27d7ff98 0x101def6c
0xb 0x1a0 0x102e0
0x0 0x0 0x0
0x0 0x0 0x0
0x0 0x0 0x0
_MHDesc2
Handle TypeNameRva ObjectNameRva Attributes GrantedAccess HandleCount PointerCount ObjectInfoRva Reserved0
0x4 0x10490 0x104a8 0x10 0x3 0x7c 0x1ee0c0b 0x0 0x0
0x8 0x104c2 0x0 0x0 0x100020 0x2 0x80001 0x0 0x0
0xc 0x104d0 0x104dc 0x0 0x1 0x2 0x80001 0x0 0x0
0x10 0x1055e 0x1056a 0x0 0x20019 0x2 0x80000 0x0 0x0
0x14 0x105f6 0x0 0x0 0x1f0000 0x2 0x80002 0x0 0x0
0x18 0x1060e 0x0 0x0 0x1f0003 0x2 0x80001 0x0 0x0
0x28 0x1061e 0x1062a 0x0 0xf003f 0x2 0x7ffba 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x30 0x10652 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x34 0x10662 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x38 0x10672 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x3c 0x10682 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x40 0x10692 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x44 0x106a2 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x4c 0x106b2 0x106ca 0x10 0xf 0x44 0xfe9d9c 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x78 0x106f2 0x0 0x0 0x1f0003 0x2 0x7ffc7 0x0 0x0
0x7c 0x10702 0x1070e 0x0 0x20019 0x2 0x7fffe 0x0 0x0
0x80 0x1077a 0x0 0x0 0x100020 0x2 0x40002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x88 0x10788 0x0 0x0 0x100003 0x2 0x40002 0x0 0x0
0x8c 0x107a0 0x0 0x0 0x100003 0x2 0x40002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0xb0 0x107b8 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xb4 0x107c8 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xb8 0x107d8 0x0 0x0 0x1f0003 0x2 0x7fddf 0x0 0x0
0xbc 0x107f0 0x0 0x0 0x1f0003 0x2 0x7fea0 0x0 0x0
0xc0 0x10808 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xc4 0x10820 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xc8 0x10838 0x0 0x0 0x1f0003 0x2 0x7fff6 0x0 0x0
0xcc 0x10850 0x0 0x0 0x1f0003 0x2 0x7fd62 0x0 0x0
0xd0 0x10868 0x0 0x0 0x1f0003 0x2 0x6f1cc 0x0 0x0
0xd4 0x10878 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xd8 0x10888 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xdc 0x108a0 0x108ac 0x0 0xf003f 0x2 0x80000 0x0 0x0
0xe0 0x108f6 0x10902 0x0 0x20019 0x2 0x80000 0x0 0x0
0xe4 0x10958 0x10964 0x0 0x20019 0x2 0x80001 0x0 0x0
0xe8 0x10a08 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xec 0x10a18 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xf0 0x10a28 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x100 0x10a38 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x104 0x10a48 0x0 0x0 0x1fffff 0x4 0xff501 0x10a5a 0x0
0x108 0x10a96 0x0 0x0 0x1f0000 0x2 0x7fff8 0x0 0x0
0x10c 0x10aae 0x0 0x0 0x1f0003 0x2 0x7fffe 0x0 0x0
0x110 0x10abe 0x0 0x0 0x1f0003 0x2 0x5ebe2 0x0 0x0
0x114 0x10adc 0x0 0x0 0xf00ff 0x2 0x73b3f 0x0 0x0
0x118 0x10b00 0x0 0x0 0x100002 0x2 0x80002 0x0 0x0
0x11c 0x10b10 0x0 0x0 0x1 0x2 0x80002 0x0 0x0
0x120 0x10b3e 0x0 0x0 0x100002 0x2 0x7d72d 0x0 0x0
0x124 0x10b4e 0x0 0x0 0x1 0x2 0x5ebe2 0x0 0x0
0x128 0x10b7c 0x0 0x0 0x1f0003 0x2 0x80000 0x0 0x0
0x12c 0x10b8c 0x0 0x0 0x1f0003 0x2 0x80000 0x0 0x0
0x130 0x10b9c 0x0 0x0 0x1f0003 0x2 0x5671f 0x0 0x0
0x134 0x10bac 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x138 0x10bbc 0x0 0x0 0x1fffff 0x4 0xbf505 0x10bce 0x0
0x13c 0x10c0a 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x140 0x10c1a 0x0 0x0 0x1f0003 0x2 0x74432 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x148 0x10c2a 0x0 0x0 0x1f0003 0x2 0x80001 0x0 0x0
0x14c 0x10c3a 0x0 0x0 0x100001 0x2 0x7feb3 0x0 0x0
0x150 0x10c48 0x0 0x0 0x1f0003 0x2 0x80001 0x0 0x0
0x154 0x10c58 0x0 0x0 0x1f0000 0x2 0x4d899 0x0 0x0
0x158 0x10c70 0x0 0x0 0x1f0003 0x2 0x7ffdc 0x0 0x0
0x15c 0x10c80 0x0 0x0 0x1f0003 0x2 0x80000 0x0 0x0
0x160 0x10c90 0x10c9c 0x0 0xf003f 0x2 0x7ffd6 0x0 0x0
0x164 0x10ce6 0x0 0x0 0x1f0003 0x2 0x80000 0x0 0x0
0x168 0x10cf6 0x10d0a 0x0 0x4 0xa3 0x28c0002 0x0 0x0
0x16c 0x10d5a 0x10d66 0x0 0xf003f 0x2 0x7ffc4 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x174 0x10db0 0x10dc0 0x10 0x100001 0x53 0x18003f 0x0 0x0
0x178 0x10e10 0x10e1c 0x0 0x20019 0x2 0x7fff4 0x0 0x0
0x17c 0x10e94 0x10ea0 0x0 0x20019 0x2 0x7fff4 0x0 0x0
0x180 0x10f1c 0x10f30 0x0 0x4 0xa3 0x28c0002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x188 0x10f80 0x0 0x0 0x120089 0x2 0x7fffc 0x0 0x0
0x18c 0x10f8e 0x0 0x0 0xf0005 0x2 0x80001 0x0 0x0
It does very far: the Python script even stopped, due to a memory error, after having generated ±13 million(!) lines of results.
Thanks in advance
The Format of Minidump file is almost Documented You can parse the file yourself without having to Rely on windbg
say with python
the Error seems to be Explicit there is some corruption in the _MINIDUMP_DIRECTORY->DataSize
The Max Number of Handles iirc is limited to 10000 handles per process
(browse for Raymond Chens blog old new thing)
so there is must be some hardcoded limit for the stream size which when violated
results in that error
below is a quickly churned python script that takes a dump and dumps the raw data
open the dump in hexeditor and peer around or maybe patch to recover part handle information
%%writefile chkdump.py
import sys
import os
import struct
import datetime
scriptname = os.path.split(sys.argv[0])[1]
if (len(sys.argv) != 2 ):
sys.exit("usage python %s path_to_dump" % scriptname)
fin = open(sys.argv[1],'rb')
if( fin.read(4) != 'MDMP' ):
fin.close()
sys.exit("not a windbg dump file no MDMP signature")
print ( "MINIDUMP_HEADER EXCLUDING SIGNATURE")
dmphdr = struct.unpack("<HHiiiiQ",fin.read(28))
print ( "%-20s\t0x%x") % ( "version", dmphdr[0] )
print ( "%-20s\t0x%x") % ( "internal version", dmphdr[1] )
print ( "%-20s\t0x%x") % ( "Number of Streams", dmphdr[2] )
print ( "%-20s\t0x%x") % ( "Stream Directory RVA", dmphdr[3] )
print ( "%-20s\t0x%x") % ( "CheckSum", dmphdr[4] )
print ( "%-20s\t") % ( "u.TimeDateStamp" ),
print ( datetime.datetime.fromtimestamp(dmphdr[5]))
print ( "%-20s\t0x%x") % ( "Flags", dmphdr[6] )
print ("\nMINIDUMP_DIRECTORY ")
print ("%-24s%-24s%-24s") % ("StreamType" , "DataSize","RVA")
streamdata = []
for i in range(0,dmphdr[2],1):
streamdata.insert(i,struct.unpack("<iii",fin.read(12)))
print ("%-24s%-24s%-24s") % ( hex(streamdata[i][0]),
hex(streamdata[i][1]),hex(streamdata[i][2]))
HStreamLoc, = [z for (x,y,z) in streamdata if x == 0xc]
HStreamDSize, = [y for (x,y,z) in streamdata if x == 0xc]
fin.seek(HStreamLoc)
sizeof_HDStream = 16
HDStream = struct.unpack("<iiii",fin.read(sizeof_HDStream))
assert (HDStream[1] * HDStream[2] + sizeof_HDStream ) == HStreamDSize
print ("_MHDesc2")
sizeof_MHDesc2 = 40
HDesc = []
print ("%-14s%-14s%-14s%-14s%-14s%-14s%-14s%-14s%-14s") % ("Handle" ,"TypeNameRva",
"ObjectNameRva","Attributes","GrantedAccess","HandleCount","PointerCount",
"ObjectInfoRva","Reserved0")
for i in range(0,HDStream[2],1):
HDesc.insert(i,struct.unpack("<Qiiiiiiii",fin.read(sizeof_MHDesc2)))
print ("%-14s%-14s%-14s%-14s%-14s%-14s%-14s%-14s%-14s") % ( hex(HDesc[i][0]),
hex(HDesc[i][1]), hex(HDesc[i][2]), hex(HDesc[i][3]),hex(HDesc[i][4]),
hex(HDesc[i][5]), hex(HDesc[i][6]),hex(HDesc[i][7]), hex(HDesc[i][8]))
when executed it would return data like this for handle stream
MINIDUMP_HEADER EXCLUDING SIGNATURE
version 0xa793
internal version 0x61b1
Number of Streams 0xd
Stream Directory RVA 0x20
CheckSum 0x0
u.TimeDateStamp 2019-02-14 02:38:24
Flags 0x61826
MINIDUMP_DIRECTORY
StreamType DataSize RVA
0x3 0x94 0x1dc
0x11 0xcc 0x270
0x4 0xc40 0x33c
0x13 0x388 0xf7c
0x9 0x1100 0x91f0
0x10 0x4f30 0x42c0
0x7 0x38 0xbc
0xf 0xe8 0xf4
0xc 0xb28 0x3798
0xb 0x58 0x294c
0x0 0x0 0x0
0x0 0x0 0x0
0x0 0x0 0x0
_MHDesc2
Handle TypeNameRva ObjectNameRva Attributes GrantedAccess HandleCount PointerCount ObjectInfoRva Reserved0
0x4 0x29b4 0x29cc 0x10 0x3 0x2d 0x54 0x0 0x0
0x8 0x29e6 0x0 0x0 0x100020 0x2 0x3 0x0 0x0
0xc 0x29f4 0x0 0x0 0x100020 0x2 0x3 0x0 0x0
0x10 0x2a02 0x0 0x0 0x100020 0x2 0x3 0x0 0x0
0x14 0x2a10 0x0 0x0 0x1f0000 0x2 0x5 0x0 0x0
EDIT
i have edited the code to print handle , type name , object name
and put it here
the results will be like
Handle TypeName ObjectName
0x4 Directory \KnownDlls
0x8 File No ObjName
0xc File No ObjName
0x10 File No ObjName
0x14 ALPC Port No ObjName
0x18 Key \REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Nls\Sorting\Versions
it should print all the 16.7 million handles in your dump if they exist

x86_64 64 bit immediate move

I am writing the instruction below.
movq $TARGET_CIA, %rcx
TARGET_CIA is an undefined variable so is treated as zero. This instruction's disassembly looks like
0: 48 c7 c1 00 00 00 00 mov $0x0,%rcx
At run time, I want to replace this $TARGET_CIA with a 64-bit value by copying the 64-bit value to the offset of TARGET_CIA symbol. Please let me know how this can this be done.
In fasm you would achieve that with "mov [qword 0], rax". Note that AL, AX, EAX, RAX are the only registers allowed to be the source or destination of an instruction with 64-bit absolute addressing so you won't be able to use RCX here (copy the value to RAX)
If your assembler has no means to force full addressing, then use:
db 0x48, 0xA3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00