I have web-service which provides me custom format of container which contains H.264 NAL units.
I want to play them via MediaElement in silverlight using custom MediaStreamSource.
According this article I need to set private codec data.
Web service provides me configCodec but in base64 format (looks like "AUIAHv/hABhnQsAe2gMg7+IhAAADAAEAAAMAMo8WLqABAARozgvI")
So, in other platforms (iOS, Android) all I need is set to extra-data property of codec.
codec->extra-data = info;
But in Windows Phone I should provide this info like 00000001 [SPS] 00000001 [PPS].
So, could someone tell me how I can parse provided private data from web-service to get SPS and PPS values from it?
Your data decoded into hex is:
0x01 0x42 0x00 0x1E 0xFF
0xE1
0x00 0x18 (SPS length in bytes)
0x67 0x42 0xC0 0x1E 0xDA 0x03 0x20 0xEF (SPS...)
0xE2 0x21 0x00 0x00 0x03 0x00 0x01 0x00
0x00 0x03 0x00 0x32 0x8F 0x16 0x2E 0xA0 (...SPS)
0x01
0x00 0x04 (PPS length in bytes)
0x68 0xCE 0x0B 0xC8 (PPS)
I don't know what this structure exactly is and where it is rfom, however SPS and PPS are definitely on it.
Related
Tried to use the OCRAM (i.mx6) region for storing the keys using the linker script But not able to read/write OCRAM region. The value we are fetching doesn't matches with the OCRAM content dumped using the MMAP call.
Attachments: [https://ufile.io/dpqwy]
modified linker script is attached
The C program used to place the key in the OCRAM attached
program output dumped below.
Map file for c program also attached, where "caterpillar_privkey" looks to be placed at right place.
OCRAM memory map attached
1 modified portion of linker script (full file attached)
MEMORY
{
RAM (xrw) : ORIGIN = 0x00000000, LENGTH = 1024M
IRAM (rwx) : ORIGIN = 0x00910000, LENGTH = (256K - 64K)
}
.mybuf : { KEEP (*(.pseudo_seg .pseudo_seg*)) } > IRAM
2.
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#define CODE_BASE_ADDR_START 0x910000
__attribute__((section(".pseudo_seg"))) uint8_t caterpillar_privkey[100];
void * MapMemory(unsigned int address, int size)
{
int32_t fd;
void *ret_addr;
fd = open("/dev/mem", O_RDWR | O_SYNC);
if (fd == -1) {
perror("open");
return NULL;
}
ret_addr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, address);
if (ret_addr == MAP_FAILED) {
perror("mmap");
ret_addr = NULL;
}
if (close(fd) == -1) {
perror("close");
}
return ret_addr;
}
int main(void)
{
int32_t k;
void *mem = MapMemory(CODE_BASE_ADDR_START, 4096);
fprintf(stderr, "*********************caterpillar key base =%p\n", caterpillar_privkey);
#if 0
memset(caterpillar_privkey, 0xa, sizeof(caterpillar_privkey));
#endif
fprintf(stderr, "\nDump caterpillar_privkey on iram mem at %p len=%d [linker script region]\n\n", caterpillar_privkey, sizeof(caterpillar_privkey));
for (k = 0; k < sizeof(caterpillar_privkey); k++) {
fprintf(stderr, "0x%02x ", caterpillar_privkey[k]);
}
fprintf(stderr, "\nDump caterpillar_privkey on iram mem at %p len=%d [linker script region] Endddddddddddd\n\n", caterpillar_privkey, sizeof(caterpillar_privkey));
fprintf(stderr, "Dump mem at %p len=%d using mmap to cross check \n\n", mem, sizeof(caterpillar_privkey));
for (k = 0; k < sizeof(caterpillar_privkey); k++) {
fprintf(stderr, "0x%02x ", ((uint8_t *) mem) [k]);
}
fprintf(stderr, "\nDump mem using mmap ndddddddddddddddddddddddd\n\n");
return 0;
}
3 (program output)
# /var/ocram_test
*********************caterpillar key base =0x910000
Dump caterpillar_privkey on iram mem at 0x910000 len=100 [linker script region]
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Dump caterpillar_privkey on iram mem at 0x910000 len=100 [linker script region] Endddddddddddd
Dump mem at 0x76fab000 len=100 using mmap to cross check
**0xec 0x1a 0x42 0x4d** 0xb3 0x62 0x55 0xe2 0x49 0xe6 0xba 0x77 0x96 0x77 0xa4 0x84 0x7b 0x76 0xf0 0x33 0xe2 0x42 0x17 0x88 0xe6 0xbd 0x53 0x5a 0xe5 0x31 0x57 0xaf 0x3d 0xbe 0x8b 0x1a 0x0f 0xba 0x9c 0x17 0x2e
0x31 0xe5 0x39 0xf7 0x65 0x27 0xfa 0x7f 0xc9 0xe2 0x65 0xfb 0xf2 0x13 0xbb 0x0f 0xd2 0x91 0x4f 0xa9 0x84 0x1b 0x2a 0xd2 0x6e 0x86 0xb2 0x29 0xc8 0xd6 0x2c 0x15 0x2b 0xff 0x4d 0xdf 0xbc 0x73 0xbf 0x09 0x61
0xd8 0x73 0x3a 0x89 0xaa 0x7a 0xb3 0x6a 0xcd 0xf0 0x9a 0xa8 0x97 0x3a 0x29 0x31 0xb2 0x32
Dump mem using mmap endddddddddddddddddddddddd
* Dumping memory at the U-boot to make sure same content exist on OCRAM */
U-Boot 2016.03 (Dec 06 2017 - 11:54:13 +0530)
CPU: Freescale i.MX6Q rev1.5 at 792 MHz
Reset cause: WDOG
Board: SABRE Lite
I2C: ready
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB
Display: hdmi:1280x720M#60 (1280x720)
In: serial
Out: serial
Err: serial
Net: Micrel ksz9021 at 7
FEC [PRIME], usb_ether
Hit any key to stop autoboot: 0
Enter passphrase to stop autoboot:
LC3_HAB => md 0x910000
00910000: **4d421aec** e25562b3 77bae649 84a47796 ..BM.bU.I..w.w..
00910010: 33f0767b 881742e2 5a53bde6 af5731e5 {v.3.B....SZ.1W.
00910020: 1a8bbe3d 179cba0f 39e5312e fa2765f7 =........1.9.e'.
00910030: 65e2c97f bb13f2fb 4f91d20f 2a1b84a9 ...e.......O...*
00910040: b2866ed2 2cd6c829 4dff2b15 bf73bcdf .n..)..,.+.M..s.
00910050: 73d86109 7aaa893a f0cd6ab3 3a97a89a .a.s:..z.j.....:
00910060: 32b23129 724ea2b0 02cc1510 564da177 )1.2..Nr....w.MV
00910070: 7b646936 4dd721ad 4b80692f 22ecdc98 6id{.!.M/i.K..."
00910080: 682e525f 5c0bed9a 1218fa32 9ef66eb6 _R.h...\2....n..
00910090: 728c29d8 1197b647 997247c0 37ab36a2 .).rG....Gr..6.7
009100a0: 72c571e1 4c6b3bda 49f2639f c719b88e .q.r.;kL.c.I....
009100b0: 9dca08b3 3a9140cc 2d3baf94 93875366 .....#.:..;-fS..
009100c0: a465e61b 2c6bb79e ce61f195 75e89607 ..e...k,..a....u
009100d0: e53cc9af 4953b4db a497ca23 206f5f87 ..<...SI#...._o
009100e0: ab309c04 03ae7f91 cf2c65cf 017420b4 ..0......e,.. t.
009100f0: b09f5053 5104ac83 ea898c88 3e737bc2 SP.....Q.....{s>
I came across this byte lookup table and was trying to identify the pattern. What is it generated from?
There is a similar byte lookup here on SO but it starts with 0x00.
How can I shuffle bits efficiently? Seems like a good way to do things like counting the number of bits that are flagged on in a large number for example.
0x01 0x00 0x01 0x02 0x03 0x02 0x03 0x00 0x01 0x00 0x01 0x02 0x03 0x02 0x03 0x04
0x05 0x04 0x05 0x06 0x07 0x06 0x07 0x04 0x05 0x04 0x05 0x06 0x07 0x06 0x07 0x00
0x01 0x00 0x01 0x02 0x03 0x02 0x03 0x00 0x01 0x00 0x01 0x02 0x03 0x02 0x03 0x04
0x05 0x04 0x05 0x06 0x07 0x06 0x07 0x04 0x05 0x04 0x05 0x06 0x07 0x06 0x07 0x08
0x09 0x08 0x09 0x0a 0x0b 0x0a 0x0b 0x08 0x09 0x08 0x09 0x0a 0x0b 0x0a 0x0b 0x0c
0x0d 0x0c 0x0d 0x0e 0x0f 0x0e 0x0f 0x0c 0x0d 0x0c 0x0d 0x0e 0x0f 0x0e 0x0f 0x08
0x09 0x08 0x09 0x0a 0x0b 0x0a 0x0b 0x08 0x09 0x08 0x09 0x0a 0x0b 0x0a 0x0b 0x0c
0x0d 0x0c 0x0d 0x0e 0x0f 0x0e 0x0f 0x0c 0x0d 0x0c 0x0d 0x0e 0x0f 0x0e 0x0f 0x00
0x01 0x00 0x01 0x02 0x03 0x02 0x03 0x00 0x01 0x00 0x01 0x02 0x03 0x02 0x03 0x04
0x05 0x04 0x05 0x06 0x07 0x06 0x07 0x04 0x05 0x04 0x05 0x06 0x07 0x06 0x07 0x00
0x01 0x00 0x01 0x02 0x03 0x02 0x03 0x00 0x01 0x00 0x01 0x02 0x03 0x02 0x03 0x04
0x05 0x04 0x05 0x06 0x07 0x06 0x07 0x04 0x05 0x04 0x05 0x06 0x07 0x06 0x07 0x08
0x09 0x08 0x09 0x0a 0x0b 0x0a 0x0b 0x08 0x09 0x08 0x09 0x0a 0x0b 0x0a 0x0b 0x0c
0x0d 0x0c 0x0d 0x0e 0x0f 0x0e 0x0f 0x0c 0x0d 0x0c 0x0d 0x0e 0x0f 0x0e 0x0f 0x08
0x09 0x08 0x09 0x0a 0x0b 0x0a 0x0b 0x08 0x09 0x08 0x09 0x0a 0x0b 0x0a 0x0b 0x0c
0x0d 0x0c 0x0d 0x0e 0x0f 0x0e 0x0f 0x0c 0x0d 0x0c 0x0d 0x0e 0x0f 0x0e 0x0f 0x10
0x11 0x10 0x11 0x12 0x13 0x12 0x13 0x10 0x11 0x10 0x11 0x12 0x13 0x12 0x13 0x14
0x15 0x14 0x15 0x16 0x17 0x16 0x17 0x14 0x15 0x14 0x15 0x16 0x17 0x16 0x17 0x10
0x11 0x10 0x11 0x12 0x13 0x12 0x13 0x10 0x11 0x10 0x11 0x12 0x13 0x12 0x13 0x14
0x15 0x14 0x15 0x16 0x17 0x16 0x17 0x14 0x15 0x14 0x15 0x16 0x17 0x16 0x17 0x18
0x19 0x18 0x19 0x1a 0x1b 0x1a 0x1b 0x18 0x19 0x18 0x19 0x1a 0x1b 0x1a 0x1b 0x1c
0x1d 0x1c 0x1d 0x1e 0x1f 0x1e 0x1f 0x1c 0x1d 0x1c 0x1d 0x1e 0x1f 0x1e 0x1f 0x18
0x19 0x18 0x19 0x1a 0x1b 0x1a 0x1b 0x18 0x19 0x18 0x19 0x1a 0x1b 0x1a 0x1b 0x1c
0x1d 0x1c 0x1d 0x1e 0x1f 0x1e 0x1f 0x1c 0x1d 0x1c 0x1d 0x1e 0x1f 0x1e 0x1f 0x10
0x11 0x10 0x11 0x12 0x13 0x12 0x13 0x10 0x11 0x10 0x11 0x12 0x13 0x12 0x13 0x14
There's actually an Online Encyclopedia of Integer Sequences! Plugging your numbers into the OEIS search turns up A059905: Index of first half of decomposition of integers into pairs based on A000695, with a comment describing it as "One coordinate of a recursive non-self intersecting walk on the square lattice Z^2". OEIS gives several ways to compute the sequence.
There are plenty of other ways to characterize this sequence and other ways it might turn up, including the bit-shuffle application you linked. We can't tell what the intended use of the table was wherever you came across it just by seeing the values or knowing that it's OEIS A059905, but knowing the math behind it helps understand it better.
If you ever want to know what a mysterious sequence of integers might be, OEIS is a good resource to try.
I made this simple password verification program, and I'm trying to overflow the buffer array to change the auth variable to 1 and i managed to do it except I can only change the auth variable to the character 1 and not the decimal 1, how can i do it?
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char *argv[]){
char buffer[16];
int auth=0;
strcpy(buffer, argv[1]);
if(strcmp(buffer,"password")==0)
auth=1;
else
auth=0;
if(auth)
printf("Granted");
return 0;
}
Following information is derived from runs on my Ubuntu-14.04 system using gcc version 4.8.4 as my compiler and gdb version 7.7.1 as my debugger
First, the buffer overflow happens as a result of the strcpy function, and if you overflow buf so that it overwrites the memory location of auth, but the following if-else block will overwrite your changes.
Secondly you can see what is happening by looking at the stack in a debugger. I made a slight modification to you code, by initializing auth to 0xbbbbbbbb (just so I can find here auth is located on the stack).
Setting a break point on main and stepping into the function we can examine the values of the various registers:
(gdb) info reg
rax 0x0 0
rbx 0x0 0
rcx 0x0 0
rdx 0x7fffffffdf30 140737488346928
rsi 0x7fffffffdf18 140737488346904
rdi 0x2 2
rbp 0x7fffffffde30 0x7fffffffde30
rsp 0x7fffffffddf0 0x7fffffffddf0
[... some lines removed ...]
rip 0x400652 0x400652 <main+37>
eflags 0x246 [ PF ZF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
From this we can see that the stack extends from 0x7fffffffddf0 to 0x7fffffffde30. Now stopping right before the call to strcpy, we can take a look at the stack:
(gdb) x/76xb $rsp
0x7fffffffddf0: 0x18 0xdf 0xff 0xff 0xff 0x7f 0x00 0x00
0x7fffffffddf8: 0x1d 0x07 0x40 0x00 0x02 0x00 0x00 0x00
0x7fffffffde00: 0x30 0xde 0xff 0xff 0xff 0x7f 0x00 0x00
0x7fffffffde08: 0x00 0x00 0x00 0x00 0xbb 0xbb 0xbb 0xbb
0x7fffffffde10: 0xd0 0x06 0x40 0x00 0x00 0x00 0x00 0x00
0x7fffffffde18: 0x40 0x05 0x40 0x00 0x00 0x00 0x00 0x00
0x7fffffffde20: 0x10 0xdf 0xff 0xff 0xff 0x7f 0x00 0x00
0x7fffffffde28: 0x00 0x2b 0x25 0x07 0xdd 0x7a 0xc0 0x6d
0x7fffffffde30: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7fffffffde38: 0x45 0x6f 0xa3 0xf7
Looking at this, we can see that auth is located at a memory address of 0x7fffffffde0c.
I set as a command line argument passwordAAAAAAAA111, and now we can single step across the strcpy call and look at memory again:
(gdb) x/76xb $rsp
0x7fffffffddf0: 0x18 0xdf 0xff 0xff 0xff 0x7f 0x00 0x00
0x7fffffffddf8: 0x1d 0x07 0x40 0x00 0x02 0x00 0x00 0x00
0x7fffffffde00: 0x30 0xde 0xff 0xff 0xff 0x7f 0x00 0x00
0x7fffffffde08: 0x00 0x00 0x00 0x00 0xbb 0xbb 0xbb 0xbb
0x7fffffffde10: 0x70 0x61 0x73 0x73 0x77 0x6f 0x72 0x64
0x7fffffffde18: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0x7fffffffde20: 0x31 0x31 0x31 0x31 0x00 0x7f 0x00 0x00
0x7fffffffde28: 0x00 0x2b 0x25 0x07 0xdd 0x7a 0xc0 0x6d
0x7fffffffde30: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7fffffffde38: 0x45 0x6f 0xa3 0xf7
(gdb)
From this, we can see that the value of auth has not be touched (notice the four 0xbb still in memory starting at 0x7fffffffde0c). Also we can now see where the password is stored in memory, it starts at 0x7fffffffde10. The four 'A's that I used are where the four 0x41s are and the four '1's that I used are where the four 0x31s are
So, on my system I do not see a way that you would be able to overflow into the auth variable.
Finally, the question that you originally raised, remember that the command line arguments are treated as a character array, so passing in something line AAAA1 on the command line will result in the array [0x41 0x41 0x41 0x41 0x31] being passed to your program. What you want your program to receive is actually [0x41 0x41 0x41 0x41 0x01 0x00 0x00 0x00] (assuming 32-bit, little endian architecture). There are two issues that you will face,
1. 0x01 is a non-printable character
2. 0x00 being the null terminator will stop the string input at the first null.
There is not alot you can do about the issue 2, with just a simple input; however as others have suggested the solution around issue 1 is to create a driver program that builds the input buffer the way that you want and then passes that to the program.
On windows (resp. Linux), create a bat (resp shell) file like this:
a 0123456789ABCDEFG
(a being the name of your executable)
Then, edit it with an hex editor and change the last G to 01 hex value, save.
If (I say if) you can make sure that the address of your integer value comes after the char buffer (which I could not do using my gcc, since the compiler locates its variable with an implementation-based order), run this script and you will see that the \001 char is passed at the end of first argument.
Note: there's no way at all to pass a 0 (null) character as arguments are null-terminated, so if you want to inject some data or code, you will have to do without the zero character.
I am trying to understand how to read memory address and find out its value using GDB.
In code, I assigned a value:
xyz->a = -1;
In GDB I see this:
(gdb) p xyz->a
$1 = 65535
(gdb) p/x xyz->a
$2 = 0xffff
(gdb) p &(xyz->a)
$3 = (some_type *) 0x172e750
(gdb) x/40xb 0x172e750
0x172e750: 0xff 0xff 0x00 0x00 0x00 0x00 0x00 0x00
0x172e758: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x172e760: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x172e768: 0xc0 0xe0 0x5b 0x01 0x00 0x00 0x00 0x00
0x172e770: 0xd8 0x00 0x00 0x00 0x29 0x00 0x00 0x00
Firstly, how do I read the memory addresses and their values to determine xyz->a value?
Second, looks like there is an Endian issue going on? How do I confirm that?
In memory, they are complements. To confirm endian, you can try to give xyz->a a value such like 0x55aa.
I'm trying to create a X509 Request for a Proxy Certificate (ProxyCertInfo Extension RFC3820) in C (OpenSSL), but I cannot figure out how the datastructures of the ProxyCertInfo should be defined. The RFC defines the ASN.1 language as follows:
PKIXproxy88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
proxy-cert-extns(25) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NONE --
-- PKIX specific OIDs
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-- private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- Locally defined OIDs
-- The proxy certificate extension
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
-- Proxy certificate policy languages
id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }
-- Proxy certificate policies languages defined in
id-ppl-anyLanguage OBJECT IDENTIFIER ::= { id-ppl 0 }
id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 }
-- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE {
pCPathLenConstraint ProxyCertPathLengthConstraint OPTIONAL,
proxyPolicy ProxyPolicy
}
ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL
}
END
I have looked at the very limited documentation of OpenSSL and cannot find out how to parse this to C data structs. I've also read http://www.openssl.org/docs/apps/asn1parse.html# as it explains how to use the parser for the command line tool, but not how to include this in your own source code.
I have managed to include other extensions to the X509 request already, so I'm relatively sure my only problem is with the formatting of the data structures for this particular extension.
I think your question is "How do I format data as a ProxyCertInfoExtension?" If this in incorrect please let me know.
If you want to know some theory, the best reference I have found is A Layman's Guide to a Subset of ASN.1, BER, and DER.
The code section in your question is a description of how the data for the ProxyCertInfoExtension is encoded. Think of the encoding description as a grammar that could be processed by a parser generator, much as yacc take a grammar as input and outputs C code. In fact at least one ASN.1 parser generator exists ASN1C
ASN.1 encodings may be of variable size. The data begins with an outtermost or top level ASN.1 encoding. Each ASN.1 encoding may contain one or more ASN.1 encoding inside itself. In this way ASN.1 is recursive.
An ASN.1 encoding is composed of a header, a length, optional content, and an optional end.
ASN.1 encoding { Header length [content] [end] }
The header is composed of a Class type, a Primitive/Constructed bit, and a Tag-Number. If the Tag-Number is larger than 63 then the Tag-Number will span multiple bytes. This means that the header may be one byte long or many bytes long depending on the value of the Tag-Number. The header is byte aligned meaning that is always some number of bytes long.
ASN.1 header { ClassType Primitive/Constructed Tag-number }
The length may also be one byte to many bytes long depending on the value of the length. Again the Length is byte aligned.
The Class type and the Tag-Number tell you what is encoded in the Content.
The outtermost encoding is usually a sequence or set, which are compound basic types. In your encoding, the outtermost encoding is the ProxyCertInfoExtension which is a sequence of an optional ProxyCertPathLengthConstraint and a ProxyPolicy. Your encoding looks like this:
ProxyCertInfoExtension { [ProxyCertPathLengthConstraint] ProxyPolicy }
Looking back at the encoding rules, ProxyCertPathLengthConstraint is just an integer, so your encoding is really:
ProxyCertInfoExtension { [Integer] ProxyPolicy }
The encoding rules define a ProxyPolicy as a sequence of a policyLanguage and an optional policy. So we can update the encoding representation to look like this:
ProxyCertInfoExtension { [Integer] { policyLanguage [policy] } }
The encoding rules specify policy as an Octet String (Just some number of bytes). So firther simplification produces:
ProxyCertInfoExtension { [Integer] { policyLanguage [Octet String] } }
Depending on the object identifier, the encoding is one of:
ProxyCertInfoExtension { [Integer] { id-ppl-anyLanguage [Octet String] } }
ProxyCertInfoExtension { [Integer] { id-ppl-inheritAll [Octet String] } }
ProxyCertInfoExtension { [Integer] { id-ppl-independent [Octet String] } }
I'll try an untested example
ProxyCertPathLengthConstraint=64
policyLanguage=id-ppl-anyLanguage
policy="test"
I'll work inside out starting with policy length is 04
this is a printable string so class=00(universal) primitive/constructed=0(primitive) and tag-number=0x13
the header byte is 0x13
length=4, so length byte is 0x04
"test" in ascii is 0x74 0x65 0x73 0x74
the encoding for policy is 0x13 0x04 0x74 0x65 0x73 0x74
id-ppl-anyLanguage is an Object Identifier so class=00(universal) primitive/constructed=0(primitive) and tag-number=0x06
the header byte is 0x06
the value for id-ppl-anyLanguage is "1.3.6.1.5.5.7.21.0"
length=18, so length byte is 0x12
"1.3.6.1.5.5.7.21.0" = 0x11 0x0E 0x03 0x0E 0x16 0x0E 0x11 0x0E 0x15 0x0E 0x15 0x0E 0x17 0x0E 0x12 0x11 0x0E 0x10
the encoding for policyLanguage is
0x06 0x12 0x11 0x0E 0x03 0x0E 0x16 0x0E 0x11 0x0E 0x15 0x0E 0x15 0x0E 0x17 0x0E 0x12 0x11 0x0E 0x10
proxyPolicy is a sequence so class=00(universal) primitive/constructed=0(primitive) and tag-number=0x10
the header byte is 0x10
the length= lengthof(policyLanguage) + lengthof(policy)
= (lengthof(policyLanguage headers) + lengthof (policyLanguage content)) + (lengthof(policyheaders) + lengthof (policy content))
= (2 + 4) + (2 + 18)
= 6 + 20 = 26
length=26, so length byte is 0x1A
the content is policyLanguage followed by policy =
0x06 0x12 0x11 0x0E 0x03 0x0E 0x16 0x0E 0x11 0x0E 0x15 0x0E 0x15 0x0E 0x17 0x0E 0x12 0x11 0x0E 0x10 0x13 0x04 0x74 0x65 0x73 0x74
the encoding for proxyPolicy is
0x10 0x1A 0x06 0x12 0x11 0x0E 0x03 0x0E 0x16 0x0E 0x11 0x0E 0x15 0x0E 0x15 0x0E 0x17 0x0E 0x12 0x11 0x0E 0x10 0x13 0x04 0x74 0x65 0x73 0x74
ProxyCertPathLengthConstraint is a integer so class=00(universal) primitive/constructed=0(primitive) and tag-number=0x02
the header byte is 0x02
the length=0x01
the content=0x40
the encoding is 0x02 0x01 0x40
ProxyCertInfoExtension is a SEQUENCE so class=00(universal) primitive/constructed=0(primitive) and tag-number=0x10
the header byte is 0x10
the length = lengthof(pCPathLenConstraint) + lengthof(proxyPolicy)
= lengthof(pCPathLenConstraint headers) + lengthof (pCPathLenConstraint content)) + (lengthof(proxyPolicy headers) + lengthof(proxyPolicy content))
= (2 + 1) + (2 + 26) = 3 + 28 = 31 = 0x1F
the content= pCPathLenConstraint followed by proxyPolicy
= 0x02 0x01 0x40 0x10 0x1A 0x06 0x12 0x11 0x0E 0x03 0x0E 0x16 0x0E 0x11 0x0E 0x15 0x0E 0x15 0x0E 0x17 0x0E 0x12 0x11 0x0E 0x10 0x13 0x04 0x74 0x65 0x73 0x74
the encoding is 0x10 0x1F 0x02 0x01 0x40 0x10 0x1A 0x06 0x12 0x11 0x0E 0x03 0x0E 0x16 0x0E 0x11 0x0E 0x15 0x0E 0x15 0x0E 0x17 0x0E 0x12 0x11 0x0E 0x10 0x13 0x04 0x74 0x65 0x73 0x74