Now that I'm not posting from my phone, I'd also like to address this as a tangent:
Darkstar wrote:Reversing a program that someone else wrote to reverse a file format? Yeah, because with every layer you put on top the reversing gets easier and easier, right?
I suspect you don't do much actual reverse engineering yourself, or if you do you live the sheltered life of one who only disassembles native code, or worse yet, strictly guesses based on nothing but binary observations.

When you're talking about shoveling together tools to reverse engineer something on a proprietary embedded system for a different CPU than your tool target, you probably aren't going to have debugging capabilities anywhere near as nice as the ones you have under a desktop OS. And even if you do have a very nice debugging and disassembling solution for the platform you're reversing from, you're still translating it to a different architecture. If you're just disassembling and targeting x86, you can tear the routines straight out of the app, plop them into your own, and you're tentatively done. From there you can step through them, take your time, easily put them through any kind of unit/sandbox test you want, and translate them way more easily with the aid of experimentation and observation in your own isolated framework. That's a far cry from translating blindly from raw disassembly because you can't debug on the platform, and even from translating to a different architecture using a likely limited (in comparison to the x86 debugging tools available) debugging environment.
So, yeah, unless the reverse engineer made a complete mess of things, it is a hell of a lot easier to reverse their work instead of the original in pretty much every case when we're talking about things like gaming console platforms. I can't name a single instance where I've chosen non-x86 over x86 for ease of reversing.