Yet, concatenating any other kind of data to the end of an image (such as a repeated string like "NYO~NYO~NYO~NYO~") is allowed.
I'm guessing it will take about 15 seconds until someone slightly modifies the script and sound image creation process to XOR the oggs with a simple bit pattern.
>>13
An Internet friend of mine who frequents Reddit shared me that link. I wonder if they posted it on Reddit too. Wouldn't be weird, since both ``les'' are pretty much two sites full of retards posting the same stuff every day.
Name:
Anonymous2012-11-28 22:10
>>14
almost all hacker jews articles are reposted on /r/programming
>>15
How do you know it's not the other way around? Wait, do you go there? Terrible!
Name:
Anonymous2012-11-28 22:22
17 GET
Name:
Anonymous2012-11-29 6:01
rarjpegs were forbidden on 4chan for years..
Name:
Anonymous2012-11-29 15:21
The discussion on /a/ started getting technical, so I'll defer to /prog/ in hopes that someone already knows the answer to this:
Is it possible to detect when a JPG is done decoding before EOF is reached? Whether or not it is possible to permanently block soundimages is dependent on whether or not this is true.
If it is so, the feasibility of blocking soundimages would also depend on whether a "million lels" attack is possible with a JPG.
By comparison, it should be easy to determine the end of a valid PNG, as there is a special IMAGE END chunk.
Write a small encoder/decoder to encode your file using all but the MSB of each pixel, and use the high bit to display a 1bpp picture of an animé face or instructions to decode it or whatever.
Of course moot could then decode the image and check whether specific pixels match an MP3 header, but he can't block the general method -- you can just change the details of it every couple of days with no problems.
This is basically a more complex version of ``save this file; convert to BMP; rename it to shit.exe'' but yeah.
Name:
Anonymous2012-11-29 15:44
>>19
In the bathroom, I realized I am an idiot, along with a few naysayers on /a/.
The imageboard script already has to decode JPGs and other images to generate thumbnails, so that pretty much rules out the question of whether it's practical to decode all images to detect embedded sounds. If it were possible to stall the servers with a "million lels" attack in an image, someone would already be doing it.
Now I just need to know if JPGs don't finish decoding until EOF.
Name:
Anonymous2012-11-29 15:46
>>20
Don't get me wrong, I'm well aware that it will always be possible to encode arbitrary data in images.
The novelty of soundimages depends on there being both a valid, user-selectable image (ie not "noise") and a valid audio file, however, so for the purposes of this discussion, I'm only considering methods of tacking data onto the end of a valid image.
Name:
Anonymous2012-11-29 15:50
>>20
Also, you can't upload uncompressed images to the imageboards (unless there is a way to do that in GIF or PNG), and I don't think that Javascript in the browser has access to the decoded binary representation of a compressed image, so your suggestion would basically require bundling a GIF, JPG, or PNG decoder written in Javascript with the userscript.
I don't know if you can make uncompressed PNGs (I thought you could, but from Wikipedia it doesn't look like it) but can't you manipulate individual pixels if you display the image in an HTML5 <canvas>?
I was thinking that users would just run a convertor after downloading the file.
It's not like these specs are closed. JPEG has chunk encoding. It is possible to know whether there is data beyond the last END chunk, it's just that most encoders/decoders don't check for it (by default?).
Tacking data at the end of an image is idiotic. You can encode data into an imagine while keeping most of the image intact in many ways.
Name:
Anonymous2012-11-29 17:28
>>26
I looked further at the Wiki page, and it seems fairly easy to "walk" over the chunks without calculating anything to get to the End of Image chunk. A "partial jpeg decoder" that calculates the end of the image data as quickly as possible should be pretty simple to implement.
How is tacking data at the end of an image idiotic? Our goal is not to perfect steganography, but to provide a simple way to include audio data in images that can be posted on an imageboard and extracted with a simple program. This method has the advantage that "encoding" is as simple as ``echo [1] >> image.jpg && cat sound.ogg >> image.jpg'', and "decoding" is almost as simple.