[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

There are a number of places where the "length" variable comes after the array.
I think there are even places where there are other variables separating the "length" and the array apart in some places.

This is all allowed in DCE/RPC and the reason for this is that "length" is just a normal variable.
When used in this way 
    ...
   [length_is(len)] foo_t entries[];
   ...
   int len;

This will actually encode "len" twice on the wire.
First it will encode the array like this :

uint32_t  "length" (*)
element 0
element 1
...
element len-1

I.e. the length of the array is encoded together with the array and it contains the value of "lenth" as the length of the array.

A short while later you will then also have the variable "length" itself being encoded with obviously the same value.


I.e. "length" is encoded twice, first it is encoded as part of the (conformance data of the) array itself
and a second time as the variable "length" itself.
Therefore it does not matter where in the IDL you specify the array and its length in relation to eachother.


(* this is a simplified example,   the array size "length" is actually not encoded at the head of the array but much earlier in the byse-sequence. It is actually encoded at the head of the encapsulating structure)


regards
ronnie sahlberg

On Tue, Apr 28, 2009 at 10:32 AM, Harsha <inet.harsha@xxxxxxxxx> wrote:

On Mon, Apr 27, 2009 at 3:38 PM, Harsha <inet.harsha@xxxxxxxxx> wrote:
> I did a quick read of the relevant part of DCE RPC specs, but in all
> the cases I saw it always had the size and then the array. In those
> cases it is trivial to first extract the size and use the size to
> extract the array contents.

Here is an example in Wireshark code where the length of the array and
then the array are extracted-
void ept_lookup(
[in] handle_t hEpMapper,
[in] unsigned long inquiry_type,
[in, ptr] UUID* object,
[in, ptr] RPC_IF_ID* Ifid,
[in] unsigned long vers_option,
[in, out] ept_lookup_handle_t* entry_handle,
[in, range(0,500)] unsigned long max_ents,
[out] unsigned long* num_ents,
[out, length_is(*num_ents), size_is(max_ents)] ept_entry_t entries[], <-----
[out] error_status* status );

Related dissecting code that extracts the length of the array and then
array is in epm_dissect_ept_map_resp() in packet-dcerpc-epm.c.

Unfortunately I don't see any other case where the array comes ahead
of its length.

Thanks,
Harsha
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe