I have an AC Huffman table generated as follows:
Destination ID = 1
Class = 1 (AC Table)
Codes of length 01 bits (000 total):
Codes of length 02 bits (002 total): 00 01
Codes of length 03 bits (001 total): 02
Codes of length 04 bits (002 total): 03 11
Codes of length 05 bits (004 total): 04 05 21 31
Codes of length 06 bits (004 total): 06 12 41 51
Codes of length 07 bits (003 total): 07 61 71
Codes of length 08 bits (004 total): 13 22 32 81
Codes of length 09 bits (007 total): 08 14 42 91 A1 B1 C1
Codes of length 10 bits (005 total): 09 23 33 52 F0
Codes of length 11 bits (004 total): 15 62 72 D1
Codes of length 12 bits (004 total): 0A 16 24 34
Codes of length 13 bits (000 total):
Codes of length 14 bits (001 total): E1
Codes of length 15 bits (002 total): 25 F1
Codes of length 16 bits (119 total): 17 18 19 1A 26 27 28 29 2A 35 36 37 38 39 3A 43
44 45 46 47 48 49 4A 53 54 55 56 57 58 59 5A 63
64 65 66 67 68 69 6A 73 74 75 76 77 78 79 7A 82
83 84 85 86 87 88 89 8A 92 93 94 95 96 97 98 99
9A A2 A3 A4 A5 A6 A7 A8 A9 AA B2 B3 B4 B5 B6 B7
B8 B9 BA C2 C3 C4 C5 C6 C7 C8 C9 CA D2 D3 D4 D5
D6 D7 D8 D9 DA E2 E3 E4 E5 E6 E7 E8 E9 EA F2 F3
F4 F5 F6 F7 F8 F9 FA
Total number of codes: 162
I need to find the Mincode, Maxcode and Valptr values from this table. Apparently the decode procedure is not similar to the one of the DC table.
The following answer explains the retrieval of these values from a DC table:
answer
The generation of those tables and the Huffman decoding of the eight-bit value is exactly the same for AC and DC coefficients. What you do with the resulting eight-bit values is different.
Related
I am trying to post a public key from a server with Bash to Github as part of an automation set-up. I am using cURL for that like so:
# Make API call to Github
api_token="some string"
pub_key="$(cat /home/${project_name}/.ssh/id_rsa.pub)"
echo $pub_key
curl -H "Authorization: token ${api_token}" -H "Content-Type: application/json" -X POST -d '{"title":"'"$project_name"'","key":"'"$pub_key"'"}' https://api.github.com/user/keys
As you can see I echo the pub_key just to make sure its getting it correctly, this is the output and the result of the API call to Github:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDi62x5maR2U42+asddDSF322dsdkjTNeG69QvV3crOeDgjiZZJTCwqoxkk9lDbfkfycS6QBazA8cPv4scxL1K1bWgXQ6p8/9TWP89/oUJcf+C9+bMzIFmJ6jOGA2ikA0+K6l7Gr4Y7SZR9UuctawFR56vFqWj9YEW7JhBQEVES9TNb+WJLZ6QPwl+PaTOt/6QXIvrnh0ffI5uuTkMg1m7XGMNuTnBnHYa2OQ0GIfL0zG8CEqLWch4AkP2gkBOFH3LnIwucS00ii9xpPVBLRv5O5WCHM9m6A7RtHtKyELu5Z6IOtLVHC6SRPnVdUaw4oEmt3aekqEEnXkq4Jom8arpiULWCYB9d5C4x6CGRrKqophHAfumoQFFh6GMtNrDLcVGUXmIa8qapOQNvsSzcDeVkyCbNu6RlurwyWYG8MH48XCrFDU3L+hmYptGEARgGd9IZSctMng/elUOIz1DL3ZGH43flMelXEZ8Umy8tAkat7/T8Yuu9tU8N8DKqKV16s= stackoverflowtest#rasenberg
{
"id": 46506612,
"key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDi62x5maR2U42+asddDSF322dsdkjTNeG69QvV3crOeDgjiZZJTCwqoxkk9lDbfkfycS6QBazA8cPv4scxL1K1bWgXQ6p8/9TWP89/oUJcf+C9+bMzIFmJ6jOGA2ikA0+K6l7Gr4Y7SZR9UuctawFR56vFqWj9YEW7JhBQEVES9TNb+WJLZ6QPwl+PaTOt/6QXIvrnh0ffI5uuTkMg1m7XGMNuTnBnHYa2OQ0GIfL0zG8CEqLWch4AkP2gkBOFH3LnIwucS00ii9xpPVBLRv5O5WCHM9m6A7RtHtKyELu5Z6IOtLVHC6SRPnVdUaw4oEmt3aekqEEnXkq4Jom8arpiULWCYB9d5C4x6CGRrKqophHAfumoQFFh6GMtNrDLcVGUXmIa8qapOQNvsSzcDeVkyCbNu6RlurwyWYG8MH48XCrFDU3L+hmYptGEARgGd9IZSctMng/elUOIz1DL3ZGH43flMelXEZ8Umy8tAkat7/T8Yuu9tU8N8DKqKV16s=",
"url": "https://api.github.com/user/keys/46506612",
"title": "stackoverflowtest",
"verified": true,
"created_at": "2020-09-27T04:23:30Z",
"read_only": false
}
As you can see in the API call, Curl cuts of the = stackoverflowtest#rasenberg part at the end, and therefore I post an invalid pub key to Github, resulting it in not working. What is going wrong?
As https://stackoverflow.com/users/3266847/benjamin-w commented (!), the comment portion of an OpenSSH-format pubkey is optional and not needed, and was almost certainly removed by github (after receipt) not by curl. However, your key is in fact invalid and I'm a bit surprised github considers it verified.
$ printf AAAAB3NzaC1yc2EAAAADAQABAAABgQDi62x5maR2U42+asddDSF322dsdkjTNeG69QvV3crOeDgjiZZJTCwqoxkk9lDbfkfycS6QBazA8cPv4scxL1K1bWgXQ6p8/9TWP89/oUJcf+C9+bMzIFmJ6jOGA2ikA0+K6l7Gr4Y7SZR9UuctawFR56vFqWj9YEW7JhBQEVES9TNb+WJLZ6QPwl+PaTOt/6QXIvrnh0ffI5uuTkMg1m7XGMNuTnBnHYa2OQ0GIfL0zG8CEqLWch4AkP2gkBOFH3LnIwucS00ii9xpPVBLRv5O5WCHM9m6A7RtHtKyELu5Z6IOtLVHC6SRPnVdUaw4oEmt3aekqEEnXkq4Jom8arpiULWCYB9d5C4x6CGRrKqophHAfumoQFFh6GMtNrDLcVGUXmIa8qapOQNvsSzcDeVkyCbNu6RlurwyWYG8MH48XCrFDU3L+hmYptGEARgGd9IZSctMng/elUOIz1DL3ZGH43flMelXEZ8Umy8tAkat7/T8Yuu9tU8N8DKqKV16s= |openssl base64 -d -A|od -Ax -tx1
000000 00 00 00 07 73 73 68 2d 72 73 61 00 00 00 03 01
000010 00 01 00 00 01 81 00 e2 eb 6c 79 99 a4 76 53 8d
000020 be 6a c7 5d 0d 21 77 db 67 6c 76 48 d3 35 e1 ba
000030 f5 0b d5 dd ca ce 78 38 23 89 96 49 4c 2c 2a a3
000040 19 24 f6 50 db 7e 47 f2 71 2e 90 05 ac c0 f1 c3
000050 ef e2 c7 31 2f 52 b5 6d 68 17 43 aa 7c ff d4 d6
000060 3f cf 7f a1 42 5c 7f e0 bd f9 b3 33 20 59 89 ea
000070 33 86 03 68 a4 03 4f 8a ea 5e c6 af 86 3b 49 94
000080 7d 52 e7 2d 6b 01 51 e7 ab c5 a9 68 fd 60 45 bb
000090 26 10 50 11 51 12 f5 33 5b f9 62 4b 67 a4 0f c2
0000a0 5f 8f 69 33 ad ff a4 17 22 fa e7 87 47 df 23 9b
0000b0 ae 4e 43 20 d6 6e d7 18 c3 6e 4e 70 67 1d 86 b6
0000c0 39 0d 06 21 f2 f4 cc 6f 02 12 a2 d6 72 1e 00 90
0000d0 fd a0 90 13 85 1f 72 e7 23 0b 9c 4b 4d 22 8b dc
0000e0 69 3d 50 4b 46 fe 4e e5 60 87 33 d9 ba 03 b4 6d
0000f0 1e d2 b2 10 bb b9 67 a2 0e b4 b5 47 0b a4 91 3e
000100 75 5d 51 ac 38 a0 49 ad dd a7 a4 a8 41 27 5e 4a
000110 b8 26 89 bc 6a ba 62 50 b5 82 60 1f 5d e4 2e 31
000120 e8 21 91 ac aa a8 a6 11 c0 7e e9 a8 40 51 61 e8
000130 63 2d 36 b0 cb 71 51 94 5e 62 1a f2 a6 a9 39 03
000140 6f b1 2c dc 0d e5 64 c8 26 cd bb a4 65 ba bc 32
000150 59 81 bc 30 7e 3c 5c 2a c5 0d 4d cb fa 19 98 a6
000160 d1 84 01 18 06 77 d2 19 49 cb 4c 9e 0f de 95 43
000170 88 cf 50 cb dd 91 87 e3 77 e5 31 e9 57 11 9f 14
000180 9b 2f 2d 02 46 ad ef f4 fc 62 eb bd b5 4f 0d f0
000190 32 aa 29 5d 7a
000195
The length of n, 00 00 01 81 at byte offsets 0x12-0x15, would correspond to a 3072-bit RSA key (with the sign byte required by SSH mpint) but implies the total length of the blob (after base64 decoding, or before encoding) should be 0x197 and instead it's actually 0x195, making it invalid and unusable. Check whatever program or process you used to create this key; there's a bug somewhere.
When inspecting a transport stream using tsduck, I can see that some packets contains a PCR value in Hex. I am not sure how to convert these into timestamps.
For example, in the packet below the PCR value is 0x000002014CE
* Packet 179
---- TS Header ----
PID: 481 (0x01E1), header size: 25, sync: 0x47
Error: 0, unit start: 1, priority: 0
Scrambling: 0, continuity counter: 4
Adaptation field: yes (21 bytes), payload: yes (163 bytes)
Discontinuity: 0, random access: 0, ES priority: 0
PCR: 0x000002014CE
---- PES Header ----
Stream id: 0xE0 (Video 0)
PES packet length: 0 (unbounded)
---- Full TS Packet Content ----
47 41 E1 34 14 12 00 00 0D B0 7E 4E 0C 02 0A 22 8E 00 00 D1 2D 03 64 00
29 00 00 01 E0 00 00 84 C0 0A 31 00 07 44 B7 11 00 05 D4 37 00 00 00 01
09 30 00 00 01 06 01 03 03 84 19 80 00 00 01 41 9A 84 93 D1 13 7F F0 28
2C 26 B5 35 90 10 B7 32 8C FF 00 D3 47 BE 4C 9A 83 AE CD B8 9C 09 5A 60
07 BE C4 F2 2C 5D D3 24 6C 7F A0 E1 C4 7B BC FA 37 CA C5 C0 B0 C4 2C 91
96 09 07 22 C4 A8 55 FF C2 BF 0E 7E 10 74 6D 84 F2 08 9D D0 29 52 7F 2B
F6 3E C8 23 1F BC 4E 80 C3 AE FD AC F4 96 08 E5 13 C8 A7 41 20 B4 F6 F8
E1 14 4A 03 4C 8E 98 00 04 73 2D AE 83 31 0B C8 61 03 3A A1
What I tried is looking at the first few instances of packets that had the PCR values in them, then converting them to decimal and subsequently dividing by 90,000 which is the clock rate of the PCR clock (i.e the timebase).
But looking at the last column, it doesn't look right. It would seem that the intervals are too high. I thought that the PCR must insert PCR stamps at least every 100ms or so, but this seems to be too infrequent....
You are not using the correct time base. If you look at the example you posted, tsduck shows the PCR as 0x000002014CE But that hex value does not show up in that packet at all. The reason is the PCR is more than just a time stamp, Its 2 timestamps. The PCR in the hex is actually 00 00 0D B0 7E 4E So how do we get from 0xDB07E4E to 0x2014CE? We extract the 90 kHz component by shifting 0xDB07E4E right by 15 bits, Then extract the 27MHz component by masking off the top 39 bits. Then multiply the 90kHz component by 300 to convert to 27MHz (300=27000000/90000) and add the two values together:
300*(0xDB07E4E>>15) + (0xDB07E4E&0x1ffff) = 0x2014CE
We now have the 27MHz timestamp. To convert that to seconds, divide by 27000000
0x2014CE/27000000=0.0779
Hence:
0x58e54 = 0.0135
0x78707 = 0.0183
TLDR: time base is 27000000, not 90000
I have an old application that stored images (scanned B&W page) in a large binary file. I have worked out how to single out the individual pages, but I can't decipher the binary for each page. As far as I know, the original pages were TIFF images. The resulting binary is also 1/16th the size, so has obviously been compressed. I'm also not sure of the "endianness" of the files. How would I go about identifying how this file has been stored/compressed or even possibly encrypted? I've included the binary for one of the (smallest) pages (This page should be white with a small line of text in the middle). The original was 58k. Incidentally, all of the pages have the same 14 byte header.
01 05 22 28 8E A9 F0 70 BD EF 03 2E EE 0F D8 B8 31 9B B8 03 D0 85 21 81 81 05 74 71 31 25 40 17 34 1E EF 07 A0 8B BD 29 A0 5B D6 C8 B8 B9 0A 31 30 01 26 48 12 B8 30 88 91 70 B0 D0 71 E0 62 63 E2 C2 80 CB 81 2B E2 2E AF F5 82 8B F4 39 AA 98 C5 FD 0B 4F 80 0C F5 37 8E 17 A0 B2 BF 5B 69 09 0E CC 2F 70 B6 44 07 BA 5D C3 E3 F8 55 41 81 EB 68 D6 E2 C7 53 14 1A 5C 74 B8 3C B8 88 F9 C8 A4 97 27 6A E2 69 95 A5 20 B1 EC A3 04 2B 5A E7 4F 93 AD EB 12 27 62 1F 9C 28 7D 60 C4 B4 E9 23 F4 68 8D A1 47 AA 8F 1B B1 3E 6E A4 3E 92 88 7D 24 A5 8F 62 91 6D 35 5A 7C 75 19 97 76 6E 0D A3 B6 86 B2 DC 61 80 18 D2 F6 58 6C 96 98 F5 0F 2A 9F 25 41 DD 9E CF D9 15 E1 FA 3E FC 24 F1 38 98 98 F9 F1 1F 8E C7 C6 DE DD 18 F4 99 6D 85 83 8B 91 1F FF 61 75 DB 69 C4 42 47 C7 7D 4E D7 C9 02 82 5B 0E 22 B8 18 30 96 39 F0 67 51 2C D5 93 1C AA ED 29 CE 16 4C DB 36 BC 69 D3 94 AD 4C C7 40 F0 96 A1 6C 62 A1 D0 8D C5 6C 82 BB 8E 41 F4 65 24 E8 70 B1 B1 56 6C 0B 8C B4 16 FF 8A 5A 45 90 60 83 28 0C 7C BF 50 02 63 93 0E D6 5F 98 F8 78 6A 7E 61 6D 6D CD 6A A9 E1 AC 3E 56 E9 9F BB 4F FF 8D 6E 0C F8 23 4D 32 0B AD 4E BB C2 03 FE 01
I'm using simplepush.php to send Apple Push Notification to my phone. Everything works fine on localhost and my phone gets the push notification successfully. However, when i try the same thing on my AWS EC2 instance (AmazonAMI) the push notification doesn't arrive.
Both development (localhost) and production (aws) environment produces the output below:
php simplepush.php testing...
message pushed: testing...
Connected to APNS
Message successfully delivered
The simplepush.php code is below:
// Put your device token here (without spaces):
$deviceToken = '[something]';
// Put your private key's passphrase here:
$passphrase = '[something]';
// Put your alert message here:
$message = 'Hi Simon!';
echo 'message pushed: '.$message."\n";
////////////////////////////////////////////////////////////////////////////////
$ctx = stream_context_create();
stream_context_set_option($ctx, 'ssl', 'local_cert', '[something]');
stream_context_set_option($ctx, 'ssl', 'passphrase', $passphrase);
// Open a connection to the APNS server
$fp = stream_socket_client(
'ssl://gateway.sandbox.push.apple.com:2195', $err,
$errstr, 60, STREAM_CLIENT_CONNECT|STREAM_CLIENT_PERSISTENT, $ctx);
if (!$fp)
exit("Failed to connect: $err $errstr" . PHP_EOL);
echo 'Connected to APNS' . PHP_EOL;
// Create the payload body
$body['aps'] = array(
'alert' => $message,
'sound' => 'default'
);
// Encode the payload as JSON
$payload = json_encode($body);
// Build the binary notification
$msg = chr(0) . pack('n', 32) . pack('H*', $deviceToken) . pack('n', strlen($payload)) . $payload;
// Send it to the server
$result = fwrite($fp, $msg, strlen($msg));
if (!$result)
echo 'Message not delivered' . PHP_EOL;
else
echo 'Message successfully delivered' . PHP_EOL;
// Close the connection to the server
fclose($fp);
So basically my problem is that i can't think of a way to identify what when wrong.
i've run
# openssl s_client -connect gateway.sandbox.push.apple.com:2195 -cert push.pem -key push.pem
Enter pass phrase for push.pem:
CONNECTED(00000003)
depth=2 O = Entrust.net, OU = www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU = (c) 1999 Entrust.net Limited, CN = Entrust.net Certification Authority (2048)
verify return:1
depth=1 C = US, O = "Entrust, Inc.", OU = www.entrust.net/rpa is incorporated by reference, OU = "(c) 2009 Entrust, Inc.", CN = Entrust Certification Authority - L1C
verify return:1
depth=0 C = US, ST = California, L = Cupertino, O = Apple Inc., CN = gateway.sandbox.push.apple.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Cupertino/O=Apple Inc./CN=gateway.sandbox.push.apple.com
i:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
1 s:/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
i:/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048)
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFMzCCBBugAwIBAgIETCMmsDANBgkqhkiG9w0BAQUFADCBsTELMAkGA1UEBhMC
VVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0
Lm5ldC9ycGEgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMW
KGMpIDIwMDkgRW50cnVzdCwgSW5jLjEuMCwGA1UEAxMlRW50cnVzdCBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eSAtIEwxQzAeFw0xNDA1MjMxNzQyNDJaFw0xNjA1MjQw
NzA1MTNaMHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYD
VQQHEwlDdXBlcnRpbm8xEzARBgNVBAoTCkFwcGxlIEluYy4xJzAlBgNVBAMTHmdh
dGV3YXkuc2FuZGJveC5wdXNoLmFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAOQpUlXpU3+LJ2XR01QdVooN7S9OFOINp3/tomPaenQAwFGo
qIakKFcN7AotWLFXFcR0QXKJkn4PL/zPKDBucyRFkc79S5+ZraGRISWfi7G8XeaG
G3GzgeVQ977Qrn0IdCswnbwLsJoErnmq4AveQajUbYueR9SxhkWBwMimSxXzXoOS
XUOPzRvzObCxVZrvBBDSRJCeNVnVxtCmb17DM3+z5GZatBwWnvw0jgvSQsgof+uC
idXgqcN4msv3tVH54ipmuD9kbbwvtnDCHBZRXMMmhUfFXZRuE8GBEbPfVkqB16ad
JV4TVrVxwFENwdnsX9CXavHCgFJhtHRWKOoCH48CAwEAAaOCAY0wggGJMAsGA1Ud
DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwMwYDVR0fBCww
KjAooCagJIYiaHR0cDovL2NybC5lbnRydXN0Lm5ldC9sZXZlbDFjLmNybDBkBggr
BgEFBQcBAQRYMFYwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmVudHJ1c3QubmV0
MC8GCCsGAQUFBzAChiNodHRwOi8vYWlhLmVudHJ1c3QubmV0LzIwNDgtbDFjLmNl
cjBKBgNVHSAEQzBBMDUGCSqGSIb2fQdLAjAoMCYGCCsGAQUFBwIBFhpodHRwOi8v
d3d3LmVudHJ1c3QubmV0L3JwYTAIBgZngQwBAgIwKQYDVR0RBCIwIIIeZ2F0ZXdh
eS5zYW5kYm94LnB1c2guYXBwbGUuY29tMB8GA1UdIwQYMBaAFB7xq4kG+EkPATN3
7hR67hl8kyhNMB0GA1UdDgQWBBSSGfpGPmr9+FPcqRiStH0iKRBL7DAJBgNVHRME
AjAAMA0GCSqGSIb3DQEBBQUAA4IBAQAkj6+okMFVl7NHqQoii4e4iPDFiia+LmHX
BCc+2UEOOjilYWYoZ61oeqRXQ2b4Um3dT/LPmzMkKmgEt9epKNBLA6lSkL+IzEnF
wLQCHkL3BgvV20n5D8syzREV+8RKmSqiYmrF8dFq8cDcstu2joEKd173EfrymWW1
fMeaYTbjrn+vNkgM94+M4c/JnIDOhiPPbeAx9TESQZH+/6S98hrbuPIIlmaOJsOT
GMOUWeOTHXTCfGb1EM4SPVcyCW28TlWUBl8miqnsEO8g95jZZ25wFANlVxhfxBnP
fwUYU5NTM3h0xi3rIlXwAKD6zLKipcQ/YXRx7oMYnAm53tfU2MxV
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Cupertino/O=Apple Inc./CN=gateway.sandbox.push.apple.com
issuer=/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
---
Acceptable client certificate CA names
/C=US/O=Apple Inc./OU=Apple Certification Authority/CN=Apple Root CA
/C=US/O=Apple Inc./OU=Apple Worldwide Developer Relations/CN=Apple Worldwide Developer Relations Certification Authority
/C=US/O=Apple Inc./OU=Apple Certification Authority/CN=Apple Application Integration Certification Authority
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 5290 bytes and written 2130 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 961A8FAC722856E00BCEC063D1C0C118C3499445A965E9113959654610FA9F5D
Session-ID-ctx:
Master-Key: B5721BD09F3A151DFAA18C5F14241EEB5CF0C926D03A51C2529F0D483C8F64260C5AE143D54B63F59AB868D685671D49
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket:
0000 - 0f 4a 6e e0 82 49 3f 6f-16 aa 2a 4a 0a 59 ec 53 .Jn..I?o..*J.Y.S
0010 - bb db 8b 56 73 64 02 6d-1e 72 fb ca 59 ca 61 44 ...Vsd.m.r..Y.aD
0020 - 4d 5b 85 d7 0f 8f b6 67-ff ec 90 e2 46 80 a0 64 M[.....g....F..d
0030 - 3d f5 ad 89 f0 e3 b7 1b-72 7e e5 6b f0 26 03 8a =.......r~.k.&..
0040 - 5c ec ef 9a 0f 46 08 6f-96 a7 e9 b4 2e a5 3a be \....F.o......:.
0050 - 2e 90 32 d2 42 f3 3e 38-6b 49 2b 63 4f c1 41 34 ..2.B.>8kI+cO.A4
0060 - ff ed 05 b3 e4 9d d1 61-62 89 e8 59 88 4f c6 c8 .......ab..Y.O..
0070 - a1 8e 4a 6b 97 bd 6d 78-15 c1 a0 86 88 22 7f d2 ..Jk..mx....."..
0080 - f7 6b d9 38 8a 67 b1 d4-41 b8 f9 ad b5 ac e0 fb .k.8.g..A.......
0090 - cf bb 89 69 7c 33 18 2e-78 06 23 6d a8 e0 d9 fb ...i|3..x.#m....
00a0 - d1 f1 9e f5 6c 4b 02 cf-ad 4e 99 7b 99 32 45 72 ....lK...N.{.2Er
00b0 - fc 40 49 42 4f b8 a5 a7-00 2c 5e 1f 92 8d 89 2c .#IBO....,^....,
00c0 - eb fb 17 e2 db 93 83 d9-b3 79 7f bc 3c f2 2b f1 .........y..<.+.
00d0 - b6 25 0e 36 b4 fa c9 10-99 ec 87 64 a8 95 27 b7 .%.6.......d..'.
00e0 - 42 f5 72 70 fa 3e 59 89-99 df 0f 44 05 41 3c 0e B.rp.>Y....D.A<.
00f0 - ae cd 79 5b 67 9e c9 df-eb 75 33 a9 f2 d2 8e 9e ..y[g....u3.....
0100 - 5f 1c 65 6f c8 33 6a e8-e8 77 e5 a3 05 6e 1b 52 _.eo.3j..w...n.R
0110 - 2a 66 32 2b 82 c0 62 52-6c d9 f4 4d 65 54 bc bf *f2+..bRl..MeT..
0120 - b7 5b c6 f0 dd cf d3 49-f5 3a a5 ab dc 74 44 88 .[.....I.:...tD.
0130 - b4 7c 8c 35 ae b7 36 78-8b 5d 60 4f 93 7c 81 c7 .|.5..6x.]`O.|..
0140 - a2 81 a9 e7 3b 94 37 11-c4 62 08 f8 5e 03 f9 8c ....;.7..b..^...
0150 - eb 62 68 d2 1e 37 44 48-1a 94 7a 2c 23 16 39 c4 .bh..7DH..z,#.9.
0160 - a5 bb 29 9c de a6 54 dd-06 f1 28 76 72 13 f6 56 ..)...T...(vr..V
0170 - cd 6d c7 14 8f 7c 2c 33-4c 5f bf 44 3e 3b ff 7d .m...|,3L_.D>;.}
0180 - 59 a6 a9 61 61 e2 bc d9-09 75 20 30 b3 b7 d0 84 Y..aa....u 0....
0190 - 2e 46 c8 a2 77 49 db fb-d7 90 4a e5 97 38 6c 0c .F..wI....J..8l.
01a0 - 57 52 99 35 aa f7 ef 8d-3d 40 cf 08 cc 32 79 c3 WR.5....=#...2y.
01b0 - f7 7a f1 d9 aa 8e 81 7e-2b ec 15 32 a6 1f cf a1 .z.....~+..2....
01c0 - 6c 06 7c b5 46 8c c6 97-4e 05 3e 4e 78 0c 5e 5a l.|.F...N.>Nx.^Z
01d0 - 91 b6 58 cf 83 9f 87 2d-81 05 0e 41 ba e9 ca 9e ..X....-...A....
01e0 - 65 ac 95 85 41 e1 26 a0-fd 22 10 2a a5 f4 d7 f6 e...A.&..".*....
01f0 - 17 14 05 d5 7a 0a e8 35-37 a7 08 88 80 c8 e2 4d ....z..57......M
0200 - 5b a7 3b bf b1 97 26 78-1c 39 b3 22 8d 7f 8a 5c [.;...&x.9."...\
0210 - 16 f3 0d f5 7b 34 57 78-9e 71 95 53 33 4e 45 ce ....{4Wx.q.S3NE.
0220 - a4 3d ee 13 51 5b 79 72-fd b3 a6 86 af b3 da ba .=..Q[yr........
0230 - d2 f9 87 de 9e 25 aa 14-fa 3c fb 1b fd 5a a9 70 .....%...<...Z.p
0240 - 02 9f f6 f8 f7 27 aa 56-12 8e 11 94 82 8d cf 0c .....'.V........
0250 - cc 16 d7 53 2c 57 9d c9-b3 c7 15 dc b6 59 9c 49 ...S,W.......Y.I
0260 - af 38 70 d5 d0 53 60 2e-a5 a7 aa 05 92 2e 5f 74 .8p..S`......._t
0270 - 42 bb f2 9a 91 41 a2 f1-4f 8f 8f 9a bf 07 68 cd B....A..O.....h.
0280 - 42 95 5b 7a 92 76 ac ed-31 b7 aa 8f 2d a8 c9 f9 B.[z.v..1...-...
0290 - 2c cd fa 8e 6d 16 10 6c-24 c2 94 57 d8 1d 0c bb ,...m..l$..W....
02a0 - 0f c5 d4 ad 5a 71 ba 41-85 33 2c bd 60 ae 84 2f ....Zq.A.3,.`../
02b0 - 6e 35 54 54 f3 85 c3 8e-31 52 0a 9e c1 2c 43 dd n5TT....1R...,C.
02c0 - 1a 17 86 ef ed c2 bd 90-0e 54 5c ea 97 2b f1 9d .........T\..+..
02d0 - 83 9a dd 08 f8 c3 e1 42-36 d8 1b ef 39 1f 10 25 .......B6...9..%
02e0 - b4 12 29 fa 93 2a 4d 09-84 27 ff 24 86 b9 af fb ..)..*M..'.$....
02f0 - 62 90 20 a1 b1 a1 bc 3a-d4 f7 b1 fa ca 67 b0 3c b. ....:.....g.<
0300 - 0b 11 8b c2 4c d4 72 bb-75 9b 53 0a 45 98 ed 63 ....L.r.u.S.E..c
0310 - 57 e9 7b e0 88 01 20 05-f8 a2 37 71 76 c0 5a d7 W.{... ...7qv.Z.
0320 - 2c 75 e3 74 24 c9 3d 9f-00 a5 ce 0a 21 69 f1 61 ,u.t$.=.....!i.a
0330 - 2a 2d d4 ed fa 97 ea cd-ce 02 c8 b7 a0 99 d6 b8 *-..............
0340 - 33 bf c8 bc a0 c6 96 e2-b8 5b 5f b1 b7 e3 52 d7 3........[_...R.
0350 - 4f 28 6a 27 4c 65 9a a1-a9 47 8c cf 7f fd a1 a6 O(j'Le...G......
0360 - b5 d7 4f 36 6c 8d 99 62-05 b5 fb 60 13 1f a1 29 ..O6l..b...`...)
0370 - 03 4c 4b 63 d5 d4 cd cc-bd 90 ee 38 75 bb d5 1c .LKc.......8u...
0380 - d2 1b 49 de 3d c0 a4 f9-cc 36 65 e7 9f d7 c8 db ..I.=....6e.....
0390 - bc 1f 9e 35 d7 12 17 cd-75 e9 06 68 fb 5c 82 a2 ...5....u..h.\..
03a0 - 6b d6 ed c1 c4 93 6c cc-b5 16 7e 30 8b 27 08 4e k.....l...~0.'.N
03b0 - 86 09 a4 95 e8 c3 ae b1-e4 1e af 28 d9 96 2b e9 ...........(..+.
03c0 - 79 b4 82 46 f6 e6 bc 13-f8 98 1d 3f c3 ec b5 d7 y..F.......?....
03d0 - 0a 91 5d 61 b1 e1 0f 21-d3 18 68 48 70 6c 18 df ..]a...!..hHpl..
03e0 - 29 53 46 e2 0b 55 b5 19-e4 c8 d3 5b 5f c1 3b 3c )SF..U.....[_.;<
03f0 - 40 75 0b 82 75 c6 be 23-4a e4 57 ac e4 5a 8b d9 #u..u..#J.W..Z..
0400 - 3a d9 d6 fa 35 8b 17 be-e4 18 7a 32 50 c7 cc 82 :...5.....z2P...
0410 - 4e 7d cc c3 67 7e 14 5a-5b 79 cb af c0 48 2e b8 N}..g~.Z[y...H..
0420 - ea 3b ad 0e 5d 11 c3 3b-f6 3b 6f e8 bf 28 02 07 .;..]..;.;o..(..
0430 - d6 ea 3e 98 96 6b 03 c2-86 6e a9 81 0b 10 8c 38 ..>..k...n.....8
0440 - b3 21 37 a5 67 0e 9a 41-4e c5 7a 1b c9 fe 99 02 .!7.g..AN.z.....
0450 - 77 91 01 ec 81 d3 46 46-9a 0b 9f 23 85 a4 32 88 w.....FF...#..2.
0460 - b9 10 e3 26 9a a1 17 95-4c b8 5d f0 ce d4 e2 52 ...&....L.]....R
0470 - b3 93 29 6b 1c 1c 54 59-4b 41 34 b6 f1 0e 64 5f ..)k..TYKA4...d_
0480 - bd ed af ef c1 a2 b9 f2-58 a8 ce 06 29 22 09 3e ........X...)".>
0490 - 35 21 24 bc 87 86 bc 7d-02 ec 4e 4e df af b3 be 5!$....}..NN....
04a0 - cb cc 56 0c 19 ea 83 96-c4 4d 39 a9 af 29 0b 4f ..V......M9..).O
04b0 - 4b 59 fc 53 85 ce c1 64-79 2d 00 04 e6 1d 5b 30 KY.S...dy-....[0
04c0 - 1f 17 89 e1 4f f5 e7 dd-02 9f cd 84 79 62 d0 f3 ....O.......yb..
04d0 - 17 2d 44 04 d1 e0 cd bb-07 14 8f fc 78 b1 a9 32 .-D.........x..2
04e0 - 41 6a 4c 9b d7 b5 0a 24-99 fd b3 63 f3 6e 72 f3 AjL....$...c.nr.
04f0 - 33 4d ba 19 ba 56 11 67-18 0f 19 4f ef 95 d2 ce 3M...V.g...O....
0500 - a0 7d d6 74 1e 61 11 76-02 10 f2 c8 d1 ee 50 f1 .}.t.a.v......P.
0510 - f6 7f 18 75 dd d9 af 6f-b1 a2 46 dd f2 26 08 6b ...u...o..F..&.k
0520 - d3 1c 65 9b 10 8b e6 32-5e ca 05 82 42 b4 42 49 ..e....2^...B.BI
0530 - a1 2e 73 fd 0d 03 37 65-8c 50 c0 d7 e3 30 01 bd ..s...7e.P...0..
0540 - e6 4e b2 71 4b bd 96 40-e0 40 6a 62 83 a0 fe e0 .N.qK..#.#jb....
0550 - e6 66 42 ec 84 f3 04 60-ba 8d 5b d5 fc 22 40 4f .fB....`..[.."#O
0560 - 22 1f ca 3c 6b 6b bb e1-c8 ba 96 55 a3 63 2e fa "..<kk.....U.c..
0570 - c1 17 42 3c 25 68 4c 9a-45 19 13 40 7a f9 6e 4b ..B<%hL.E..#z.nK
0580 - 71 75 d1 c2 d4 81 76 23-88 31 ec d1 ca 69 99 f0 qu....v#.1...i..
0590 - a5 e4 cb 7f f2 2e 95 19-e5 7a 05 60 d7 d4 b1 31 .........z.`...1
05a0 - 55 53 1b 93 dd 1a 33 3b-70 5a ca 76 f9 71 04 35 US....3;pZ.v.q.5
05b0 - ce 6b 44 bf bd 9e db 5d-e0 31 ed 5e 6f b4 94 4b .kD....].1.^o..K
05c0 - 11 99 c0 b5 b9 a9 09 ca-e4 67 9e 05 7d c4 ba ed .........g..}...
05d0 - 24 1e 27 b9 59 7a b8 d9-63 ec 6a e4 c0 10 30 09 $.'.Yz..c.j...0.
05e0 - 17 b3 05 ff 08 60 24 73-28 ad 36 fe 3a c0 23 39 .....`$s(.6.:.#9
05f0 - a7 ce 51 9d 5c 21 f0 14-5c de 7c f9 4e c3 eb 98 ..Q.\!..\.|.N...
0600 - 44 46 67 ec 2d 31 2b cd-07 c9 60 59 ee 4d da c2 DFg.-1+...`Y.M..
0610 - 66 ec fa 9b ec e6 35 dc-b3 04 2d 6b 1d 32 14 ba f.....5...-k.2..
0620 - c0 23 bf 10 7c 30 dc e4-18 f2 4a 57 90 e3 05 0e .#..|0....JW....
Start Time: 1424168427
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
closed
[Update]
I've already opened port 2195 and 2196 on my ec2 security group inbound traffic. also listened for both ports on my LBS.
1) Check that port 2195 TCP port is open. AWS instances have a very locked down security policy. You can see this in the EC2 console.
2) Check your certificate.
3) Check that the device token is issued for the right certificate & app IDA.
4) Consider using one of the numerous PHP APNS libraries. Your code won't scale.
Ok i've solved the problem after spent a day at it.
The problem is with the way we provision the certs. We deleted everything and started all over again. the main difference this time round was that we generated a separate CSR for development and production instead of sharing the same CSR.
So the steps to proper cert generation are as follows:
1) Use Keychain Access to generate csr
2) Upload csr to apple developer and download the .cer
3) Convert .cer to .pem using terminal
4) Download.p12 from keychain
5) Convert .p12 to .pem using terminal
6) Combine the .cer.pem and .p12.pem into one file
for detailed steps follow:
http://www.raywenderlich.com/32960/apple-push-notification-services-in-ios-6-tutorial-part-1
Do this 6 steps separately for developer and then for production.
I think you should re-check SSL on 2915 and 2916. If it still does not work, you need to generate provision file again. You have to log error messages returned by Apple server. I hope that you can resolve this issue.
Would someone please explain why this script sometime return only 15 bytes in hex string representation?
for i in {1..10}; do
API_IV=`openssl rand 16`; API_IV_HEX=`echo -n "$API_IV" | od -vt x1 -w16 | awk '{$1="";print}'`; echo $API_IV_HEX;
done
like this:
c2 2a 09 0f 9a cd 64 02 28 06 43 f8 13 80 a5 04
fa c4 ac b1 95 23 7c 36 95 2d 5e 0e bf 05 fe f4
38 55 d3 b4 32 bb 61 f4 fd 17 92 67 e2 9b b4 04
6d a7 f8 46 e9 99 bd 89 87 f9 7f 2b 15 5a 17 8a
11 c8 89 f4 8f 66 93 f1 6d b9 2b 64 7e 01 61 68
93 e3 9d 28 95 e1 c8 92 e5 62 d9 bf 20 b3 1c dd
37 64 ef b0 2f da c7 60 1c c8 20 b8 28 9d f9
29 f0 5a e9 cc 36 66 de 02 82 fc 8e 36 bf 5d d1
b2 57 d8 79 21 df 73 1c af 07 e9 80 0a 67 c6 15
ba 77 cb 92 39 42 39 f9 a4 57 c8 c4 be 62 19 54
If pipe the "openssl rand 16" directly to the od command then it works fine, but I need the binary value. Thanks for your help.
echo, like various other standard commands, considers \x00 as an end-of-string marker. So stop displaying after it.
Maybe you are looking to the -hex option of openssl rand:
sh$ openssl rand 16 -hex
4248bf230fc9dd927ab53f799e2a9708
Given that option is available on your system, your example could be rewritten:
sh$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
sh$ for i in {1..10}; do
openssl rand 16 -hex | sed -e 's|..|& |g' -e 's| $||'
done
20 cb 6b 7a 85 2d 0b fe 9e c7 d0 4b 91 88 1b bb
5d 74 99 5e 05 c9 7d 9d 37 dd 02 f3 23 bb c5 b7
51 e9 0f dc 58 04 5e 30 e3 6b 9f 63 aa fc 95 05
fc 6b b8 cb 05 82 53 85 78 0e 59 13 3b e7 c1 4b
cf fa fc d9 1a 25 df e0 f8 59 71 a6 2c 64 c5 87
93 1a 29 b4 5a 52 77 bb 3f bb 1d 0a 46 5d c8 b4
0c bb c2 b2 b4 89 d4 37 1c 86 0a 7a 58 b8 64 e2
ee fc a7 ec 6c f8 7f 51 04 43 d6 00 d8 79 65 43
b9 73 9e cc 4b 42 9e 64 9d 5b 21 6a 20 b7 c3 16
06 8a 15 22 6a d5 ae ab 9a d2 9f 60 f1 a9 26 bd
If you need to later convert from hex to bytes use this perl one-liner:
echo MY_HEX_STRING |
perl -ne 's/([0-9a-f]{2})/print chr hex $1/gie' |
my_tool_reading_binary_input_from_stdin
(from https://stackoverflow.com/a/1604770/2363712)
Please note I pipe to the client program and o not use a shell variable here, as I think it cannot properly handle the \x00.
As the bash cannot properly deal with binary strings containing \x00 your best bet if you absolutely want to stick with shell programming is to use an intermediate file to store binary data. And not a variable:
This is the idea. Feel free to adapt to your needs:
for i in {1..10}; do
openssl rand 16 > api_iv_$i # better use `mktemp` here
API_IV_HEX=`od -vt x1 -w16 < api_iv_$i | awk '{$1="";print}'`
echo $API_IV_HEX;
done
sh$ bash t.sh
cf 06 ab ab 86 fd ef 22 1a 2c bd 7f 8c 45 27 e5
2a 01 9c 7a fa 15 d3 ea 40 89 8b 26 d5 4f 97 08
55 2e c9 d3 cd 0d 3a 6f 1b a0 fe 38 6d 0e 20 07
fe 60 35 62 17 80 f2 db 64 7a af da 81 ff f7 e0
74 9a 5c 39 0e 1a 6b 89 a3 21 65 01 a3 de c4 1c
c3 11 45 e3 e0 dc 66 a3 e8 fb 5b 8a bd d0 7d 43
a4 ee 80 f8 c8 8b 4e 50 5c dd 21 00 3b d0 bc cf
e2 d5 11 d4 7d 98 08 a7 16 7b 8c 56 44 ba 6d 53
ad 63 65 fd bf 3f 1f 4a a1 c5 d0 58 23 ae d1 47
80 74 f1 d0 b9 00 e5 1d 50 74 53 96 4b ce 59 50
sh$ hexdump -C ./api_iv_10
00000000 80 74 f1 d0 b9 00 e5 1d 50 74 53 96 4b ce 59 50 |.t......PtS.K.YP|
00000010
As a personal opinion, if you really have a lot of binary data processing, I would recommend to switch to some other language more data oriented (Python, ...)
Because the missing byte was an ASCII NUL '\0' '\x00'. The echo command stops printing its argument(s) when it comes across a null byte in each argument.