PhotoMagnetic

This is a project I've been wanting to do for a while, and I finally got around to putting the code together yesterday.

It's based on a project called JSteg, the idea of which is to simply alter JPEG data after the lossy compression phase has been completed.

Microsoft has a fairly good explanation of how JPEG works and this can be simplified into three main phases:

1. Downsampling
2. Transforming and quantising
3. Lossless compression

Downsampling
The first phase represents the image in terms of brightness and chrominance, brightness being measured on a one dimensional scale, and chrominance on a two dimensional scale with one axis being red-green, and the other being blue-yellow. Experiments have shown that the brightness channel is what effects our perception of images the most - the JSteg page has an example of how far the chrominance channels can be downsampled  before noticable changes start to appear.

Transforming and quantising
The data is then subjected to a discrete cosine transform which effectively replaces the pixel values with frequency values. These are then quantised (smoothing off the rough edges if you like) and then rearranged in order to place all the resultant 0 values next to each other. You can imagine what the next step is now.

Lossless encoding
The adjacent zeroes are perfect fodder for run length encoding, followed by huffman coding. The resultant space savings come not only from direct reductions in the space used by chrominance values, but also a simplification of the data such that traditional compression can be used.

Hiding a 160 bit hash
This is actually the easiest part. All the complicated work is done in the lossy stage, so all that needs to be done to hide our hash is to alter the file before it is losslessly compressed. The basic operation is as follows:

• Decompression
• Altering the coefficients
• Compression

The way we hide the data is overwriting the LSB of the coefficients, which results in a minor change spread across that part of the image. The advantage of saving a fixed length of data is that no extra metadata needs to be stored, so that any file that hasn't had anything encoded will still produce a hash, it just won't have any meaning, so it gives the encoding some amount of deniability.

You can download the project from here if you'd like to try it out for yourself.

Ściągnij z iply

Kolega mi polecił programa "IPLA" abym obejrzeć seriałów polskich. Oczywiście, to mi się spodobało, ale nie lubię objerzeć online - wolę ściągnąć a potem obejrzeć, abym nie wyczerpać internet.

Więc, uradziłem napisać swojego program, przez co mogłbym tak zrobić. Na szczęście było prosto, bo IPLA używa XML, a mogłem tworzeć jakiegoś XSLT który mi pomógł. Wreszice mi się udało, ale trudno użyć UTF-8 z stdin'a z windowsem - nie mogłem po prostu użyć fgets() lub scanf() a raczej potrezebowałem ReadConsoleW(), SetConsoleCP() i SetConsoleOutputCP().

Program ściągnij z iply można pobrać, więc spróbuj, i mów mi co masz na myśli!

ASFDump: I'm sick of it

The plugin is dead in the water. XPCOM and NSPR lack documentation and working samples, and I've already spent enough time getting this project up and running. The command line app works, but as for the plugin, somebody else will have to make that.

The project can be found here, feel free to let me know what you think of it

ASFRecorder part 3: Making the plugin

This, I told myself, is the easy part - it's all smooth sailing from here!

No such luck unfortunately, although I found comfort in the knowledge that making a plugin for firefox meant I could actually believe that the specification was being somewhat followed. This part was much easier in comparison to the ASF parsing, so I can't really complain too much.

The way binaries are included in addons in firefox is fairly straightforward, and there are good tutorials (my plugin was based more or less on this one with a few adjustments to the makefile) so after the issues were sorted out I had my test plugin ready to go.

With the test plugin sorted, the next step was to add functionality to detect the loading of .asf files. There are a number of different plugins that download .flv files, and a quick look through the (copyrighted) source of these turned up extensive use of observer notifications, and a check against the (GPL licensed and therefore stealable) Tamper Data source confirmed this for me. A look over some of the firefox articles showed me how to extract the URLs, which leaves me set for the next steps:

• Add observers to the test plugin
• Cache .asf (and .wmv) file requests
• Maaaaaaaaaaybe look at response headers to check for MIME types I like
• Load the ASFRecorder and post processing code into the binary part of the module
• Maybe add some callback options to give an idea of progress
• Package up and start distributing

It looks fairly easy from here, maybe the callback stuff will be a pain, but I'm hoping I can get it all sorted by the weekend

ASFRecorder part 2: fixing up streaming output

The project is coming along quite well, and I mean quite well, and I'm at a stage where I'm almost ready to build a plugin framework to host a beta. Here's a quick run through what I've had to do so far to get the output to a point where more than just VLC will play

• Remove all references to the extra streams that are filtered out, including removing a few headers, rebuilding the header section in the process
• Add padding lengths  to each data packet (because packet sizes are fixed, the server actually breaks its own standard by not setting the padding lengths, so although this is a trivial exercise, it was more work than I wanted to do)
• Add packet length values to a sparse minority of data packets (something like one in 100,000, but it breaks avidemux) by manually summing the payload lengths, and then setting the padding lengths accordingly
• Remove the null data packets (once again, these are fixed length, so easy to detect and skip, but this not only breaks the standard, I strip about 10% off the size of the file once these are removed)

Was it worth it? Turns out trying to appease avidemux wasn't the best goal, as its wmv reader module looks quite seriously broken (maybe it doesn't read the keyframes but the output has tons of artifacts), but now the output works on that, vlc, windows media player, and totem movie player.

It should all be smooth sailing from here though - just putting the post processing routines into a single module, getting ASFRecorder up to scratch, possibly tying the two modules together (or maybe that can be the second release), then doing all the GPL documentation and putting the demo plugin together.

I just hope I've gotten the hard part out of the way now ;)

ASFRecorder

As fantastic as streaming audio and video are, sometimes it's nice to reply things later. As far as websites which host .flv go, the act of saving the media file is fairly trivial, and is done by a wide range of browser plugins. Websites which actually rely on a client-side stream player are a different story though...

I was after a simple option, and ideally something single-purpose. Apps like VLC are up to the task, but a bit too big to bundle in a plugin, and lack some desired features (like resuming, in the case of VLC). There is a Japanese app called GetASFStream which appears to do a good job, and even rebuilds the header based on the streams chosen (which as far as I can tell simply chooses the first audio and video streams). There's a couple of problems though - it's in japanese, doesn't appear to be open source, and doesn't appear to have commandline support. So the search continues...

I then stumbled across the code for an application called ASFRecorder. It appears to be unchanged since 2001, and as a result, lacks a few features.

For starters, it doesn't recognise the content type "application/vnd.ms.wms-hdr.asfv1", which Microsoft gives little data on, but it appears I'm not the only one to come across this problem.

Once I'd patched the code to take newer ContentType values, I came to another problem - it doesn't parse the payload parsing information section properly - instead of actually interpreting it as per the spec (which is freely downloadable), it appears as if the original author picked a few common values, or found them from trial and error, instead of calculating the length as a general case function. Once this is fixed, ASFRecorder happily dumps the stream to a file, but we're not done yet!

As described here, ASFRecorder only downloads the first stream, and dumps the header has it. This is quite messy, but the attempt is quite a valid one - if the stream is dumped directly to a file, then in theory it can be played straight back. However, it appears the code was only ever written for single stream broadcasts, which means the user is limited to either audio streams, or soundless video streams (ie. radio or porn), and so despite the file being written with a multi-stream header, only the first stream is saved.

I decided to undertake the rewarding task of building my own header parser app (which I might post if anybody cares enough to look at the code) so I could compare the (incorrect) output of ASFRecorder with the (correct) output of GetASFStream. After comparing the two headers, and trying (unsuccessfully) to simply paste the header from the correct dump onto the incorrect one (which stopped it from playing completely), I discovered that the reason ASFRecorder was only dumping a single stream was because that's all it was asking for.

By changing the hardcoded reply message so that it asks for two streams instead of one, my dump is suddenly working correctly! However, there is a bit more tidying that needs to be done, and some of it is necessary before release, but there is also some I can save until later

• Actually coding a general parser for the payload parsing information
• Changing the handler to take all MIME types for ASF files
• Parsing the return value from the server to give a proper selection of streams
• Processing the whole header, writing a new one, and arranging the streams accordingly
• Building a proper resume function to compensate for the new header
• Somewhere along the line incorporating this into a browser plugin

And that's all.... looks fairly straightforward.

One final comment to make about the ASF file format - it's actually logical. The last time I messed with m$ file formats was DIB and WAV files, each with their own quirks and rude deviations from the standard. It seems when m$ does their writing from scratch, they do a proper job of it.

Update

Apologies to anyone who thought this might be updated on a regular basis (including myself).

Things wound down quite seriously in November, and I returned from Poland last week (where there were many piękni widoki) to find I had a lot of catching up to do.

Here's a quick list of the projects I have at the moment. Hopefully one of these will grab me so I can make a few more posts about it.

• Extending the IPv6 version of the ARP replay attack for WEP into a usable utility, and performing some better tests with it (doable, since I acquired another wireless AP)
• Phase two of the drive by download project (as per the last update)
• Further exploration into VOIP (the asterisk server is working fine as it is though...)
• Configuring reverse DNS entries for my IPv6 subnet
• Honing my reversing skills further with more crackmes and wargames

There is also the need for a job somewhere in there... but that'll hopefully sort itself out while I play around... right?