TCAP_MAP not calculating 'Constructor EOC' in TCAP transaction

[stenh0use]

I've been using the pycrate and sctp libraries to build a mock AuC for lab testing purposed and have discovered a bug in the way that the TCAP_MAP library calculates the hex for the TCAP section.

CONSTRUCTOR EOC: 0x0000 is missing at the end of both Constructor fields in the TCAP part.

This also means that the CONSTRUCTOR Tag Length is also miss calculated as it doesn't include the padding.

I'm not sure how to fix this in the pycrate library but basically what this means is any packet generated by the library is missing the padding and the length. Wireshark will display the information but I found that the System under test would reject the packets with an error telling me that the Transaction Portion was badly formatted.

I've provided some example code demonstrating the in hex and the out hex miss match. Any help would be greatly appreciated.

from pycrate_asn1dir import TCAP_MAP from binascii import hexlify, unhexlify

tcap_map_hex = '6581aa4804840001ff4904a50500016b2a2828060700118605010101a01d611b80020780a109060704000001000e03a203020100a305a1030201006c80a26c0201013067020138a380a180305a04104b9d6191107536658cfe59880cd2ac2704104b8c43a2542050120467f333c00f42d804108c43a2542050120467f333c00f42d84b041043a2542050120467f333c00f42d84b8c0410a2551a058cdb00004b8d79f7caff5012000000000000'

tcap_map = TCAP_MAP.TCAP_MAP_Messages.TCAP_MAP_Message

tcap_map.from_ber(unhexlify(tcap_map_hex))

print(hexlify(tcap_map.to_ber())) b'6581a44804840001ff4904a50500016b2a2828060700118605010101a01d611b80020780a109060704000001000e03a203020100a305a1030201006c6aa2680201013063020138a35ea15c305a04104b9d6191107536658cfe59880cd2ac2704104b8c43a2542050120467f333c00f42d804108c43a2542050120467f333c00f42d84b041043a2542050120467f333c00f42d84b8c0410a2551a058cdb00004b8d79f7caff5012'`

The sample packets the hex was generated from this trace: https://pcapr.net/view/nos/2011/6/4/20/gprs_ms_log.pcap.html

example trace: sendAuthenticationInfo.zip

[p1-bmu]

Thank for your feedback.

I am not sure to understand exactly what is your issue. TCAP-MAP is using ASN.1 BER. In BER, there are multiple ways to encode constructed objects (e.g. SEQUENCE, SET). One of it consists in using indefinite length (i.e. null length) and an end-of-content marker field at the end of the encoding, this is this encoding which is also enforced in CER. Use of this end-of-content marker is however not mandated in BER, especially when the length prefix is accurately calculated over the content. This is explained in ITU-T X.690, section 8.1.5.

So back to your issue: do you really think the TCAP-MAP messages generated by pycrate are not compliant with BER ? If yes, please precise. Otherwise, if this is only an issue with your "System under test", you can configure pycrate's BER by setting appropriate values in the class attributes of ASN1CodecBER (see https://github.com/P1sec/pycrate/blob/383fd140a60ab5ada688aaec73a122117c879b80/pycrate_asn1rt/codecs.py#L1042).

For instance:

from pycrate_asn1rt.codecs import ASN1CodecBER
ASN1CodecBER.ENC_LUNDEF = True

[stenh0use]

Hi Benoit,

Thank you for taking the time to look at my problem and giving a detailed explanation. I'm pretty new to this packet generation down at such a low level and don't fully understand it.

I have implemented the configuration parameter as you suggested, and it did solve my problem, as the system under test is now accepting packets as valid TCAP. I did think it was interesting though that the input hex is still different to the output hex as shown below.

Thank you for the info, I would like to open source this project of mine at some stage as it might be useful for other people.

from pycrate_asn1dir import TCAP_MAP from binascii import hexlify, unhexlify

from pycrate_asn1rt.codecs import ASN1CodecBER ASN1CodecBER.ENC_LUNDEF = True

input = '6581aa4804840001ff4904a50500016b2a2828060700118605010101a01d611b80020780a109060704000001000e03a203020100a305a1030201006c80a26c0201013067020138a380a180305a04104b9d6191107536658cfe59880cd2ac2704104b8c43a2542050120467f333c00f42d804108c43a2542050120467f333c00f42d84b041043a2542050120467f333c00f42d84b8c0410a2551a058cdb00004b8d79f7caff5012000000000000'

tcap_map = TCAP_MAP.TCAP_MAP_Messages.TCAP_MAP_Message tcap_map.from_ber(unhexlify(input))

output = hexlify(tcap_map.to_ber()) print(output) b'65804804840001ff4904a50500016b802880060700118605010101a080618080020780a180060704000001000e030000a2800201000000a380a1800201000000000000000000000000006c80a2800201013080020138a380a180308004104b9d6191107536658cfe59880cd2ac2704104b8c43a2542050120467f333c00f42d804108c43a2542050120467f333c00f42d84b041043a2542050120467f333c00f42d84b8c0410a2551a058cdb00004b8d79f7caff50120000000000000000000000000000'

[p1-bmu]

BER is a set of encoding rules with many alternatives : there can be multiple encodings for the same value. This is the reason why re-encoding a given value may not provide the same buffer as originally decoded.