May 22nd, 2007 by Multimedia Mike
Vacation approaches. I’m heading out to Berlin.de soon for LinuxTag 2007. If you happen to be at the conference, do stop by the free multimedia booth to meet the crew. Oh, and be sure to attend my presentation, “FFmpeg: Past, Present, and Future”, which will be a fairly high-level overview of FFmpeg, its surrounding culture, the challenges it has overcome, and the challenges it still faces.
Answer to FAQ: Maybe the presentation will be recorded and placed online; that’s really not my department. Enough people seem to be interested that this will probably happen one way or another.
Posted in Open Source Multimedia | Comments Off on Gone Fishin’
May 18th, 2007 by Multimedia Mike
One of FFmpeg’s Summer of Code projects is a decoder implementation for E-AC3. Thus far, the only samples available are rips from HD-DVDs. However, according to the E-AC3 mentor/student pair, these streams are not especially interesting for building a full-featured decoder; they don’t really flex the new features presented in the E-AC3 (a.k.a. a/52b) coding standard.
Thus, I’m wondering if anyone out there has the capability to encode new samples, preferably ones that make sure of the new bells and whistles? Or if anyone even knows what software can do this, that would be useful knowledge as well.
It would be particularly arduous to have to first write our own encoder so that we could also write the decoder.
Posted in Open Source Multimedia | 3 Comments »
May 16th, 2007 by Multimedia Mike
A correspondent who understandably wishes to remain anonymous is perhaps the first to come forth and point out what others have undoubtedly noticed:
Those naughty websites have a knack for posting samples with lots of errors … Maybe it would be easier to have a “clip bin” that’s anonymous, where you can submit clips ..that break the library.
We already do have the anonymous FTP at mplayerhq.hu for uploading samples. IP addresses are logged somewhere, but big deal. The bigger issue is that you sort of need to ping a development list somewhere in order to make them aware of the problem.
If you are determined enough, you can always go through anonymous proxy services to upload the sample and then use anonymous remailers or email services to alert the list or someone associated with the list.
Just part of our… umm… commitment to quality.
Mr. Anonymous mentions that the second part could be avoided by having an automated script that checks for new material in the upload directory and logs the information somewhere. I’ll file that away for when I finally get the autobuild/test system operational.
Posted in General | 2 Comments »
May 2nd, 2007 by Multimedia Mike
I resurrected my old call/ret experiments recently. I wish I had published more about how I did what I did 2 years ago — that’s why I started this blog, as a research journal, for my own benefit, for when I eventually return to a project after a lengthy hiatus. Fortunately, I emailed pretty thorough details to a fellow reverse engineer during the original project and still have the old email in the archives.
To refresh, the call/ret monitor watches a piece of code run and logs when function call or return instructions are executed, and where. After the fact, and combined with executable code that comes with meaningful symbol names, it generates a call graph to demonstrate where code really flows and gets around the problem of resolving indirect jumps in static disassembly listings. The original experiment assumes that for every call, there is an equal and opposite return (formally stated: num_calls == num_rets). The target I’m after right now behaves… differently. I am seeing way more calls than returns.
Obviously, there is a lot about compilers that I don’t understand. I think what I’m looking at in this situation is an artifact of C++ or perhaps its linkage from C. When I examine functions in static disassembly, there will be 7 NOP instructions after the stack frame initialization. Seems pretty innocuous. However, when I analyze the code more carefully while it’s running, I see that something — I suspect the dynamic loader — is using those 7 NOP bytes for something else. I imagine this is some common convention, and I would love to know more about it someday. But for the time being, I just want to get past this problem. In this particular situation, all that the patched code does is perform a call 5 bytes farther in the address space where a pop instruction is waiting to clear the return address that just got pushed on the stack by the call. So that’s where the massive call surplus comes from. Why the unknown entity couldn’t patch in an absolute jump is unclear.
Eventually, it dawned on me that the /ret half of the call/ret experiment was entirely unnecessary given the other data I already have. I have retooled the experiment with that in mind. It’s annoying to try to remember enough Perl to make this fly but it’s worth it for the resulting data visualization.
Posted in call/ret Monitor, Reverse Engineering | 5 Comments »