This has got to be the coolest use of an animated GIF ever:
Even crazier, in Firefox, if you right-click to “View Image”, the favicon shown in the tab is animated too! I smell code re-use! That kicks ass. I wonder what level of hell I’d burn in if I made the favicon for my site animated.
© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Today I was reminded of the NGsec security games site from a DefCon CTF team-mate. (This game was actually used as a prequal for DefCon 10, which I didn’t go to. Ken told me stories about it, though.) I burned through stages 1-9 in about 45 minutes, and then hit stage 10 and was side-tracked learning about encrypted ELF binaries.
There continues to be no useful FOSS binary analyzers for this kind of reverse engineering. gdb just doesn’t even begin to cut it: it was made for (surprise!) debugging programs built by friendly compilers, not doing forensics on decidedly unfriendly, hand-crafted binaries . If Paul Graham and Richard Hamming are to be believed:
I should be writing a static binary analyzer. And a dynamic one too. GPL IDApro replacement. Yeow.
© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
The “sendfile” system call is a way to send file contents directly out to a network socket. This saves time in userspace (so it doesn’t have to copy buffer contents around), and was one of the reasons I upgraded kernel.org‘s Apache to version 2.x at the end of 2003 (because version 1.x doesn’t have sendfile support). A few weeks ago, one of the other kernel.org admins discovered that files greater than 2G were not being delivered by Apache.
I had a lot of fun tracking down the issue. The “amount to send” argument in the sendfile call is a “size_t”, which is basically an “unsigned long”. Having a 2G limit didn’t make sense, since even with 32 bits, that should be a 4G limit. However, the kernel.org servers are both 64bit, so as it turns out, “size_t” is a full 64 bits. After writing a quick test, I was able to verify that it was, indeed, a 31 bit limit on both 64 bit and 32 bit kernels. Peter Anvin took it from here, and tracked down the origin of the problem: filesystem operations greater than 31 bits in offset were being rejected deep in the kernel. He suggested truncating the request instead of returning a failure.
Seems as though Linus decided to limit the size of filesystem calls to make sure there aren’t security problems (signed vs unsigned overflows) in the various filesystem drivers, while people using the Linux kernel migrate more from 32bit to 64bit systems. Personally, I don’t agree with this, but from a practical stand-point, it hardly makes a difference. Instead of sending all 4G out the pipe and returning to user space, it just returns twice, sending 2G per call.
This should be fixed in 2.6.16. Until then, we could patch Apache to keep it’s offset request under 31 bits, but we’ll probably just tell people to use FTP, since vsftpd doesn’t use sendfile yet.
© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
I’m involved in the Open Source as Prior Art initiative. The goal being to more readily make FOSS available as prior art for the US Patent and Trade Office to use while examining software patent applications, reducing the number of poorly issued software patents.
This is a rather touchy area given the fact that most FOSS proponents (myself included) would rather see software patents go away completely. However, in the US, this is not likely to happen any time soon, since it’s not up to the USPTO, it’s up to the US Legislature; the USPTO has to implement the law, which puts them in a bind since they’re not very successful right now at finding prior art (and the laws surrounding prior art discovery aren’t that helpful either). In my opinion, if the USPTO could reliably find prior art, they would start rejecting almost all software patent applications, and the futility of software patenting would become clear to those that didn’t already recognize it. If I’m wrong, then I’d hope that with the very few patents issued, innovation really would return to the system.
Groklaw has already discussed the OSaPA project and the overall “Patent Quality Improvement” initiatives announced by the USPTO. I’ve read these and several other articles, each ranging from praise to scepticism, looking for more thoughts on subject, trying to help me shape my opinions.
One of the most sceptical was written by Greg Aharonian from the Internet Patent News Service (which ironically has no online archives for me to link to). His scepticism is mostly aimed at the USPTO and IBM, and not directly at the various initiatives, past or present. His fundamental point is that the USPTO doesn’t appear to have manged to use the (voluminous) resources it already has at its fingertips, so why would adding more help the situation? This approach didn’t work in the past, and there’s no indication that anything has changed in the USPTO to make it a success this time around.
I don’t have the historical background to know if it’s a fair assessment, but I enjoyed his analogy:
“[…] IBM is Lucy, PTO management is Charley [sic] Brown, and these fake initiatives to improve patent quality are the football that the PTO keeps on trying to kick, only to be fooled again and again.”
One thing I think he may have missed, though, was that the OSaPA initiative contains another player. The initiative itself may again be the football, and the USPTO and IBM may again be playing, just as with prior (seemingly failed) initiatives. However, this time, the FOSS community is involved. I like to think that in Greg’s analogy, the FOSS community is Charles Schultz. We can draw any damn comic we want, and we’ll still be around after the initiatives, IBM, and the USPTO are long forgotten. The FOSS community is on the multi-hundred year plan, the same as any other sustainable cultural plan. If Greg’s predictions come to pass, and it really does turn out to be a waste of time, I still have faith that it’ll only be the USPTO (and, unfortunately, the US) getting hurt. To borrow from John Gilmore, FOSS will treat this as a defect, and route around it.
Regardless of history, I sincerely hope the USPTO takes this novel chance to harness the power of the FOSS community. We’re interested in helping them solve their problems, and if the USPTO drops the ball, it’s unlikely the FOSS community will ever look back.
© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
In the back of my head, I’ve been wondering about various ways I could use my $20 camcorder. Making cheap movie shorts, like SNL’s “Lazy Sunday” come to mind. There are no fancy zooms or special effects. It’s all editing and audio. Bryce kicked some ideas my way, most of which include using the dogs and/or cats as the primary actors (I can pay them in kibble). He also suggested renewing my father’s Rottweiler Camcorder with a much smaller device. I think the images would be mostly obscured by my dog’s chin. We’ll see. I also worry it may suffer from being summarily ingested.
While playing Name that Tune 80s DVD Edition, the a-ha video for “Take On Me” came on. The rotoscoping used to create the animated parts made me think of Inkscape‘s autotracing function, and I lept up to go investigate the possibilities.
So far, I’ve played with two styles. One leaves the autotraced fill areas (which makes a video look like a really freaky cartoon), and one that reduces the fill opacity, and adds line density so it looks more like a regular outlined cartoon. That one tends to be distracting, though, since the edges keep jumping all over the place.
The autorotoscope script requires mplayer, ImageMagick, autotrace, and ffmpeg.
Here are the results:
These AVIs use xvid for their video codec. If you don’t already have it, you can get them from here.
© 2006 – 2015, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
I’ve gotten all my Firefox extensions straightened out again since the 1.5 shake-up. Now that it’s sane, I wanted to report what I’m using so I’ll remember for the future, and so I can go look somewhere if I’m on my laptop or some other machine and I can’t remember which extension I was looking for.
Also at least one other person has asked me what extensions I’m using, so maybe others would be interested. I used the following to get a human-readable list of my extensions:
egrep ':(version|name|description|type)' ~/.mozilla/firefox/*.default/extensions.rdf | \
perl -pe 'print "\n" if (/:version/); s/^[^=]+="//; s/"$//;' | \
(read EMPTY; while read VER; do \
read NAME; read DESC; read TYPE; read EMPTY; \
if echo "$TYPE" | grep \>2\<>/dev/null; then \
echo "$NAME $VER"; echo "$DESC"; echo ""; \
fi; \
done)
I bet there is an elegant XPath command to extract this directly with a single “perl” execution, but, uhm, I’m not an XML expert. :)
Almost all of these extensions were gotten from the Firefox extensions list:
In addition, it seems the option in TabBrowserPreferences for URL pasting into the display window to load was removed. After some Googling, I was directed to the about:config page, under “middlemouse.contentLoadURL”. Set it to true to restore the prior default behavior.
© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Powered by WordPress