asn1c: Decoding an OCTET STRING with lower bound limit on its size fails for uper_decode() #135
Comments
|
I think your code is buggy. One of the problems it has is that the upper limit on the octet string size is 81920, while your This is my fork of asn1c, whose only difference is that a lot of the PRs that have not been applied/merged to the main repo, are applied to mine (and when there's a conflict between those PRs that I chose to apply, I take care of it :)). But probably the main repo would handle this correctly too... |
|
@mouse07410 thank you very much for the feedback. In What version of the In |
As I said - I'm using my fork https://github.com/mouse07410/asn1c.git of this repo. As I said, the main difference is that my fork has most of the outstanding PRs applied, plus some minor fixes.
Yes of course.
Of course.
What sense does make to make a test that always fails?! Since the size of your image (as I said) is 831368, obviously it is not going to pass through an upper bound filter that cuts above 81920. 831368 is greater than 81920. As for your other file aptly named "bad_data", I can confirm the problem (it does not get properly encoded/decoded), but the actual constraint statement has nothing to do with it: Note that there's no "constraint failed" message. Also note that More investigation needed. |
You have changes, enough said.
Making sure constraints are honored. Since the error I suspected had to do with the size constraints.
Never said there is.
Since changing the lower limit, changes the behavior of the code.. then there is something to do with it.
I tested another file same size as |
Interesting. I notice that the error message above does not seem to be produced by any of the |
In |
UpdateI'm not sure where to dig. I still am not enamored by your sample program, but it does look like [UA]PER encoder/decoder is broken. @vlm that's your code - I'd appreciate if you could step in here. Here's the log that should be self-describing enough (and if not - I'd be happy to explain). Why I think it's probably having problems in your PER code: Complete failure documentationASN.1 sourceInput dataRandom data I'm feeding the encoder/decoder (file itself is hex-encoded for ease of visual inspection): InvocationTest-program invocation: UPER-encoded file:Complete log of my test-program (includes encoding):Converter-sample output (decoding that file): |
Update2To alleviate any possibility of my (or @xeirwn 's) code being the culprit, I've created a clean DER-encoded file. @vlm, please step in. Scenario
FileScreen log@ikarso, @persandstrom - you seem to be using PER (and this problem manifests with APER as well, same way), so you may want to pitch in too. It doesn't seem to be related to what we're doing, because the original reporter used the unmodified |
|
I am getting more and more confused. I wrote a small program to encode and decode a similar PDU (except for the same of simplicity I set upper limit to 100 instead of 81920). It all worked smoothly with random data, correctly refusing to process PDU when constraints were violated. Here's the log of conversion of the DER-encoded file that failed in the previous post ( ASN.1 module: |
|
I also found that when I define the upper limit for the OCTET STRING in the ballpark of Here's the ASN.1: In the failing cases, the encoding starts with the length byte, like hex In the successful encoding and decoding cases, the UPER-encoded PDU starts with hex It's rather disappointing that those who (presumably) know PER and |
|
Appears fixed in my fork (thanks, @velichkov). @xeirwn feel free to test. |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello guys,
I've noticed that when I set a
lower boundlimit on the size of anoctet string, it fails to decode it.To reproduce this scenario I created a small but full example that is located here.
The example is an application that uses the code generated by
asn1cand has the following behavior:octet stringusingOCTET_STRING_fromBuf()ASN.1structure usinguper_encode_to_new_buffer(), afterasn_check_constraints()succeedsuper_decode()Methodology
To create/view the bug use this
ASN1data structure as input to theasn1ccompiler:To hide the bug, use:
The only difference between the two versions is the use of a lower limit constraint on the size of the OCTET string.
Compilation command for asn1c
From folder
asn1c_image/asn1we used the following command:Version of asn1c
'ASN.1 Compiler, v0.9.28'
Samples
Inside the archive, there are two files [
test_01.png,bad_data.bin].test_01.pngis larger than 80K so it should always fail.bad_data.binfails only when there is a lower bound limit on the sizeThe text was updated successfully, but these errors were encountered: