-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
Brief description
In the DCERPC_Client class, the _bind method resets the call_id field
#scapy/layers/msrpce/rpcclient.py, line 643
self.call_id = 0 # reset call idWhile this methods is called by method bind and alter_context.
#scapy/layers/msrpce/rpcclient.py
def bind(self, interface: Union[DceRpcInterface, ComInterface]) -> bool:
"""
Bind the client to an interface
:param interface: the DceRpcInterface object
"""
return self._bind(interface, DceRpc5Bind, DceRpc5BindAck)
def alter_context(self, interface: Union[DceRpcInterface, ComInterface]) -> bool:
"""
Alter context: post-bind context negotiation
:param interface: the DceRpcInterface object
"""
return self._bind(interface, DceRpc5AlterContext, DceRpc5AlterContextResp)
Specifications C706 https://pubs.opengroup.org/onlinepubs/9629399/chap12.htm says
The call_id Field
Each run-time protocol message contains a call_id field. This field is used by the caller to guarantee that it is matching the proper response and request. [...]. The caller must guarantee that at any time, all call_ids for all outstanding messages for the same association group are distinct. The server just returns the call_id on the corresponding message.
Specifications C706 defines association group by
The client and server CALL protocol machines communicate using a set of call PDUs, and the client and server ASSOCIATION protocol machines communicate using a set of association PDUs. (The ASSOCIATION GROUP state machines are purely local to the client and server and exchange no PDUs.) The PDUs in each group are:
Association
bind
bind_ack
bind_nak
alter_context
alter_context_response
The reset in _bind method that occurs at bind and alter_context leads to the following problem :
When calling a method twice from the same interface, while having an alter_context between the two calls.
In the second call the call_id is reset to 0 and the server responds with the result of the first call instead of the second.
By deleting the reset, problem doesnt occurs and it doesnt seem to break other functionnality (because call_id doesnt need to start from 0 maybe)
What is the purpose of adding a reset at this step ?
Scapy version
2.7
Python version
3.13
Operating system
Linux 6.18.5
Additional environment information
No response
How to reproduce
When calling a method twice from the same interface, while having an alter_context between the two calls.
In the second call the call_id is reset to 0 and the server responds with the result of the first call instead of the second.
Actual result
No response
Expected result
No response
Related resources
No response