I'm struggling with extracting application/x-gzip HTTP responses manually because Fiddler can't extract them. For example, my Android device queries https://android.clients.google.com/fdfe/selfUpdate from time to time. The response has Content-Type: application/x-gzip and the body is only 9 bytes long (hex):
0A 03 BA 02 00 2A 02 08 00
According to the following W3C paper: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5
applications SHOULD consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
However, GZIP should start with hex bytes 1F 8B. And according to GZIP file format, the header is always 10 bytes long so if the response body has only 9 bytes, it can't be stored as a valid GZIP file. If I store it in a file anyway, none of the following extractors can process it: gzip, arclite, 7-Zip, WinRar. As mentioned before, Fiddler can't extract it too.
Perhaps the GZIP 10-byte header was stripped - let's add it. The file contents is now:
1F 8B 08 00 00 00 00 00 00 00
0A 03 BA 02 00 2A 02 08 00
Unfortunately, this doesn't really change anything, none of the extractors mentioned above can process it.
EDIT:
Looking at a few other x-gzip responses from Google servers, the body always starts with 0x0A byte. No other similarity found.
Related
I have issues convincing Firefox 71 to cache a large (>4MB) image. I notice both in developer tools (as being logged) and during normal operations (as per loading delay) that the image is loaded every time the page is accessed.
Although I thought I provided all the necessary response headers, Firefox is not sending If-Modified-Since or If-None-Match request headers.
These are the HTTP headers my server is sending:
$ HEAD https://😉/image.png
200 OK
Cache-Control: public, max-age=31536000, immutable
Connection: close
Date: Sat, 04 Jan 2020 19:52:20 GMT
Accept-Ranges: bytes
ETag: "564cd5fb-4484b0"
Server: nginx/1.14.0 (Ubuntu)
Content-Length: 4490416
Content-Type: image/png
Last-Modified: Wed, 18 Nov 2015 19:48:11 GMT
Client-Date: Sat, 04 Jan 2020 19:52:20 GMT
Client-Peer: 😛
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Client-SSL-Cert-Subject: /CN=😉
Client-SSL-Cipher: ECDHE-RSA-CHACHA20-POLY1305
Client-SSL-Socket-Class: IO::Socket::SSL
The web page loads the image via JavaScript:
let mapImg = new Image();
mapImg.src = 'image.png';
I believe I did everything according to documentation and wonder if I made some wrong combination of response headers, encryption, compression, and loading method?
I have setup advertising in bluez using hcitool The device sow up as expected.
The setup is done as follow:
#advertising
sudo hcitool -i hci0 cmd 0x08 0x0008 18 02 01 06 02 0a 00 11 07 9e ca dc 24 0e e5 a9 e0 93 f3 a3 b5 01 00 40 6e 00 00 00 00 00 00 00
#scan response
sudo hcitool -i hci0 cmd 0x08 0x0009 0d 0c 09 6f 6f
#setup advertising interval
sudo hcitool -i hci0 cmd 0x08 0x0006 80 02 c0 03 00 00 00 00 00 00 00 00 00 07 00
#turn advertising on
sudo hcitool -i hci0 cmd 0x08 0x000a 01
After a devie connect the advertising is gone. How kan I keep continuing advertising?
I did a workaround calling sudo hcitool -i hci0 cmd 0x08 0x000a 01 repeatedly.
Another question is how setup the advertising above using the d-bus interface.
ps.
Many info have been found in Bluetooth specification 5.0 (Core_v5.0.pdf), 7.8.5 LE Set Advertising Parameters command p.1321
Most stacks/implementations (including BlueZ) will automatically switch off adverts when a device's state switches from advertising to accepting an incoming connection. The reason for this is that according to the stack Link Layer states (Please see picture below which is available Bluetooth specification v5.1, Vol 6, Part B, Section 1.1: Link Layer States), the state of the device should change from Advertising to Connected as the device cannot be in two different states at the same time.
However, once you are in a connection you can restart your adverts as you have done manually. Please have a look at the answer below for more information:-
Link Layer state for more than one simultaneous connection
I hope this helps.
I'm an ios programmer
my server gave me h264 data with TCP
but the data is not freindly like this
The startcode (00 00 00 01 or 00 00 01) is not at the start of each response data
So how can i get a whole nalu?
I captured and decrypted an HTTPS request using fiddler. It looks about like this:
CONNECT qwer1234.com:443 HTTP/1.0
User-Agent: Blabla Example/1.0
Host: qwer1234.com:443
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: 13 35 55 0B F2 3C 9D A3 A2 C2 E4 3E 66 FA D3 DD E5 15 27 33 F1 E6 CD A5 E0 C4 10 4E 41 67 32 8E
SessionID: empty
Extensions:
renegotiation_info 00
server_name qwer1234.com
status_request 01 00 00 00 00
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
signature_algorithms 00 01 06 07 05 08 03 09 04 03 06 04 04 07 01 09
SessionTicket empty
Ciphers:
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256
[002F] TLS_RSA_AES_128_SHA
[003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
Compression:
[00] NO_COMPRESSION
Is this a special kind of HTTPS request? Why is only half of the request excrypted? What do the random generated numbers mean / what are they for? How would I send this request using a WinHttpRequest? How does it differ from other HTTPS requests?
I'm kind of bad in finding the right places to ask questions like this. Tell me if you think that I should have asked this on a different page and if so, where.
This isn't a HTTPS request at all, it is a CONNECT tunnel through which HTTPS traffic subsequently flows. Client applications first send a CONNECT request to the proxy (like Fiddler) to tell them where to establish a TCP/IP connection to, then after the connection establishes, a HTTPS handshake is performed and the requests are sent.
When showing you the CONNECT tunnel, Fiddler analyzes the parameters and displays them for you to read. The actual HTTPS requests will appear after this tunnel in the Web Sessions list, if and only if you have enabled HTTPS decryption in the Tools > Fiddler Options > HTTPS screen.
The data comes from here, I take tcp socket to get it.
the response like:
HTTP/1.1 200 OK
Server: nginx/0.7.67
Date: Tue, 06 Aug 2013 08:25:48 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Content-Encoding: gzip
2e2
?
And then I decompress used the zlib function "uncompress", but get a Z_DATA_ERROR returned code. It looks like the data started position "2e2" was not a validate gzip stream data?
The transfer encoding is chunked. Each chunk of data is preceded by the chunk size specified in hexadecimal followed by a line terminator. Then, that many bytes should be read in for the content. The chunk data is followed by another line terminator. The next chunk has the same format (size followed by data) until a 0 sized chunk is sent.
You need to decode each chunk and append it to the decompress buffer. Leaving the chunk size in your data stream would not be treated as valid input by zlib.