I just lost a couple of days of work to a crashing editor. My file is now an empty file, and the last backup I have is from 4 days ago.
I have the CSS file saved in my Chromium's cache, but it looks like this:
http://myserver.example.com/style.css
HTTP/1.1 200 OK
Date: Mon, 04 Jul 2011 05:18:25 GMT
Last-Modified: Mon, 04 Jul 2011 01:10:47 GMT
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 7588
Content-Type: text/css
00000000: 5e 01 00 00 02 08 00 00 be 45 ba c7 cd 05 2e 00 ^........E......
00000010: 25 68 d9 c7 cd 05 2e 00 1d 01 00 00 48 54 54 50 %h..........HTTP
00000020: 2f 31 2e 31 20 32 30 30 20 4f 4b 00 44 61 74 65 /1.1 200 OK.Date
00000030: 3a 20 4d 6f 6e 2c 20 30 34 20 4a 75 6c 20 32 30 : Mon, 04 Jul 20
00000040: 31 31 20 30 35 3a 31 38 3a 32 35 20 47 4d 54 00 11 05:18:25 GMT.
(etc)
00000000: 1f 8b 08 00 00 00 00 00 00 03 cd 3d fd 8f db b6 ...........=....
00000010: 92 3f d7 7f 05 2f 8b 22 ed c2 f2 87 fc b1 6b 2f .?.../."......k/
00000020: 1a a0 09 5e 1e f0 5e 7b 57 34 c5 dd 0f 87 83 21 ...^..^{W4.....!
00000030: db f2 5a 89 6c f9 49 72 36 5b 63 ff f7 e3 b7 86 ..Z.l.Ir6[c.....
00000040: e4 50 1f 9b 4d ef 52 34 b1 65 71 66 38 1c ce 0c .P..M.R4.eqf8...
00000050: 87 c3 e1 f0 9a fc e3 9c 1e c9 3f e2 94 fc b1 8f ..........?.....
The entire file seems to be there, and I can get the text.
I'd like to get back the plain CSS file somehow. I tried extracting the data, but gzip says it isn't gzip format. But it doesn't seem to be gzip encoded (it's not binary, after all...). Is it base64 or something? I've had a hard time finding any info on this.
Try finding the gzip header by extracting the hex data into an editor and searching for the header as per gzip specification. You should be able to do this by finding the end of the response body and selecting the previous 7588 bytes (you have this info in the response headers: Content-Length: 7588) - this should be the first character of the header.
Depending on the flags set in the header, gzip'd files may be ASCII or binary. You can determine if data are base64 encoded as base64 scheme encodings terminate with the = character. You can decode base64 online.
Alternatively you could try a tool such as ChromeCacheViewer.
The file looks gzip. It has the 1f8b header. Chrome stores the cached files as files, you just need to find them. Google for "location of chrome cache" and find it for your platform.
Related
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.
I have an OTI Copni device and I need to install a .cap file to this Copni device. So I have JCOP tools with Eclipse and I try to upload and install. It then gives this the indicated error. I presume this is happening because of a failed authentication.
cm> /term "winscard:4|SCM Microsystems Inc. SDI011G Contactless Reader 0"
--Opening terminal
> /card -a a000000003000000 -c com.ibm.jc.CardManager
resetCard with timeout: 0 (ms)
--Waiting for card...
ATR=3B 88 80 01 00 73 C8 40 00 00 90 00 62 ;....s.#....b
ATR: T=0, T=1, Hist=0073C84000009000
=> 00 A4 04 00 08 A0 00 00 00 03 00 00 00 00 ..............
(21592 usec)
<= 6F 65 84 08 A0 00 00 00 03 00 00 00 A5 59 9F 65 oe...........Y.e
01 FF 9F 6E 06 47 91 20 17 3F 00 73 4A 06 07 2A ...n.G. .?.sJ..*
86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B 03 64 ....c...*.H..k.d
0B 06 09 2A 86 48 86 FC 6B 04 02 15 65 0B 06 09 ...*.H..k...e...
2B 85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 +...Hd...f...+..
04 01 2A 02 6E 01 02 90 00 ..*.n....
Status: No Error
cm> set-key 255/1/DES-ECB/404142434445464748494a4b4c4d4e4f 255/2/DES-ECB/404142434445464748494a4b4c4d4e4f 255/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update 255
=> 80 50 00 00 08 C2 3F 4B C4 BE B6 E5 58 00 .P....?K....X.
(43622 usec)
<= 00 00 32 98 00 09 30 97 06 25 01 02 00 10 68 6C ..2...0..%....hl
E3 CA 2C 2B 4D 2C 4B 0D 0E 62 5F 8C 90 00 ..,+M,K..b_...
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 EB FC 66 BC FA 30 91 58 5B 51 FA .......f..0.X[Q.
0C 46 D7 43 C9 .F.C.
(12557 usec)
<= 69 85 i.
Status: Conditions of use not satisfied
jcshell: Error code: 6985 (Conditions of use not satisfied)
jcshell: Wrong response APDU: 6985
Unexpected error; aborting execution
Can someone tell me how to upload a .cap file to this device?
Try ext-auth mac instead, the smart card is probably in the state OP_SECURE, which means that at minimal command MAC is required.
As JCOP tools is not publicly available nor open source, I'd suggest you try a publicly available piece of software instead:
https://github.com/martinpaljak/GlobalPlatform#globalplatform-from-openkms
(as the name of the github repository implies this is self-promotion)
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!
During SSL 3.0 handshaking server responses with the following serverhello message
16 03 00 00 51 02 00
00 4d 03 00 4f a1 c1
eb e3 fb 00 a9 c8 25
25 48 6f 89 27 ec bb
80 f3 8c 5d db f7 6c
94 56 d8 34 7a b5 9d
02 20 54 ab 20 ea 05
a6 38 6f ee 55 40 ae
af e2 5d ae 2a 4d c1
c6 f4 09 a7 08 b1 c5
49 39 87 82 d3 f7 00
39 00 00 05 ff 01 00
01 00
I understand this response as follows:
Content-type: 22 (Handshake protocol)
Version: 3.0
Length: a1 (81 bytes)
Content-type: 02 (ServerHello)
Length: 4d (77 bytes)
Version: 3.0
Random: 4f a1 c1 eb e3 fb 00 a9
c8 25 25 48 6f 89 27 ec
bb 80 f3 8c 5d db f7 6c
94 56 d8 34 7a b5 9d 02
SessionID Length: 20 (32 bytes)
SessionID: 54 ab 20 ea 05 a6 38 6f
ee 55 40 ae af e2 5d ae
2a 4d c1 c6 f4 09 a7 08
b1 c5 49 39 87 82 d3 f7
Cipher Suite: 00 39
Compression method: 00
But i can't understand how the last 7 bytes should be interpreted: 00 05 ff 01 00 01 00
That would be the renegotiation_info extension, as defined in RFC 5746:
o If this is the initial handshake for a connection, then the
"renegotiated_connection" field is of zero length in both the
ClientHello and the ServerHello. Thus, the entire encoding of the
extension is ff 01 00 01 00. The first two octets represent the
extension type, the third and fourth octets the length of the
extension itself, and the final octet the zero length byte for the
"renegotiated_connection" field.
http://www.faqs.org/rfcs/rfc4253.html
::http://www.faqs.org/rfcs/rfc4251.html
Does anyone know the SSH key file format?
!! UPDATE
!! The base64 function I was using doesn't work. After running the key file through a different function (mozilla's built in atob()) the data fit into the specifications listed above.
I have rsa key files created with puttygen, but I must be missing something critical. Here is the hex of the public section:
00 00 00 07 73 73 68 2d 72 73 61 00 00 00 01 25
00 00 00 10 1c 1c 57 3f 4f 58 63 69 38 ad 19 35
b5 28 3d 78 53 35 53 6c 15 0e 69 23 ac 17 14 84
21 29 13 07 36 62 90 26 37 93 73 17 28 b8 ce 95
c3 11 24 21 61 b7 82 d9 04 42 97 f8 27 c3 44 06
46 ca e8 a3 a3 34 d7 3c c3 95 13 dd 16 1b 2c 29
7c 35 19 5f c2 7a 17 d5 14 0d 26 36 27 18 71 67
8d 9c 5b c4 7d
first 4 bytes are UINT 7, the number of bytes inthe following string "ssh-rsa" but the format stops making sense after that. It SHOULD be followed by two MPINT but they lengths don't add up for the 3rd value.
Thanks!
It's in ASN.1 syntax. You should be able to use an ASN.1 parser along with the specs for the file contents to decipher it.