asn1c | The ASN.1 Compiler - ASN | Cryptography library

You need to compile with -fwide-types flag.

-fwide-types Use the wide integer types (INTEGER_t, REAL_t) instead of ma-chine’s native data types (long, double).

The problem is that most of the INTEGER fields of RSAPrivateKey contain really big numbers that not fit in long type that is being used by default.

Without -fwide-types

I am using the c code generated by asn1c from the TCAP protocol specification

Which asn1c are you using (git commit id) and where do you get it from as there are quite a log of forks out there?

While the message type ("Begin", in this case), is correctly detected, but other paramters are not parsed.

How do you know that Begin is correctly detected?

Using other encoding rules, i.e., aper_decode() and uper_decode(), also fails.

There is no point in trying other encodings as they are not binary compatible.

I would be thankful if anyone can describe how to use the auto-generated c code for decoding (parsing) a byte string of TCAP messages.

You are using it correctly and probably there is a bug somewhere in the BER decoder.

You could try compiling with -DASN_EMIT_DEBUG=1 in CFLAGS (or -DEMIT_ASN_DEBUG=1 depending on the asn1c version you are using) to get some more debug messages.

The invokeId and opCode parameters are truely detected, and the parser gives us a buffer named as invokeParameters which is of type ANY.

The question is how to decode (parse) invokeParameters?

You need to call ber_decode with the appropriate type (depending on the operation code) and the content of the ANY buffer. From ANY.h

You cannot change LDAP asn1 specification to solve your problem.

For example: when you decode a BindRequest, to decode name (of type LDAPDN) ber_decode expects the tag of OCTET STRING. If you change the spec as you suggest, you will expect the tag of UTF8String and receive the tag of OCTET STRING (hence the error)

Unfortunately, with generic tools, there is no way to display a human readable text while the specification is using OCTET STRING

You have several options:

1. Use a newer version of asn1c from this PR (still not merged)

2. Copy the EXTERNAL.h from the osmocom repository

3. Rename EXTERNAL to EXTERNALt in all asn files and add the following in the asn files that has EXTERNALt.

You don't need to compile all asn files in asn sub-directory. There is a rebuild script that you could use.

You need to read more about ASN.1.

The problem that it solves is that things on different computers are not all the same. If you want to send data from an embedded x86 DOS system (16 bit little endian int) to a SPARC (32 bit big endian int) then you can't just use int on both sides.

There are two main parts to ASN.1:

• the language description i.e., the ASN.1 grammar
• the encoding rules that apply the grammar to convert host data to and from encoded data

There are some examples on the asn1c web site.

Luke,

You're probably going to have better luck with an actual ASN.1 compiler—there are several commercially available, but Lev Walkin's free ASN.1 Compiler might fit the bill for your needs.

I'm not very familiar with OpenSSL, but a quick browse through the asn1t.h source (among others) doesn't suggest that there's builtin support for declaring an extensible sequence. You're probably more motivated than I to look, but I confess I wouldn't be surprised to find they didn't include it. Extensibility can be a hard problem to solve, especially if you're relying on preprocessor macros for code generation.

In any case, relying on the OpenSSL code could cause problems in the future anyway: when the APIs or code change, you'll be forced to manually update all of your code to match. A code generator would (probably) do a better job of maintaining API (and ABI) compatibility while allowing somewhat more flexible code generation and language choices.