Sometimes, multimedia programs are modular which facilitates reverse engineering. But what if they are not modular or are just standalone programs that do one thing well?<\/p>\n
<\/p>\n
Many multimedia program architectures are highly modular in order to allow easy expandability for new codecs and container formats. Since the modules conform to well-defined interfaces, usually exporting one or more functions from a standard API, such modular platforms provide an excellent jumping-off point for reverse engineering. But what happens when you encounter a standalone player where all of the decoding code is hidden in there somewhere amidst megabytes of unrelated code? Or, in the case of Apple’s QuickTime Player, many of the core codecs are rolled up into one mega-DLL?<\/p>\n
In situations like this, I like to use a chase-the-data-through-the-buffers strategy. I will need to come up with a better name for that. It operates on the following simple logical premise:<\/p>\n
I once had access to a debugger that could be made to stop when a particular area of memory was read from. I would put a breakpoint on the standard Windows ReadFile() function. I would wait until I recognized the buffer of data being read from the file (since I had the sample file open in a hex editor in a different window). Then I would put a read breakpoint over the entire data buffer which would lead me straight to the core decoding function.<\/p>\n
I do not have access to that debugger anymore and it seems to be a fairly rare feature in modern debuggers. Besides, using debuggers just encourages one to step through the code. I want cool software tools that do tedious work for me.<\/p>\n
So, let’s brainstorm a new program. Operating on a similar logical premise as above, feed it a buffer pattern you wish to match. The pattern would be, for example, the first 16 bytes of the first keyframe of a file that contains data in a format that is still only decodable by a binary codec. The program would then set the x86 CPU trap flag, so that every instruction causes a breakpoint handler to be invoked, and the custom breakpoint handler would search memory for that pattern.<\/p>\n
Seems like a big task. I think I would break it down like this:<\/p>\n
Nutty, and not something I am likely to get started on soon.<\/p>\n","protected":false},"excerpt":{"rendered":"
How about a tool that searches for a pattern through memory as a program is running?<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-45","post","type-post","status-publish","format-standard","hentry","category-reverse-engineering"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t