fast_ber::Integer wrong encodding

[pedjaman]

I've tried using fast_ber for my project as it required BER encoding. It is a Microsoft RDP protocol. It seems that integers are encoded badly, as produced results are not as in BER specification and RDP messages are also expecting different results.
Here are some example of integer being encoded badly:

fast_ber::Integer<> i = 255;
result = 02 02 00 ff (wrong)
should be: 02 01 ff

fast_ber::Integer<> i = 65534;
result = 02 03 00 ff fe (wrong)
should be: 02 02 ff fe

fast_ber::Integer<> i = 65535;
result = 02 03 00 ff ff (wrong)
should be: 02 02 ff ff

Please advise

[Samuel-Tyler]

Hi Pedjaman,

I believe this value is correct.

Rules from https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf:

8.3 Encoding of an integer value
8.3.1 The encoding of an integer value shall be primitive. The contents octets shall consist of one or more octets.
8.3.2 If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet
and bit 8 of the second octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of octets.
8.3.3 The contents octets shall be a two's complement binary number equal to the integer value, and consisting of
bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed by bits 8 to 1 of each octet in turn up to
and including the last octet of the contents octets.
NOTE – The value of a two's complement binary number is derived by numbering the bits in the contents octets, starting with bit
1 of the last octet as bit zero and ending the numbering with bit 8 of the first octet. Each bit is assigned a numerical value of 2N,
where N is its position in the above numbering sequence. The value of the two's complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are set to one, excluding bit 8 of the first octet, and then
reducing this value by the numerical value assigned to bit 8 of the first octet if that bit is set to one. 

As this is two's compliment 02 01 ff encodes as -1

Nokalva online encoder agrees with this encoding.

Encoding to the file 'data.der' using DER encoding rule...
Rocket INTEGER: tag = [UNIVERSAL 2] primitive; length = 3
  65535
Encoded successfully in 5 bytes:
020300FF FF

[pedjaman]

Hi,

I'm not sure which variant of BER is used in Microsoft's remote desktop protocol but they certainly require 65535 to be encoded as 02 02 ff ff. Although I'm not a fan of Microsoft, it sounds quite strange that they are wrong about.

I've tried to transform 65535 value to achieve what is expected but had no luck. It seems I'll have to use something else.

[Samuel-Tyler]

It's definitely not -1?

Do you have any ASN.1 specs or other documents I may look at as a reference?

[pedjaman]

The best I can provide is
[MS-RDPBCGR].pdf
wich represents MS RDP protocol specification.

Check page 328/430 (raw packet data). At position 0x29 is a sequence 02 02 FF FF
Such sequence has been explained on the next page (329/430), under section Connect-Initial::targetParameters, value for DomainParameters::maxMCSPDUSIze = 65535;

Please find attached asn file here describing Connect-Initial and other objects:
mcs-protocol.asn.zip

BER encoding has been used for data in question.

[Samuel-Tyler]

I assume this is caused by the sign constraint (maxMCSPDUsize INTEGER (0..MAX), which unfortunately this library does not support.

[pedjaman]

Ok. I've read somewhere that all integers should be encoded as unsigned in BER. But I'm not sure where I read that. Anyways thanks for the clarification. Unfortunately I will have to try another approach

…

On Fri, Apr 23, 2021, 16:08 Samuel-Tyler ***@***.***> wrote: I assume this is caused by the sign constraint (maxMCSPDUsize INTEGER (0..MAX), which unfortunately this library does not support. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJKNHZZTEARV7PGDWMYLQTTKF5OZANCNFSM43LDAKKQ> .

[Samuel-Tyler]

Ok, thank you for taking the time to try the library.

Maybe some time in the future I will add support for unsigned integers.