[ / / / / / / / / / / / / / ] [ dir / 1st / acme / lit / mde / pinoy / s8s / vichan / zoo ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Email
Comment *
File
Select/drop/paste files here
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): c60fcca31b4e765⋯.png (308.53 KB, 1115x1022, 1115:1022, Hex.png) (h) (u)

[–]

 No.995954[Watch Thread][Show All Posts]

An anon converted some videos and posted them:

>>/rwby/36811

The videos report as corrupt. I opened them up in a hex editor and saw pic related. The first 1452 bytes of the file are the first 1452 bytes of the file with an HTTP header at the end. The value 1452 is important because it is a common MTU for a TCP payload.

Is what I am looking at a proxy server leaking information about itself? I think that what I am looking at is a buffer underrun (the server lost the last packet, and filled it in with garbage before the buffer).

Does anyone have any bright ideas as to what this is?

 No.995957

>>>/rwby/36811

Sorry, it's been a while since I did a cross-board post.


 No.995991>>996309

File (hide): d0ba43dfd48d152⋯.mp4 (8.89 MB, 640x360, 16:9, you're_welcome.mp4) (h) (u) [play once] [loop]

Well first of all it's a HTTP response. I can see it in the file you linked too. It's also probably not from 8ch itself, considering the completely different headers it gives.

It's not aligned with any byte boundary in the file (starting at 0x37F), supporting your argument for a buffer overrun. However I'm not sure what you mean by 1452 bytes. The file is made up of 895 bytes before the HTTP header, and then that exact same 895 bytes after it.

In my opinion, you're not going to find out how this happened unless you figure out where the HTTP response came from.

On the bright side, it actually plays fine once you remove the HTTP header and all the bytes before it, file related.


 No.996309

>>995991

> However I'm not sure what you mean by 1452 bytes.

There are five corrupted videos that were posted. All five have different length response headers, the only constant among them was that the file began again after byte position 1452.

> In my opinion, you're not going to find out how this happened unless you figure out where the HTTP response came from.

According to the poster, it was downloaded directly from Youtube. So, it's probably a bug in the downloader he is using. And, here I was getting my hopes up that random anon found an information-leaking bug in a server stack.


 No.997171

bump for general curiosity/interest




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
4 replies | 1 images | Page ?
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / 1st / acme / lit / mde / pinoy / s8s / vichan / zoo ][ watchlist ]