The attributes xPos and yPos for a Color Pointer Update are confusing,
as they may be confused with the xPos and yPos of the pointer bitmap on
the actual screen.
Rename these attributes to what they actually represent, and that is the
hotspot position.
xPos and yPos are still members of the hotspot. However, hotSpotX and
hotSpotY are much more clearer.
In addition to that, the Large Pointer Update uses the same names for
the hotspot coordinates.
Some RDP servers start sending graphics updates too early for us to
process. This triggered a bug that at that point the EndPaint callback
is not available, as the connection is not fully established.
* Fixed remdesk settings pointer
* Fixed sign warnings in display_write_monitor_layout_pdu
* Use freerdp_abort_connect_context and freerdp_shall_disconnect_context
* Added and updates settings
* info assert/dynamic timezone
* mcs assert/log/flags
* Fixed and added assertions for wStream
* Unified stream length checks
* Added new function to check for lenght and log
* Replace all usages with this new function
* Cleaned up PER, added parser logging
* Cleaned up BER, added parser logging
* log messages
* Modified Stream_CheckAndLogRequiredLengthEx
* Allow custom format and options
* Add Stream_CheckAndLogRequiredLengthExVa for prepared va_list
* Improved Stream_CheckAndLogRequiredLength
* Now have log level adjustable
* Added function equivalents for existing logger
* Added a backtrace in case of a failure is detected
* Fixed public API input checks
removed no more actually used count property of BITMAP_UPDATE struct,
fixed allocating twice as memory for its rectangles - as of refactoring
at e5767f07 BITMAP_UPDATE struct is reused no more
When uploading large ICON (96x96), we end up growing the stream
mid-update. Stream_EnsureCapacity end up reallocating the stream
with a larger capacity to accomodate the large ICON size, but in
doing so, also updating the sealed length for the data currently in
the stream. This breaks the assumption between update_begin_paint
and update_end_paint where the sealed lenght is used to keep track
of the location where we need to update the orders counts after
we're done accumulating update. As a result of the growth and lost
of that location, the number of orders is written to the wrong
location and the resulting stream is invalid which result in a
protocol violation and a connection drop.
The current fix uses a new offsetOrder in the update object to
keep track of where update_end_paint needs to write the number
of orders contained. I think a better fix would be for
Stream_EnsureCapacity to preserve the sealead length of the
stream on growth, but this has a much more significant impact and
careful analysis needs to be done to ensure this doesn't violate
other assumption. Need to follow up with FreeRDP developer to get
their take on this one.
* Added checks for bitmap width and heigth values
Data received from the server might have invalid values for bitmap
with or height. Abort parsing if such a value is found.
Reported by Sunglin from the Knownsec 404 team & 0103 sec team
* Added checks for glyph width & height
The length check and field sizes in _update_read_pointer_large
were off, corrected according to [MS-RDPBCGR] 2.2.9.1.2.1.11
Fast-Path Large Pointer Update (TS_FP_LARGEPOINTERATTRIBUTE)
* Split common functionality from client code
* Clean up client code and use proper defines for constants
* Implements the channel code to read/write server side
messages.
Since these functions were called from 2 different threads
(main thread or dynamic channel) depending on fastpath or
gfx channel use lock between these.
If not locked the invalid region may be accessed from both
threads and lead to crashes as experienced with nightly df280a7ff
