kekePower/rdesktop
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Explain the +7 constant while processing secondary drawing orders

Browse Source
This commit is contained in:
Karl Mikaelsson 2019-01-30 10:34:00 +01:00
parent 6249a5fec3
commit 28b3c6b621
1 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
orders.c
View File

@ -1255,7 +1255,7 @@ process_secondary_order(STREAM s)
/* The length isn't calculated correctly by the server.
* For very compact orders the length becomes negative
* so a signed integer must be used. */
uint16 length;
sint16 length;
uint16 flags;
uint8 type;
uint8 *next_order;
@ -1265,12 +1265,17 @@ process_secondary_order(STREAM s)
in_uint16_le(s, flags); /* used by bmpcache2 */
in_uint8(s, type);
if (!s_check_rem(s, (sint16) length + 7))
length += 13; /* MS-RDPEGDI is ridiculous and says that you need to add 13 to this
field to get the total packet length. "For historical reasons". */
length -= 6; /* Subtract six bytes of headers and you'll get the size of the remaining
order data. */
if (!s_check_rem(s, length))
{
rdp_protocol_error("process_secondary_order(), next order pointer would overrun stream", &packet);
}
next_order = s->p + (sint16) length + 7;
next_order = s->p + length;
switch (type)
{