To start off, I'm not a programmer or script writer. I'm modding a 3d model file of a game and it involves using a hex editor to input values into the float32 box in a hex editor like HxD.
So i'm basically putting in values for stuff like vertex coordinates, UV coordinates, etc.
HxD automatically converts the values i put in the float32 box to hex. (All tested, works in-game). However this a long tedious process because i have to put the values in one by one by one.
My question is, is there a script or program where i can just paste a list of values, like:
0.298584
0.423096
0.308350
0.417480
0.268066
0.392578
0.321045
0.464844
0.309814
0.464844
0.308350
0.511963
0.298584
0.506348
0.268066
0.536865
0.284668
0.498291
0.260010
0.523193
Then the script will automatically convert the list of values as float32 into hex, like:
01 E0 98 3E 0A A0 D8 3E 0D E0 9D 3E F0 BF D5 3E F2 3F 89 3E FC FF C8 3E 03 60 A4 3E 08 00 EE 3E F1 9F 9E 3E 08 00 EE 3E 0D E0 9D 3E 02 10 03 3F 01 E0 98 3E 06 A0 01 3F F2 3F 89 3E FC 6F 09 3F 01 C0 91 3E FF 1F FF 3E 08 20 85 3E FA EF 05 3F
or
01E0983E0AA0D83E0DE09D3EF0BFD53EF23F893EFCFFC83E0360A43E0800EE3EF19F9E3E0800EE3E0DE09D3E0210033F01E0983E06A0013FF23F893EFC6F093F01C0913EFF1FFF3E0820853EFAEF053F
It would help me make this process less time consuming.
I've been searching other stackoverflow questions, but most of them seem to focus on converting a single float to hex rather than a list of floats. That plus i have limited scripting, programming knowledge.
Related
Currently, I am attempting to generating a hash of a user password for PDF, given the encrypted PDF file and the plain password. I follow the instruction of this article. However, the hash I've computed is different from the hash stored in the PDF file.
The hashed user password (/U entry) is simply the 32-byte padding
string above, encrypted with RC4, using the 5-byte file key. Compliant
PDF viewers will check the password given by the user (by attempting
to decrypt the /U entry using the file key, and comparing it against
the padding string) and allow or refuse certain operations based on
the permission settings.
First, I padded my password "123456" using a hardcoded 32-byte string, which gives me
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
I tried to compute the hash with RC4 using the 5-byte file key as the key. According to the article:
The encryption key is generated as follows:
1. Pad the user password out to 32 bytes, using a hardcoded
32-byte string:
28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
2E 2E 00 B6 D0 68 3E 80 2F 0C A9 FE 64 53 69 7A
If the user password is null, just use the entire padding
string. (I.e., concatenate the user password and the padding
string and take the first 32 bytes.)
2. Append the hashed owner password (the /O entry above).
3. Append the permissions (the /P entry), treated as a four-byte
integer, LSB first.
4. Append the file identifier (the /ID entry from the trailer
dictionary). This is an arbitrary string of bytes; Adobe
recommends that it be generated by MD5 hashing various pieces
of information about the document.
5. MD5 hash this string; the first 5 bytes of output are the
encryption key. (This is a 40-bit key, presumably to meet US
export regulations.)
I appended the hashed owner key to the padded password, which gives me
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
C4 31 FA B9 CC 5E F7 B5 9C 24 4B 61 B7 45 F7 1A
C5 BA 42 7B 1B 91 02 DA 46 8E 77 12 7F 1E 69 D6
Then, I appended the /P entry (-4), treated as a four-byte integer, encoded with little endian, which gives me
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
C4 31 FA B9 CC 5E F7 B5 9C 24 4B 61 B7 45 F7 1A
C5 BA 42 7B 1B 91 02 DA 46 8E 77 12 7F 1E 69 D6
FC FF FF FF
Last, I appended the file identifier to it. The trailer of my PDF is:
trailer
<<
/Size 13
/Root 2 0 R
/Encrypt 1 0 R
/Info 4 0 R
/ID [<B5185D941CC0EA39ACA809F661EF36D4> <393BE725532F9158DC9E6E8EA97CFBF0>]
>>
and the result is
31 32 33 34 35 36 28 BF 4E 5E 4E 75 8A 41 64 00
4E 56 FF FA 01 08 2E 2E 00 B6 D0 68 3E 80 2F 0C
C4 31 FA B9 CC 5E F7 B5 9C 24 4B 61 B7 45 F7 1A
C5 BA 42 7B 1B 91 02 DA 46 8E 77 12 7F 1E 69 D6
FC FF FF FF B5 18 5D 94 1C C0 EA 39 AC A8 09 F6
61 EF 36 D4 39 3B E7 25 53 2F 91 58 DC 9E 6E 8E
A9 7C FB F0
MD5 hashing this block of data returns 942c5e7b2020ce57ce4408f531a65019. I RC4-ed the padded password with cryptii using the first 5 bytes of the MD5 hash as the key. However, it returns
90 e2 b5 21 2a 7d 53 05 70 d9 5d 26 95 c7 c2 05
6e 2a 28 40 63 e7 4a d4 e9 05 86 71 43 d1 39 d6
while the hash in PDF is
58 81 CA 74 65 DC 2E A7 5D D2 39 D4 43 9C 0D DE
28 BF 4E 5E 4E 75 8A 41 64 00 4E 56 FF FA 01 08
Which step am I doing wrong? I suspect that the problem happens because
I am appending the File Idenifier in a wrong format
I am using the wrong drop bytes with RC4.
The hash function is not for PDF 1.6
I make some mistake during those process
Or maybe the article is actually wrong
Files: Original PDF dummy.pdf, dummy-protected.pdf (Password: 123456)
Please help
There are two issues in your calculation:
The article to use refers to PDF encryption algorithms available for PDF-1.3 but your document is encrypted using an algorithm introduced with PDF-1.5.
You make an error when appending the file identifier - actually only the first entry of the ID array shall be appended, not both (which is not really clear from the article you use).
In a comment you asked accordingly
where can I find the password hashing detail for >V1.3 PDF?
I would propose using the PDF specification, ISO 32000.
As ISO specifications go, they are not free, but Adobe used to provide a version of ISO 32000-1 with merely the ISO header removed on their web site. Some days ago it has been removed (By design? By error? I don't know yet.) but you still find copies of it googl'ing for "PDF32000".
The relevant section in ISO 32000-1 is 7.6 Encryption and in particular 7.6.3 Standard Security Handler.
Following that information you should be able to correctly calculate the value in question.
(Alternatively you can also use old Adobe PDF references, the editions for PDF 1.5, 1.6, and 1.7 should also give you the information required for decrypting your document. But these references have been characterized as not normative in nature by prominent Adobe employees, so I would go for the ISO norm.)
Beware, though: After ISO 32000-1 had been published, Adobe introduced an AES-256 encryption scheme as an extension which obviously is not included in ISO 32000-1. You can find a specification in "Adobe Supplement to ISO 32000, base version 1.7, extension level 3".
Furthermore, with ISO 32000-2 that Adobe AES-256 encryption scheme and all older schemes became deprecated, the only encryption scheme to use with PDF-2.0 is a new AES-256 encryption scheme described in ISO 32000-2 which is based on the Adobe scheme but introduces some extra hashing iterations.
Is there a way to easily remove the first 5 characters from this hexdump (from a .pcap), remove the spaces from the hex characters, and then after the 32nd hex character, remove the decoded ascii? I've read into the cut operator, as well as using a Python script but couldn't get it working (it just seemed to create an extremely large .txt).
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 c6 9a 59 40 00 40 06 88 38 c0 a8 01 c8 ac d9 ...Y#.#..8......
0020 a8 56 8b 18 01 bb 85 40 40 4f 4d 73 a6 1b 80 18 .V.....##OMs....
0030 05 c1 fd 7f 00 00 01 01 08 0a df 7b 09 99 3e cb ...........{..>.
0040 4d 9f 17 03 03 00 8d d3 6d ce 93 8c 4d ec bd 16 M.......m...M...
0050 91 21 b4 cf d5 cf 40 d6 79 5c 5d 0a 33 41 51 d3 .!....#.y\].3AQ.
0060 5c 81 1b 40 f7 bc fb 26 1e c3 0a 6d 1b e5 62 d5 \..#...&...m..b.
0070 04 18 43 a1 ec 8f 7f ca 3e bf 62 2f 77 f1 e4 0e ..C.....>.b/w...
0080 62 d0 12 0a da cc 1c 03 f3 e6 32 d6 de 65 27 aa b.........2..e'.
0090 3f 85 35 4d 11 7f 5a 1a 2d 41 08 27 97 98 e8 04 ?.5M..Z.-A.'....
00a0 88 03 1f 66 bd 56 f2 4c c2 0e 7d 47 5f c6 5d b0 ...f.V.L..}G_.].
00b0 52 d7 16 31 27 28 d5 01 9f b0 01 3f 14 3d a7 33 R..1'(.....?.=.3
00c0 39 b2 65 6c f2 3d 76 b3 2c 47 5b 2c f6 03 4a c8 9.el.=v.,G[,..J.
00d0 37 b6 24 9a 7.$.
Expected (for the first line):
cafe0000babedead0000beef08004500
Here's what I tried to get rid of the first 5 characters:
tail -c +6 test2.txt > newfile.txt
Could you please try following, written and tested with shown samples in GNU awk.
awk '{val="";val=substr($0,5,50);gsub(/ +/,"",val);print val}' Input_file
Explanation: Adding detailed explanation for above.
awk ' ##Starting awk program from here.
{
val=""
val=substr($0,5,50) ##Creating val which has sub string of characters starting from 5th index to 50 more characters of current line.
gsub(/ +/,"",val) ##Globally substituting spaces with NULL in val here.
print val ##Printing val here.
}
' Input_file ##Mentioning Input_file name here.
sed -E 's/^.{6}(.{47}).*/\1/; s/ //g'
The first substitution preserves only 47 characters found after the first 6 characters. The second substitution removes the spaces from those 47 characters.
Similar logic with perl:
perl -lne 'print substr($_,6,47) =~ tr/ //dr'
perl -pe 's/^.{6}(.{47}).*/$1=~tr| ||dr/e'
You could use cut too, if you are willing to spell out all the character locations:
cut -c7,8,10,11,13,14,16,17,19,20,22,23,25,26,28,29,31,32,34,35,37,38,40,41,43,44,46,47,49,50,52,53
$ awk -v OFS= '{$1=$NF=""} 1' file
cafe0000babedead0000beef08004500
00c69a59400040068838c0a801c8acd9
a8568b1801bb8540404f4d73a61b8018
05c1fd7f00000101080adf7b09993ecb
4d9f170303008dd36dce938c4decbd16
9121b4cfd5cf40d6795c5d0a334151d3
5c811b40f7bcfb261ec30a6d1be562d5
041843a1ec8f7fca3ebf622f77f1e40e
62d0120adacc1c03f3e632d6de6527aa
3f85354d117f5a1a2d4108279798e804
88031f66bd56f24cc20e7d475fc65db0
52d716312728d5019fb0013f143da733
39b2656cf23d76b32c475b2cf6034ac8
37b6249a
awk '{ for(i=1;i<=NF;i++) { if (length($i)==2) { printf "%s",$i } } printf "\n" }' file
Search through all space separated fields and if the length of the field is 2, print.
I would do it following way using GNU AWK, let file.txt content be
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 c6 9a 59 40 00 40 06 88 38 c0 a8 01 c8 ac d9 ...Y#.#..8......
0020 a8 56 8b 18 01 bb 85 40 40 4f 4d 73 a6 1b 80 18 .V.....##OMs....
0030 05 c1 fd 7f 00 00 01 01 08 0a df 7b 09 99 3e cb ...........{..>.
0040 4d 9f 17 03 03 00 8d d3 6d ce 93 8c 4d ec bd 16 M.......m...M...
0050 91 21 b4 cf d5 cf 40 d6 79 5c 5d 0a 33 41 51 d3 .!....#.y\].3AQ.
0060 5c 81 1b 40 f7 bc fb 26 1e c3 0a 6d 1b e5 62 d5 \..#...&...m..b.
0070 04 18 43 a1 ec 8f 7f ca 3e bf 62 2f 77 f1 e4 0e ..C.....>.b/w...
0080 62 d0 12 0a da cc 1c 03 f3 e6 32 d6 de 65 27 aa b.........2..e'.
0090 3f 85 35 4d 11 7f 5a 1a 2d 41 08 27 97 98 e8 04 ?.5M..Z.-A.'....
00a0 88 03 1f 66 bd 56 f2 4c c2 0e 7d 47 5f c6 5d b0 ...f.V.L..}G_.].
00b0 52 d7 16 31 27 28 d5 01 9f b0 01 3f 14 3d a7 33 R..1'(.....?.=.3
00c0 39 b2 65 6c f2 3d 76 b3 2c 47 5b 2c f6 03 4a c8 9.el.=v.,G[,..J.
00d0 37 b6 24 9a 7.$.
then
awk 'BEGIN{FS="[ ]{2,}"}{gsub(/ /, "", $2);print $2}' file.txt
output:
cafe0000babedead0000beef08004500
00c69a59400040068838c0a801c8acd9
a8568b1801bb8540404f4d73a61b8018
05c1fd7f00000101080adf7b09993ecb
4d9f170303008dd36dce938c4decbd16
9121b4cfd5cf40d6795c5d0a334151d3
5c811b40f7bcfb261ec30a6d1be562d5
Explanation: I set field seperator (FS) for 2 and more spaces, then I remove all spaces from 2nd column ($2) and print such changed column.
Using Perl,
$ perl -ne ' m/\s+(.+)\s{2,}/ ; ($s=$1)=~s/\s//g; print "$s\n" ' flowermia.pcap
cafe0000babedead0000beef08004500
00c69a59400040068838c0a801c8acd9
a8568b1801bb8540404f4d73a61b8018
05c1fd7f00000101080adf7b09993ecb
4d9f170303008dd36dce938c4decbd16
9121b4cfd5cf40d6795c5d0a334151d3
5c811b40f7bcfb261ec30a6d1be562d5
041843a1ec8f7fca3ebf622f77f1e40e
62d0120adacc1c03f3e632d6de6527aa
3f85354d117f5a1a2d4108279798e804
88031f66bd56f24cc20e7d475fc65db0
52d716312728d5019fb0013f143da733
39b2656cf23d76b32c475b2cf6034ac8
37b6249a
$
We have ended our contract with a Saas tool. We have received our archived data as a Oracle database with word & pdf documents in a Blob column. We were told that the Blob data is in Base64 binary and needs to be decoded before downloading to a file. When looking at the data in the Blob column it looks like this:
í]pÅ™þgµ«•,´–‘°
8„I–
c#Y’-Ù²ül‡àF»#íˆÝõήŒHRˆ#! qsG\¹‹I ¹ÜåçQ<ª #G.<'Áªâ«
÷È«øB‘J¼÷ýÝ3»#iW–d‡×Í/}ÛÓÓÝÿß÷ßwïÎãðç½ç›ÿƒ&ÐZ*£¹J*wS€
N$LÔmŸ;‘ËåøÔz çÑÛŠ~wß÷èüë*ýDÇêÍ÷,ßÐ#TCÃÃ÷ÔßS?ÑBˆ*ý
Ô|Ñã7I4ÔLÎã¦\®ö¤ÇÝ+>U?
The same as hexdump:
00000000 1f 8b 08 00 00 00 00 00 00 00 ed 5d 0b 70 1c c5 |...........].p..|
00000010 99 fe 67 b5 ab 95 2c ad b4 96 91 b0 8d 0d 03 38 |..g...,........8|
00000020 84 18 49 96 0d 06 63 07 23 59 92 2d d9 b2 fc 90 |..I...c.#Y.-....|
00000030 6c 87 e0 03 46 bb 23 ed 88 dd 9d f5 ce ae 8c 48 |l...F.#........H|
00000040 52 88 40 02 21 09 71 12 73 47 5c b9 8b 49 20 b9 |R.#.!.q.sG\..I .|
00000050 dc e5 12 e7 51 3c aa 20 90 23 47 2e 3c 12 27 c1 |....Q<. .#G.<.'.|
Have tried Base64 library in PL/SQl, Java, Linux to decode but does not work.
Java:
byte[] decoded = Base64.decodeBase64(Files.readAllBytes(Paths.get(fileName)));
byte[] decodedBytes = Base64.decodeBase64(input_file);
PL/SQL:
utl_file.put(l_output, utl_raw.cast_to_varchar2(vblob));
utl_file.putl_output, utl_raw.cast_to_varchar2(utl_encode.base64_decode(vblob)));
raw_decoded := utl_encode.base64_decode(vblob);
utl_file.put_raw(l_output, utl_raw.cast_to_varchar2(raw_decoded));
Could you advise if this is a Base64 data or what format it is in? The expected result is to render blob in MS Word, PDF documents.
I have resolved this issue. Turns out the data in the blob column was direct document (word or pdf) but was compressed. So when querying the blob column used utl_compress to decompress and then directly utl_file output to a physical file.
select UTL_COMPRESS.LZ_UNCOMPRESS(BLOB_COLUMN) into v_blob from TABLE where ID =
Thank you to all who responded.
Original question for reference - see update below
This is an extremely strange problem.
I've got an iBeacon broadcasting from Phone A. Everything I've read seems to say that it's not possible for a phone to continue to broadcast as an iBeacon once it has entered the background. However, I am able to lock my phone, and I continue to see (using LightBlue or a raspberry pi) iBeacon advertising packets emitted, with identical manufacturerData. Indefinitely. Nothing about the packet is altered in any way when the phone enters the background.
Phone B is listening for beacon region enter/exit events, and ranging on enter.
Whenever Phone A is put into the background, Phone B loses it - first the number of beacons being ranged drops to 0, then the region is exited. However, I can inspect the bluetooth packets that continue to be sent across the air and clearly see that they are identical to the ones that were send when the app was in the foreground. Even the transmission rate seems to be about the same.
So my question is this: If Phone B is continuing to receive identical iBeacon-formatted advertising packets from Phone A, how does Phone B decide that it has left the region defined by those packets? None of the actual data sent over the air appears to change, so what is the loss of beacon based on?
Any insight you can give is much appreciated!
Update
Per #davidyoung's suggestion, I used hcidump on the pi to inspect the packets. I also left one of my estimotes on for reference (mac address DA:E3:1D:A7:DE:E8). My device has mac 72:F3:FC:7E:2F:DA Two cases:
Started with the app in the foreground:
pi#raspberrypi ~ $ sudo hcidump --raw & sudo hcitool lescan
[1] 2228
HCI sniffer - Bluetooth packet analyzer ver 2.4
LE Scan ...
device: hci0 snap_len: 1028 filter: 0xffffffff
DA:E3:1D:A7:DE:E8 (unknown)
> 04 3E 2A 02 01 00 01 E8 DE A7 1D E3 DA 1E 02 01 06 1A FF 4C
00 02 15 B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D DE
E8 1D A7 B6 BA
DA:E3:1D:A7:DE:E8 estimote
> 04 3E 25 02 01 04 01 E8 DE A7 1D E3 DA 19 09 09 65 73 74 69
6D 6F 74 65 0E 16 0A 18 E8 DE A7 1D E3 DA B6 E8 DE A7 1D BB
72:F3:FC:7E:2F:DA (unknown)
> 04 3E 2A 02 01 00 01 DA 2F 7E FC F3 72 1E 02 01 1A 1A FF 4C
00 02 15 B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D AE
85 69 C6 B6 A7
72:F3:FC:7E:2F:DA (unknown)
> 04 3E 0C 02 01 04 01 DA 2F 7E FC F3 72 00 A8
Started with the app in the background:
pi#raspberrypi ~ $ sudo hcidump --raw & sudo hcitool lescan
[1] 2234
HCI sniffer - Bluetooth packet analyzer ver 2.4
LE Scan ...
device: hci0 snap_len: 1028 filter: 0xffffffff
DA:E3:1D:A7:DE:E8 (unknown)
> 04 3E 2A 02 01 00 01 E8 DE A7 1D E3 DA 1E 02 01 06 1A FF 4C
00 02 15 B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D DE
E8 1D A7 B6 B5
DA:E3:1D:A7:DE:E8 estimote
> 04 3E 25 02 01 04 01 E8 DE A7 1D E3 DA 19 09 09 65 73 74 69
6D 6F 74 65 0E 16 0A 18 E8 DE A7 1D E3 DA B6 E8 DE A7 1D B6
72:F3:FC:7E:2F:DA (unknown)
> 04 3E 0F 02 01 00 01 DA 2F 7E FC F3 72 03 02 01 1A A6
72:F3:FC:7E:2F:DA (unknown)
> 04 3E 0C 02 01 04 01 DA 2F 7E FC F3 72 00 A6
I don't see any new packets being emitted when I take the app from the background to the foreground (or vice-versa), but I do see a different (much smaller) packet steadily emitted when the app is in the background. This smaller packet is only present when my app is in the background, not on a clean boot of the device.
So it would seem that although the app does continue to emit BTLE packets in the background, they're much smaller and not ibeacon-compliant. This would be consistent with what I've read around the CoreBluetooth "overflow" area when advertising in the background.
I suspect the packets you are seeing in LightBlue and on the Raspberry Pi are not the iBeacon advertisement. It may be that they were coming from a different hardware device or a different app on iOS.
Understand that iOS does allow you to advertise in the background, just not iBeacon advertisements. So if you have another app running that is advertising Bluetooth LE services its advertisements will always get picked up by LightBlue and a Raspberry Pi regardless of whether your app is in the foreground or not.
Since LightBlue does not show you the packet detail, there is no way to tell with this tool if the advertisements are from an iBeacon or not. But you can tell with a Raspberry Pi. Like this:
Start an hcidump in the background showing you raw BLE packets
sudo hcidump --raw &
Start a BLE scan
sudo hcitool lescan
This will give you a unique list of all BLE advertisement packets seen.
Try running this with your app in the background, then bring it to the foreground to see what additional advertisements are seen if any. I suspect you will see one additional advertisement, which is your iBeacon advertisement (look closely for your ProximityUUID), and you will only see it when your app is in the foreground.
My application is using SSL over SMTP.
But I faced a problem of extra byte at the end.
The packet which I recieved is as follows: (Hex dump of SSL Record packet)
17 03 01 01 00 9A 07 74 E3 4B E0 07 17 71 38 BF 29 7E 70
E9 14 CC B1 97 77 4C B9 AB A0 9F 88 7B D4 ED 14 8E 97 F2
5A BE 46 56 D4 12 BC 15 01 49 EE CE A1 ED 3F D3 6E 7F AA
DC 6B DF 41 11 74 7B 55 B8 D3 3E 8D EF 96 52 B0 BD 50 35
09 E7 2A FF 0E 39 58 C7 91 99 95 22 6F B0 73 57 28 B4 EA
C6 28 4C DC 5C DA 6C 31 FB 63 71 7D 08 F0 DD 78 C4 08 C5
27 90 04 C7 09 59 E4 83 F4 4D 9A 7B 65 E9 AF 38 44 B4 CD
9E 4D BE 80 0D 07 24 8D C3 79 99 DC 02 81 D7 97 21 16 0B
28 44 82 ED E4 5F E6 91 81 A5 28 C1 C8 92 60 36 4E DE 27
AF D0 2B EE FB 9D 12 9C 2B 4F 3F 29 F2 04 8F DC 21 39 4F
80 23 7E 78 3C A0 29 E0 67 E7 9F 90 B6 1F D4 08 63 3E CE
73 E1 17 72 8D B1 8C 3D A8 59 C0 0F 03 59 7A A6 5D F9 7A
40 57 D6 8D 94 48 93 BF D8 17 C6 70 79 36 13 D0 F1 D1 D2
69 D4 05 9D 67 86 6D E9 66 D0 83 4A D8 5E 20
The length of this packet as seen from SSL 3.1 protocol is 256 Bytes.
But there is one extra byte at the end (shown in bold at the end).
Due to this extra byte at the end, when next packet is being read, then this 20 is also read and causes error of SSL_R_WRONG_VERSION_NUMBER (I am using OpenSSL Library for SSL).
Next packet which I recieved is like (as per packet sniffer)
17 03 01 00 18 ...
But when next read is being done, OpenSSL reads packet as 20 17 03 01 .. which causes the error (since 17 03 is wrong version for 03 01)
I would like to know if this (extra byte at the end) is a part of SSL standard.
Please suggest me how to handle this case in OpenSSL. OpenSSL version is 1.0.0.
No. The extra byte is not as a part of SSL Standard.
As per SSL Standard (RFC 2246 for TLS 1.0, Latest is RFC 5246 for TLS 1.2) the record of SSL is as below:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
The fragment will be exactly of the length as specified by uint16 length member. So, the 20 must be getting inserted either incorrectly by the Server Implementation, or some other software in the middle is inserting it when the data is in network.
Openssl reads exactly the number of bytes as specified by uint16 length member which is why it doesn't read 20.
Some of the points which you can focus on are:
1. Does this happen with the first application data packet which is transferred immediately after handshake? (From the content type I assumed this packet dump is for application data)
2. Is this a random occurance? Do all connections with that particular server exhibit the same behavior?
3. You can try to get the dump of the packet sent at the Server to see if 20 is present when the packet is being sent at the Server side itself or it is getting added during it's flight.
4. Could there be a Firewall related problem? (I don't know about Firewall, so didn't give more details here)
Hope this helps!
I was bashing my head with this one today; finally resorted to this:
_sslStream.Write(merged, 0, merged.Length - 1)
Problem solved, move along!