From 28b3c6b621b920c9ba4597dbab5416cf1a98f7df Mon Sep 17 00:00:00 2001 From: Karl Mikaelsson Date: Wed, 30 Jan 2019 10:34:00 +0100 Subject: [PATCH] Explain the +7 constant while processing secondary drawing orders --- orders.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/orders.c b/orders.c index 34be543..40d4356 100644 --- a/orders.c +++ b/orders.c @@ -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) {