Zlib inflate unexpected decompression errors - c++

I am struggling for a few weeks with zlib inflate alghorithm.
I would like to decompress packets from popular game called Tibia. They have compressed it with zlib inflate alghorithms. But it seems something is changed. Can you check it, maybe you will spot something I am missing?
Packet compressed: - cannot be inflated directly (its raw huffman fixed coding - probably)
DA 22 A6 CB 10 99 5F AA 50 9C 9A AA 90 A8 90 05 B4 2F B5 44 41 C3 B1 28 D7 CA 50 53 8F CB B3 44 A1 3C 35 33 3D A3 58 C1 C8 44 CF C0 40 21 BF 4A 0F
Packet decompressed using Reverse Engineering:
B4 16 2D 00 59 6F 75 20 73 65 65 20 61 20 6A 61 63 6B 65 74 20 28 41 72 6D 3A 31 29 2E 0A 49 74 20 77 65 69 67 68 73 20 32 34 2E 30 30 20 6F 7A 2E
Decompressed packet compressed with zlib deflate using CyberChef deflate / php deflate functions:
db 22 a6 cb 10 99 5f aa 50 9c 9a aa 90 a8 90 95 98 9c 9d 5a a2 a0 e1 58 94 6b 65 a8 a9 c7 e5 59 a2 50 9e 9a 99 9e 51 ac 60 64 a2 67 60 a0 90 5f a5 07 00
Data matches in a few places, but generally, its different. Do you know what could be the case?
I attach a picture from RE an inflating function: Screenshot from IdaPro
Here are packets in correct order:
http://wklej.org/hash/6aee9e223f0/txt/ - inflated correctly
http://wklej.org/hash/bd371e7f510/txt/ - inflated correctly
http://wklej.org/hash/8f15935dc15/txt/ - inflated correctly
And here is the packet that cannot be inflated...
CA059BC6043619009FC9FFFFE831

Your packet that cannot be inflated is likely part of a longer stream of compressed data, with other packets preceding it and following it. You need to decompress all of them as a single stream for the decompression to succeed.
Your first example is a portion of a deflate stream that references data that preceded it. So it is part of a larger deflate stream. You need all of the compressed data that preceded that piece in order to decompress that piece. Your last example (CA05...) also references preceding data, so it too is part of a larger stream with compressed data that preceded it.

Related

How to replace gzip compressed data with other data and still have a valid .gz file?

I'm experimenting. I created a .txt file with the word hi and run gzip test.txt to compress it.
This gives me a file test.txt.gz with the following bytes:
1F 8B 08 08 E6 E8 3F 60 00 03 62 2E 74 78 74 00
CB C8 04 00 AC 2A 93 D8 02 00 00 00
With the software 101 editor, I found out that the first line is the header.
CB C8 04 00 are the compressed data
AC 2A 93 D8 is "CRC of the data section"
02 00 00 00 is the "size of the uncompressed input"
What I'm trying to do (I don't know if it is even possible): I want to have my own characters as "compressed" data but want the .gz file to be still valid.
I tried replacing CB C8 04 00 with 62 62 62 62 (letter 'b' 4 times) but the file is invalid then. Then I tried to replace AC 2A 93 D8, too with the CRC32 value of "bbbb", but the file is still invalid. I can't decompress it. Running gzip -d test.txt.gz returns "unexpected end of file".
Is it possible what I'm trying to do? If yes: what am I doing wrong?
CB C8 04 00 is a valid deflate stream. 62 62 62 62 is not. A gzip member is a gzip header, a valid deflate stream, and a gzip trailer.
Deflate streams are defined in RFC 1951.

JITP cert not created with mbedTLS+ATECC608A (works with moquitto_pub)

I have the following setup:
ATECC608A
mbedTLS (tested with 2.16.6 and 2.16.9)
coreMQTT
The certificate chain is the following: RootCA > SignerCA > DeviceCert. I've registered both RootCA and SignerCA as CAs in the AWS IoT Console
I setup the chain in mbedTLS with the following:
/* Extract the device certificate and convert to mbedtls cert */
if (0 != atca_mbedtls_cert_add(&device_cert_chain, &g_cert_def_2_device))
{
printf("Failed to parse device cert from device\n");
goto exit;
}
/* Extract the signer certificate, convert, then attach to the chain */
if (0 != atca_mbedtls_cert_add(&device_cert_chain, &g_cert_def_1_signer))
{
printf("Failed to parse signer cert from device\n");
goto exit;
}
When connecting to my ats-endpoint with that stack, the TLS handshake is successul: the device cert and signerCA are presented and AWS presents its cert chain as well. mbedTLS seems to be happy:
....[SNIP]
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:2898: <= parse server hello done
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:3522: client state: 7
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2753: => flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2765: <= flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5343: => write certificate
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: own certificate #1:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: cert. version : 3
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: serial number : 40:F7:D9:46:59:6E:2F:58:E6:87:04:4F:D5:6E:86:03
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: issuer name : O=CompanyName, CN=signer.companyname.com FFFF
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: subject name : O=CompanyName, CN=pu0223528E47B3461DEE
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: issued on : 2021-01-14 21:00:00
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: expires on : 3000-12-31 23:59:59
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: signed using : ECDSA with SHA256
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: EC key size : 256 bits
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: basic constraints : CA=false
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: key usage : Digital Signature, Key Agreement
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: value of 'crt->eckey.Q(X)' (256 bits) is:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: c7 1f a4 ea e7 ae 51 16 fb c3 0b ce 33 f1 7a af
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: f1 27 3a af a7 5d 76 76 74 58 e8 56 36 94 56 76
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: value of 'crt->eckey.Q(Y)' (255 bits) is:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: 5f a6 2e 21 53 a5 91 7d 95 f8 9e 0e f8 ce bd d9
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: c1 50 83 c2 7d 74 98 4b 66 b2 eb 9a b7 49 48 4c
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: own certificate #2:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: cert. version : 3
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: serial number : 4D:29:66:FF:B8:09:8D:39:0E:39:C8:3A:94:6E:EE:6A
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: issuer name : O=CompanyName, CN=root.companyname.com FFFF
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: subject name : O=CompanyName, CN=signer.companyname.com FFFF
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: issued on : 2020-11-09 17:55:11
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: expires on : 2070-10-28 17:44:12
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: signed using : ECDSA with SHA256
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: EC key size : 256 bits
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: basic constraints : CA=true
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: key usage : Digital Signature, Key Cert Sign, CRL Sign
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: value of 'crt->eckey.Q(X)' (256 bits) is:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: cc 63 87 d3 bd 58 08 1e c7 55 02 be a8 e1 d7 a2
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: f9 7f 62 0a 39 c6 40 45 cf 1d 83 4a 53 5e 6a e3
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: value of 'crt->eckey.Q(Y)' (255 bits) is:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: 5b be ad 83 96 10 3c 0e 5b 0b 60 32 65 5d d3 3b
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: 77 90 b2 a7 a8 cb 90 b7 49 3f 24 cd c6 6b 1f 38
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3192: => write handshake message
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3351: => write record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3428: output record: msgtype = 22, version = [3:3], msglen = 982
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: dumping 'output record sent to network' (987 bytes)
....[SNIP]
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4399: <= read record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6606: <= parse finished
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:3522: client state: 14
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2753: => flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2765: <= flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:3633: handshake: done
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:3522: client state: 15
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2753: => flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2765: <= flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6350: => handshake wrapup
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6323: => handshake wrapup: final free
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6343: <= handshake wrapup: final free
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6405: <= handshake wrapup
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8108: <= handshake
ok
TLS Session Established and a Socket is ready for an Application
I then use the created mbedtls_ssl_context to connect coreMQTT. From log, coreMQTT is able to write on the socket but AWS closes the connection.
...[SNIP]...
TLS Session Established and a Socket is ready for an Application
Initializing MQTT...ok
Connecting to the MQTT broker with params:
- identifier='testclient'
- username='?SDK=Fedora&Version=33&Platform=PC&MQTTLib=core-mqtt#v1.1.0'
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8696: => write
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3351: => write record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1443: => encrypt buf
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: dumping 'before encrypt: output payload' (85 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0000: 10 53 00 04 4d 51 54 54 04 82 00 3c 00 0a 74 65 .S..MQTT...<..te
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0010: 73 74 63 6c 69 65 6e 74 00 3b 3f 53 44 4b 3d 46 stclient.;?SDK=F
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0020: 65 64 6f 72 61 26 56 65 72 73 69 6f 6e 3d 33 33 edora&Version=33
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0030: 26 50 6c 61 74 66 6f 72 6d 3d 50 43 26 4d 51 54 &Platform=PC&MQT
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0040: 54 4c 69 62 3d 63 6f 72 65 2d 6d 71 74 74 40 76 TLib=core-mqtt#v
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0050: 31 2e 31 2e 30 1.1.0
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1572: dumping 'additional data for AEAD' (13 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1572: 0000: 00 00 00 00 00 00 00 01 17 03 03 00 55 ............U
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1602: dumping 'IV used (internal)' (12 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1602: 0000: 91 d1 a1 52 00 00 00 00 00 00 00 01 ...R........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1604: dumping 'IV used (transmitted)' (8 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1604: 0000: 00 00 00 00 00 00 00 01 ........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1614: before encrypt: msglen = 93, including 0 bytes of padding
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1641: dumping 'after encrypt: tag' (16 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1641: 0000: db 24 89 b1 5f 7f e6 ff 78 dd c3 8b 34 99 79 1f .$.._...x...4.y.
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1779: <= encrypt buf
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3428: output record: msgtype = 23, version = [3:3], msglen = 109
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: dumping 'output record sent to network' (114 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0000: 17 03 03 00 6d 00 00 00 00 00 00 00 01 ba 08 e9 ....m...........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0010: fb f4 64 84 4e 6d 31 6e 89 3f 7b 74 e1 9a 0a af ..d.Nm1n.?{t....
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0020: 82 33 4e 7b 13 23 de ba 55 19 41 24 6e 95 14 3c .3N{.#..U.A$n..<
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0030: 2a 6e 02 67 6d 76 4d f8 32 a0 45 ca 12 a2 1a 31 *n.gmvM.2.E....1
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0040: 97 26 45 13 88 07 2c 18 13 ab 92 4b 2b 98 41 49 .&E...,....K+.AI
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0050: 03 5a 4f a9 5d 95 33 2b 68 c9 16 ee 2a ad 59 0a .ZO.].3+h...*.Y.
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0060: 7a 52 db 24 89 b1 5f 7f e6 ff 78 dd c3 8b 34 99 zR.$.._...x...4.
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0070: 79 1f y.
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2753: => flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2771: message length: 114, out_left: 114
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2777: ssl->f_send() returned 114 (-0xffffff8e)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2805: <= flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3484: <= write record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8724: <= write
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8284: => read
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4325: => read record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2534: => fetch input
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2694: in_left: 0, nb_want: 5
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2718: in_left: 0, nb_want: 5
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2720: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2740: <= fetch input
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4061: dumping 'input record header' (5 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4061: 0000: 15 03 03 00 1a .....
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4067: input record: msgtype = 21, version = [3:3], msglen = 26
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2534: => fetch input
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2694: in_left: 5, nb_want: 31
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2718: in_left: 5, nb_want: 31
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2720: ssl->f_recv(_timeout)() returned 26 (-0xffffffe6)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2740: <= fetch input
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4246: dumping 'input record from network' (31 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4246: 0000: 15 03 03 00 1a 00 00 00 00 00 00 00 01 33 90 3f .............3.?
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4246: 0010: df 0b 29 53 90 20 f1 90 14 82 84 99 e9 f6 db ..)S. .........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1792: => decrypt buf
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1879: dumping 'additional data for AEAD' (13 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1879: 0000: 00 00 00 00 00 00 00 01 15 03 03 00 02 .............
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1908: dumping 'IV used' (12 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1908: 0000: 3a e9 5a f2 00 00 00 00 00 00 00 01 :.Z.........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1909: dumping 'TAG used' (16 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1909: 0000: 3f df 0b 29 53 90 20 f1 90 14 82 84 99 e9 f6 db ?..)S. .........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2374: <= decrypt buf
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4273: dumping 'input payload after decrypt' (2 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4273: 0000: 01 00 ..
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5183: got an alert message, type: [1:0]
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5199: is a close notify message
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4383: mbedtls_ssl_handle_message_type() returned -30848 (-0x7880)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8349: mbedtls_ssl_read_record() returned -30848 (-0x7880)
I expect the first connection to fail. But in this case, the certificate does not appear in the AWS IoT console and subsequent connection attempts fail as well.
I double checked the signerCA stored and its policy. They seem fine. To ensure that this confg is correct, I manually created a certificate on my machine and signed it with my SignerCA.I then used that certificate with mosquitto_pub. The process works and my certificate appears in the AWS IoT console with the correct policy attached. Here's a log of what I'm doing:
$ openssl genpkey -out fakeDeviceCert.key -algorithm EC -pkeyopt ec_paramgen_curve:P-256
$ openssl req -new -key fakeDeviceCert.key -out fakeDeviceCert.csr
$ openssl x509 -req -in fakeDeviceCert.csr -CA ../certs/signer-FFFF.crt \
-CAkey ../certs/signer-FFFF.key \
-CAcreateserial \
-out fakeDeviceCert.pem \
-days 357335 \
-sha256
$ cat fakeDeviceCert.pem ../certs/signer-FFFF.crt > deviceCertAndCACert.crt
$ mosquitto_pub --cafile AmazonRootCA1.pem \
--cert deviceCertAndCACertcrt --key fakeDeviceCert.key \
-h <redacted>-ats.iot.eu-central-1.amazonaws.com -p 8883 -q 1 -t ji/tp \
-i deviceCert --tls-version tlsv1.2 -m '{"let-me": "in"}' -d
Doing this, I know that the policy attached to my signerCA is correct and running well.
Another verification I've done is to check that my coreMQTT connection is correct. To connect without the JITP provisioning, I extracted the device certificate from the ATECC, manually uploaded its PEM and attached a policy to the device in the AWS console.
That MQTT connection was successful (and I see the 'MQTT.Connect event in the AWS logs).
Here's the relevant certs description. I've redacted the Issuer/Subject from the output so the signatures are incorrect:
The device cert stored in ATECC (the one that does not trigger the provisioning process):
$ openssl x509 -text -noout -in extracted_device_cert.pm
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
40:f7:d9:46:59:6e:2f:58:e6:87:04:4f:d5:6e:86:03
Signature Algorithm: ecdsa-with-SHA256
Issuer: O = CompanyName, CN = signer.companyname.com FFFF
Validity
Not Before: Jan 14 21:00:00 2021 GMT
Not After : Dec 31 23:59:59 3000 GMT
Subject: O = CompanyName, CN = pu0223528E47B3461DEE
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:c7:1f:a4:ea:e7:ae:51:16:fb:c3:0b:ce:33:f1:
7a:af:f1:27:3a:af:a7:5d:76:76:74:58:e8:56:36:
94:56:76:5f:a6:2e:21:53:a5:91:7d:95:f8:9e:0e:
f8:ce:bd:d9:c1:50:83:c2:7d:74:98:4b:66:b2:eb:
9a:b7:49:48:4c
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Agreement
X509v3 Subject Key Identifier:
4A:F0:38:0D:8E:57:76:71:A2:92:07:B7:60:1B:C7:0A:B4:7E:8B:D1
X509v3 Authority Key Identifier:
keyid:4C:E5:14:B2:9D:3E:8F:29:43:34:45:83:34:C2:F4:09:53:60:13:99
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:5c:86:11:4b:79:07:ce:34:32:61:6d:00:2a:7c:
43:75:16:e9:b6:ae:13:21:91:25:5f:1b:80:c3:b2:41:93:0d:
02:20:31:fc:4c:6d:5e:f0:54:46:da:ae:d7:aa:b7:f8:6a:c8:
21:ba:45:62:31:7b:55:f7:b3:38:af:7c:97:25:81:72
And the manually generated cert that correctly triggers the JITP:
$ openssl x509 -text -noout -in fakeDeviceCert.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
7a:50:78:20:5e:dc:de:56:74:55:fb:fa:6e:61:ed:13:ed:c9:0a:b7
Signature Algorithm: ecdsa-with-SHA256
Issuer: O = CompanyName, CN = signer.companyname.com FFFF
Validity
Not Before: Jan 15 08:22:44 2021 GMT
Not After : May 23 08:22:44 2999 GMT
Subject: O = CompanyName, CN = pu010203040506070811
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:62:1e:35:5a:97:ec:7f:f7:82:6e:67:7a:ac:a5:
1b:b0:a3:bc:42:08:cb:0e:fe:ad:07:46:0c:dd:8c:
ca:b3:60:8f:e3:0b:59:a4:b3:e5:6b:a5:22:8e:49:
d3:3a:1e:76:43:7b:7a:cd:dd:0d:dc:52:1f:8f:83:
ee:10:e0:fb:1a
ASN1 OID: prime256v1
NIST CURVE: P-256
Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:8f:3a:b4:e4:25:98:3c:79:23:65:e4:1b:68:
75:19:11:27:91:df:66:22:ea:c1:13:06:72:6f:e0:5d:3d:13:
49:02:21:00:e2:7e:2b:92:55:68:98:09:b9:a4:e9:7b:2a:7c:
48:2a:bb:23:c7:45:d2:96:ec:df:9b:62:a8:9d:7a:98:06:fe
Here's the signerCA description from AWS (with some redacted fields between <>)
$ aws iot describe-ca-certificate --certificate-id <my-ca-cert-id>
{
"certificateDescription": {
"certificateArn": "arn:aws:iot:eu-central-1:<accountID>:cacert/<ca-id>",
"certificateId": "<ca-id>",
"status": "ACTIVE",
"certificatePem": "-----BEGIN CERTIFICATE-----\n<pem-content>-----END CERTIFICATE-----\n",
"ownedBy": "<owner-account-id>",
"creationDate": "2021-01-11T10:40:58.736000+01:00",
"autoRegistrationStatus": "ENABLE",
"lastModifiedDate": "2021-01-14T23:38:52.132000+01:00",
"customerVersion": 2,
"generationId": "09eb8608-630c-4632-a1ef-0879f6f2dd6f",
"validity": {
"notBefore": "2020-11-09T18:55:11+01:00",
"notAfter": "2070-10-28T18:44:12+01:00"
}
},
"registrationConfig": {
"templateBody": "{\"Parameters\": {\"AWS::IoT::Certificate::CommonName\": {\"Type\": \"String\"}, \"AWS::IoT::Certificate::Id\": {\"Type\": \"String\"}}, \"Resources\": {\"thing\": {\"Type\": \"AWS::IoT::Thing\", \"Properties\": {\"ThingName\": {\"Ref\": \"AWS::IoT::Certificate::CommonName\"}, \"AttributePayload\": {\"version\": \"v1\"}}}, \"certificate\": {\"Type\": \"AWS::IoT::Certificate\", \"Properties\": {\"CertificateId\": {\"Ref\": \"AWS::IoT::Certificate::Id\"}, \"Status\": \"ACTIVE\"}}, \"policy\": {\"Type\": \"AWS::IoT::Policy\", \"Properties\": {\"PolicyDocument\": \"{\\\"Version\\\": \\\"2012-10-17\\\", \\\"Statement\\\": [{\\\"Effect\\\": \\\"Allow\\\", \\\"Action\\\": [\\\"iot:Connect\\\", \\\"iot:Publish\\\", \\\"iot:Subscribe\\\", \\\"iot:Receive\\\", \\\"iot:GetThingShadow\\\", \\\"iot:DeleteThingShadow\\\", \\\"iot:UpdateThingShadow\\\"], \\\"Resource\\\": [\\\"*\\\"]}]}\"}}}}",
"roleArn": "arn:aws:iam::<account-id>:role/JITP-Role"
}
}
I'm a bit lost and have a few questions:
mbedTLS seems to present the two concatened certificates. Would the handshake be successful if one them was not correct or if mbedTLS was misconfigured?
Could the X509v3 extensions be responsible for the JITP failure? The device cert has them, while the manually-generated one has not.
Is there a way to log mutual authentication failures in Cloudwatch?
Is there anything that I missed?
(EDIT: If I don't include the signerCA in the cert chain when connecting, the TLS handshake is still successful. Of course, in that case I expect the JITP process to fail because AWS cannot find the associated CA).
EDIT2:
I've tried to connect with mosquitto and a certificate that is much closer to the one used by the ATECC (same algos and same X509v3 extensions). The outcome is the same: the manually generated one with mosquitto can trigger the JITP while the one from ATECC cannot.
Got it. I was retrieving the public key of my root certificate in the wrong slot in the ATECC (ouch). This was resulting in a slightly different signerCA to be generated by the atcacert_def_t and the template at runtime.
I missed it because all my tooling in Python was fetching the right slot while the C version was not kept perfectly in sync.

Google Deployment Manager stored runtime-config variables appear corrupted

I'm having trouble with encrypted base64 encoded values I'm using in Google Deployment Manager via runtimeconfig.v1beta1.config resource declarations.
After I perform the deployment, the value that I stored using Deployment Manager appear to be quite different to what I retrieve using gcloud beta runtime-configs. As a result, I can't decrypt the value.
First I encrypted and base64 encoded some secret text:
$ echo "secret"|gcloud kms encrypt --key my-crypto-key \
--keyring my-keyring --location australia-southeast1 \
--plaintext-file - --ciphertext-file - | base64 -w0
CiQAsOSNmVXBs2ayUjRePnE5+Oi5dUPuVvjn6UKKUXgxMTA56koSMABDkVUGnXlocFgdUEsQ5qLCF3PVIz5zit+ZCSXjSvNzEAO5XRv6WBRkxBJMjVcheg==
Which I then store in a deployment manager YAML file:
resources:
- name: my-config
type: runtimeconfig.v1beta1.config
properties:
config: my-config
description: "A demo configuration"
- name: dummy-secret
type: runtimeconfig.v1beta1.variable
properties:
parent: $(ref.my-config.name)
variable: 'dummy/secret'
value: "CiQAsOSNmVXBs2ayUjRePnE5+Oi5dUPuVvjn6UKKUXgxMTA56koSMABDkVUGnXlocFgdUEsQ5qLCF3PVIz5zit+ZCSXjSvNzEAO5XRv6WBRkxBJMjVcheg=="
Then I create the deployment (which completes without errors or warnings):
$ gcloud deployment-manager deployments create my-config \
--config my-config.yaml
But when I try extracting the variable value, it is completely different from what I stored:
$ gcloud beta runtime-config configs variables \
get-value 'dummy/secret' --config-name my-config|base64 -w0
CiQAPz8/P1U/P2Y/UjRePnE5Pz8/dUM/Vj8/P0I/UXgxMTA5P0oSMABDP1UGP3locFgdUEsQPz8/F3M/Iz5zPz8/CSU/Sj9zEAM/XRs/WBRkPxJMP1cheg==
This is repeatable / reproducible and I haven't a clue what I'm doing wrong. I don't have this problem using gcloud beta runtime-config variables set followed by get-value.
Looking at the decoded base64 binary of your content, we notice that all the bytes with values >= 0x80 have been changed to 0x3F, ASCII '?'. We suspect you're passing the binary data through the shell or some other pipe which isn't binary-clean.
Corrupted value:
dierks#dierks:~$ base64 -d | hexdump -C
CiQAPz8/P1U/P2Y/UjRePnE5Pz8/dUM/Vj8/P0I/UXgxMTA5P0oSMABDP1UGP3locFgdUEsQPz8/F3M/Iz5zPz8/CSU/Sj9zEAM/XRs/WBRkPxJMP1cheg==
00000000 0a 24 00 3f 3f 3f 3f 55 3f 3f 66 3f 52 34 5e 3e |.$.????U??f?R4^>|
00000010 71 39 3f 3f 3f 75 43 3f 56 3f 3f 3f 42 3f 51 78 |q9???uC?V???B?Qx|
00000020 31 31 30 39 3f 4a 12 30 00 43 3f 55 06 3f 79 68 |1109?J.0.C?U.?yh|
00000030 70 58 1d 50 4b 10 3f 3f 3f 17 73 3f 23 3e 73 3f |pX.PK.???.s?#>s?|
00000040 3f 3f 09 25 3f 4a 3f 73 10 03 3f 5d 1b 3f 58 14 |??.%?J?s..?].?X.|
00000050 64 3f 12 4c 3f 57 21 7a |d?.L?W!z|
00000058
Original value:
dierks#dierks:~$ base64 -d | hexdump -C
CiQAsOSNmVXBs2ayUjRePnE5+Oi5dUPuVvjn6UKKUXgxMTA56koSMABDkVUGnXlocFgdUEsQ5qLCF3PVIz5zit+ZCSXjSvNzEAO5XRv6WBRkxBJMjVcheg==
00000000 0a 24 00 b0 e4 8d 99 55 c1 b3 66 b2 52 34 5e 3e |.$.....U..f.R4^>|
00000010 71 39 f8 e8 b9 75 43 ee 56 f8 e7 e9 42 8a 51 78 |q9...uC.V...B.Qx|
00000020 31 31 30 39 ea 4a 12 30 00 43 91 55 06 9d 79 68 |1109.J.0.C.U..yh|
00000030 70 58 1d 50 4b 10 e6 a2 c2 17 73 d5 23 3e 73 8a |pX.PK.....s.#>s.|
00000040 df 99 09 25 e3 4a f3 73 10 03 b9 5d 1b fa 58 14 |...%.J.s...]..X.|
00000050 64 c4 12 4c 8d 57 21 7a |d..L.W!z|

How is running the asset_management.go different from running a simple chaincode like chaincode_example02.go

The simple workflow for deploying/invoking a chaincode (to my knowledge) is :
Deploy a chaincode(smart contract) on the blockchain
This brings up a docker container on all peers that has the chaincode running in it
Invoke some function
This type of function changes the values of variables in chaincode state
For asset_management.go, the chaincode can be tested by running go test in the asset_management chaincode directory . But this does not really bring up a docker container(or does it ?) that runs the asset_management chaincode.
Whats the right way to deploy/invoke this chaincode and how is it different from deploying/invoking chaincodes using the REST interface(like we do for chaincode_example02)
The chaincode workflow you mentioned is correct, just one detail regarding variables in chaincode state: the variables are stored in a global key-value collection named World State, which is accessed through the invocation of a chaincode and it is access protected.
Now, what you are doing with go test is running the code in asset_management_test.go. If you look at this code, you will see that it basically starts a VP and a CA and then tries sending transactions to tests that the chaincode works. For example:
// Now create the Transactions message and send to Peer.
transaction, err := txHandler.NewChaincodeExecute(chaincodeInvocationSpec, tid)
You could also code a test file for the chaincode_example02 and test it.
Or you can also deploy the asset_management chaincode the same way you use to deploy chaincode_example02. Which can be using a chaincode development environment or a development network.
Important: asset_management chaincode is used to test the invocation access control, so it is fairly complex. Invoking its methods means using digital signatures to check the identity of the chaincode invoker. You can check the asset_management_test file to see how it is done.
The list of steps for anybody who would like to run “asset_management_with_roles” manually:
Checkout Fabric, run vagrant from “devenv” folder
ssh to the started container.
Reset Fabric’s configuration:
rm /var/hyperledger/production
Enable attribute certificate authority in membersrvc.yaml
aca.enabled: true
Enable security in core.yaml
security.enable: true
Switch log level for “node” to “debug” in core.yaml (optional. not necessary if you know the certificates)
logging.node: debug
Run membersrvc in background:
nohup membersrvc &> /tmp/membersrvc.log &
Run peer service
peer node start
Verify if users “assigner, bob, alice” are in membersrvc.yaml, according to the comment in this example we will work with:
// This example implements asset transfer using attributes support and specifically Attribute Based Access Control (ABAC).
// There are three users in this example:
// - alice
// - bob
// - assigner
//
// This users are defined in the section “eca" of asset.yaml file.
// In the section “aca" of asset.yaml file two attributes are defined to this users:
// The first attribute is called ‘role' with this values:
// - alice has role = client
// - bob has role = client
// - assigner has role = assigner
//
// The second attribute is called ‘account' with this values:
// - alice has account = 12345-56789
// - bob has account = 23456-67890
Open another ssh terminal with vagrant and login to the network:
peer network login assigner -p Tc43PeqBl11
peer network login bob -p NOE63pEQbL25
peer network login alice -p CMS10pEQlB16
8. Deploy chaincode to the network using “assigner” security context:
curl -XPOST -d ‘{“jsonrpc": "2.0", "method": "deploy", "params": {"type": 1,"chaincodeID": {"path": "github.com/hyperledger/fabric/examples/chaincode/go/asset_management_with_roles","language": "GOLANG"}, "ctorMsg": { "args": ["init"] }, "metadata":[97, 115, 115, 105, 103, 110, 101, 114] ,"secureContext": "assigner"} ,"id": 0}' http://localhost:7050/chaincode
metadata contains utf-8 encoded string “assigner”. This string will be saved in a ledger and only user with such role will be able to execute “assign” function in smart contract.
In order to keep example readable lets save chaincode id in local variable:
export HASH=7adc030881c07c39d2edac0b1560bf7cf2b7f0a4bce74fe7e6144e3f36e1bf2d176093d4c23ba58712a9589d9600e6d9ef596a1521a4c5227c222d8af2bf16c8
Starting from this moment user “assigner” can create new assets for bob and alice, we just have to find their certificates.
let’s run query command for any random asset name under “bob” securityContext:
curl -XPOST -d '{"jsonrpc": "2.0", "method": "query", "params": {"type": 1, "chaincodeID": {"name": "'"$HASH"'"}, "ctorMsg": {"args": ["query", "myasset"]}, "secureContext": "bob", "attributes": ["role", "account"]}, "id": 1}' http://localhost:7050/chaincode
(IMPORTANT: without “attributes”: [“role”, “account”] no attributes will be loaded into transactions certificate)
As far as “peer” is started in debug mode, bob’s certificate will be printed in peer log output. Try to find row “[client.bob] Adding new Cert” and copy certificate value:
30 82 02 90 30 82 02 37 a0 03 02 01 02 02 10 2f 9e 4e da c9 e9 4e 97 b1 58 24 78 4e 15 05 f4 30 0a 06 08 2a 86 48 ce 3d 04 03 03 30 31 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 14 30 12 06 03 55 04 0a 13 0b 48 79 70 65 72 6c 65 64 67 65 72 31 0c 30 0a 06 03 55 04 03 13 03 74 63 61 30 1e 17 0d 31 36 30 39 31 39 32 31 32 34 31 39 5a 17 0d 31 36 31 32 31 38 32 31 32 34 31 39 5a 30 45 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 14 30 12 06 03 55 04 0a 13 0b 48 79 70 65 72 6c 65 64 67 65 72 31 20 30 1e 06 03 55 04 03 13 17 54 72 61 6e 73 61 63 74 69 6f 6e 20 43 65 72 74 69 66 69 63 61 74 65 30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a 86 48 ce 3d 03 01 07 03 42 00 04 78 8f f2 11 55 a3 5a 8d f1 b5 4f 38 e4 94 e4 67 b0 47 7f e0 07 04 b8 fb 12 ee 86 17 8a 05 55 e3 98 f6 c1 af 59 ee 2d 54 a9 c5 36 22 cd fa a8 1b ce ba e0 26 fd 73 40 af 20 5d 15 65 89 9c 62 64 a3 82 01 1b 30 82 01 17 30 0e 06 03 55 1d 0f 01 01 ff 04 04 03 02 07 80 30 0c 06 03 55 1d 13 01 01 ff 04 02 30 00 30 0d 06 03 55 1d 0e 04 06 04 04 01 02 03 04 30 0f 06 03 55 1d 23 04 08 30 06 80 04 01 02 03 04 30 10 06 06 2a 03 04 05 06 0a 04 06 63 6c 69 65 6e 74 30 15 06 06 2a 03 04 05 06 0b 04 0b 32 33 34 35 36 2d 36 37 38 39 30 30 4d 06 06 2a 03 04 05 06 07 01 01 ff 04 40 fc c2 07 dd ee ac 8c 76 84 12 07 d2 e0 a6 da b3 06 c9 5b 5b 41 57 a3 f3 a2 f7 59 e2 ed 02 02 7e 56 46 f5 bc 24 00 0a 2e 18 b4 a6 b7 a6 c3 8d ca 15 13 a7 98 42 98 8f 9b 85 a2 d1 6a 77 0d da e8 30 3a 06 06 2a 03 04 05 06 08 04 30 ff d2 ab 7f c8 2d 98 c4 3f c9 f7 05 12 07 01 3a 36 69 f8 ee d1 c4 27 16 48 3e ee ed db b9 b6 3c d6 e5 1a 3e 0b 7d f0 19 1c 81 03 12 f6 7b d5 3e 30 23 06 06 2a 03 04 05 06 09 04 19 30 30 48 45 41 44 72 6f 6c 65 2d 3e 31 23 61 63 63 6f 75 6e 74 2d 3e 32 23 30 0a 06 08 2a 86 48 ce 3d 04 03 03 03 47 00 30 44 02 20 49 52 26 bd b8 f4 a0 98 c6 ff fc 56 3e b5 b0 12 ee ec b7 46 90 55 b1 17 99 29 fe df 80 2e 95 b9 02 20 3b 7f dd 32 88 56 ae a1 14 60 54 60 95 61 fb d1 bc 0c f7 e0 61 f2 e9 0b 46 35 6a 36 61 c9 b8 f0
Certificate should be based64 encoded. As an option we can use http://tomeko.net/online_tools/hex_to_base64.php?lang=en
Insert certificate into “Hex string” field, click “convert” button, and result will be in “Output (base64)”:
MIICkjCCAjigAwIBAgIRAO9nis6q+khvv6TMvhKbmacwCgYIKoZIzj0EAwMwMTELMAkGA1UEBhMCVVMxFDASBgNVBAoTC0h5cGVybGVkZ2VyMQwwCgYDVQQDEwN0Y2EwHhcNMTYwOTE5MjAyMDE5WhcNMTYxMjE4MjAyMDE5WjBFMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLSHlwZXJsZWRnZXIxIDAeBgNVBAMTF1RyYW5zYWN0aW9uIENlcnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqop3N0IpJaLVaRuYioSuHPvyWX3OY9vo4I1YYw1YophcFGFt3fN0X6bDlufUZ5/u81JMmZHozduREnNzM1n+gaOCARswggEXMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMA0GA1UdDgQGBAQBAgMEMA8GA1UdIwQIMAaABAECAwQwEAYGKgMEBQYKBAZjbGllbnQwFQYGKgMEBQYLBAsyMzQ1Ni02Nzg5MDBNBgYqAwQFBgcBAf8EQNbPDmdWcOogMkZrlxbRJw/06jg4Ai88KW2+BsuxUnIH5FSa3OY7ZsXJLpceIN4SeEWKDKDsIPCo2wm6cUMYApIwOgYGKgMEBQYIBDDikSBKFYtTmYZRhtVDPhnIoSvefWHQ5Vx5oahIRbG8d/w4J1YTrtVoEwa2jikAqJowIwYGKgMEBQYJBBkwMEhFQURyb2xlLT4xI2FjY291bnQtPjIjMAoGCCqGSM49BAMDA0gAMEUCIQCrUQw2moOA5RFEx/780so4uEOV5esX3fy/It0t2la7gQIgGGVoDoM2kSxWH7TtV4T8W4pY6tN/LXu8XpKWb8+eF0k=
"assign" method expects 2 parameters the Name for asset and owner certificate. New asset can be created using:
curl -XPOST -d '{"jsonrpc": "2.0", "method": "invoke", "params": {"type": 1, "chaincodeID": {"name": "'"$HASH"'"}, "ctorMsg": {"args": ["assign", "myasset", "MIICkjCCAjigAwIBAgIRAO9nis6q+khvv6TMvhKbmacwCgYIKoZIzj0EAwMwMTELMAkGA1UEBhMCVVMxFDASBgNVBAoTC0h5cGVybGVkZ2VyMQwwCgYDVQQDEwN0Y2EwHhcNMTYwOTE5MjAyMDE5WhcNMTYxMjE4MjAyMDE5WjBFMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLSHlwZXJsZWRnZXIxIDAeBgNVBAMTF1RyYW5zYWN0aW9uIENlcnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqop3N0IpJaLVaRuYioSuHPvyWX3OY9vo4I1YYw1YophcFGFt3fN0X6bDlufUZ5/u81JMmZHozduREnNzM1n+gaOCARswggEXMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMA0GA1UdDgQGBAQBAgMEMA8GA1UdIwQIMAaABAECAwQwEAYGKgMEBQYKBAZjbGllbnQwFQYGKgMEBQYLBAsyMzQ1Ni02Nzg5MDBNBgYqAwQFBgcBAf8EQNbPDmdWcOogMkZrlxbRJw/06jg4Ai88KW2+BsuxUnIH5FSa3OY7ZsXJLpceIN4SeEWKDKDsIPCo2wm6cUMYApIwOgYGKgMEBQYIBDDikSBKFYtTmYZRhtVDPhnIoSvefWHQ5Vx5oahIRbG8d/w4J1YTrtVoEwa2jikAqJowIwYGKgMEBQYJBBkwMEhFQURyb2xlLT4xI2FjY291bnQtPjIjMAoGCCqGSM49BAMDA0gAMEUCIQCrUQw2moOA5RFEx/780so4uEOV5esX3fy/It0t2la7gQIgGGVoDoM2kSxWH7TtV4T8W4pY6tN/LXu8XpKWb8+eF0k="]}, "metadata":[97, 115, 115, 105, 103, 110, 101, 114], "secureContext": "assigner", "attributes": ["role", "account"]}, "id": 1}' http://localhost:7050/chaincode
Try to run the query from step 9 for bob again:
curl -XPOST -d ‘{"jsonrpc": "2.0", "method": "query", "params": {"type": 1, "chaincodeID": {"name": "'"$HASH"'"}, "ctorMsg": {"args": ["query", "myasset"]}, "secureContext": "bob", "attributes": ["role", "account"]}, "id": 1}' http://localhost:7050/chaincode
and you will see that “myasset” is already created, and belongs to account “23456-67890”
Using the same approach we can find certificate for alice and change the owner for “myasset”.

Error `invalid distance too far back` when Inflate HTML gZIP content

I want to inflate HTML webpages. I am using zlib functions
inflateInit2(&zstream,15+32);
and then
inflate(&zstream,Z_SYNC_FLUSH);
It works for lots of webpages correctly but for "www.tabnak.ir" it does not work correctly.
invalid distance too far back is the ERROR I got for this website.
This webpage is also gzip and utf8.
How should I deal with that?
This is For Bing.com which works Fine
1f 8b 08 00 ef 8c 77 56 00 ff ec 5a eb 73 9c 46
12 ff 9e aa fc 0f 04 d5 9d ad 78 1f c0 3e b4 0b
96 52 b2 24 2b ba 73 1c 9d 2d 27 b9 8a af b6 06
This is For tabnak.ir which results in invalid distance too far back Error
1f 8b 08 00 00 00 00 00 00 03 ed fd db 73 5b d7
99 2f 8a 3e ab ab d6 ff 30 ac ae ac d8 3b 82 80
39 71 a7 6d 55 39 89 7b 75 f7 4a d2 7d 92 74 af
The zlib/gzip format performs compression saying things like "The next 22 bytes are the same as the 22 bytes we saw 1013 bytes ago.
In this case the record describing the repetition, is from before the size of the 'window'.
Given you have specified a maximum size of window, the likelihood, is that the data format has changed a bit, or the data you received is not the same as was sent.
Some things to check.
You are using the latest zlib library.
Standard utilities (e.g. gunzip, winzip) can decompress the data.
The data you are getting is not being mangled by a text filter ('rb' vs 'rt')
If that hasn't helped, try walking through the data and understanding what the failure in gzip is.
It would seem that the file you are trying to "inflate" (decompress using zlib) is not a valid zip file. Since bing.com is most likely not a zlib file, it might be pure coincidence that you found something quite early that prevented decompression.