Live data from Hacker News

Xbox360 –> Windows Executable Converter (2017)

github.com

21–30 of 57 posts

Re: Xbox360 –> Windows Executable Converter (2017)

#21

Something like this was even easier for XNA games, since you could download a bundle of C# dlls and exes from your console and then after a quick decryption process, patch them to swap the dependencies. I reverse engineered a couple games this way and was able to boot them part-way within a couple hours (of course, endianness and console-only shader instructions were a problem.)

I vaguely remember this being done for FEZ back in the day. Funnily enough, the same is true for a number of cross-platform frameworks. One that sticks out was a port of David Cage game (which was largely written in lua) and making huge progress on porting the runtime from PS3 to PC.

Re: Xbox360 –> Windows Executable Converter (2017)

#22

Earlier quoted context omitted.

This emulator isn't taking the 'CXBX approach'. CXBX does not recompile the binary and relies on common system/graphics api calls not being inlined and easily replaceable with windows equivalents, which absolutely doesn't exist in any 360 game binary for all the important things.

The point is that it's still HLEing all of the imports (like CXBX). Just going the extra mile and full system emulating pays massive dividends. No, it's not close enough to Windows in super subtle ways, so don't take the bait of the import names being the same.

> The point is that it's still HLEing all of the imports (like CXBX).

You have a fundamental misunderstanding here. HLE in the style that CXBX does it is not possible for 360 games as every userland library is static linked and LTCG is enabled by default (maybe required for MS cert?) for release builds. Nearly everything is inlined and impossible to replace with calls to matching windows APIs as a result. Xenia and rexdex both emulate the kernel at the syscall level and don't touch userland at all.

> Just going the extra mile and full system emulating pays massive dividends.

Maybe for security research and correctness purposes, it has little practical value for ps3/360 gen emulation and beyond.

Re: Xbox360 –> Windows Executable Converter (2017)

#25
post #23

Earlier quoted context omitted.

The main README explains their approach. It disassembles PPC, generates equivalent C++ and compiles that into the target ISA (amd64).

What is PPC please ? Can't find anything

PowerPC

Re: Xbox360 –> Windows Executable Converter (2017)

#26
post #18

Earlier quoted context omitted.

The main README explains their approach. It disassembles PPC, generates equivalent C++ and compiles that into the target ISA (amd64).

Is it not completely crazy that this is even possible? This sounds like wizardry to me.

Qemu does something similar. And Box86 does that while keeping 3D acceleration on converting X86->ARM linux binaries.

https://github.com/ptitSeb/box86

Re: Xbox360 –> Windows Executable Converter (2017)

#27

Something like this was even easier for XNA games, since you could download a bundle of C# dlls and exes from your console and then after a quick decryption process, patch them to swap the dependencies. I reverse engineered a couple games this way and was able to boot them part-way within a couple hours (of course, endianness and console-only shader instructions were a problem.)

Under OpenBSD you still have xnaify to wrap and run C# games with MonoGame or whatever was called.

Re: Xbox360 –> Windows Executable Converter (2017)

#28
post #23

Earlier quoted context omitted.

The main README explains their approach. It disassembles PPC, generates equivalent C++ and compiles that into the target ISA (amd64).

What is PPC please ? Can't find anything

Add "computing" to your query to disambiguate.

Re: Xbox360 –> Windows Executable Converter (2017)

#29
post #18

Earlier quoted context omitted.

The main README explains their approach. It disassembles PPC, generates equivalent C++ and compiles that into the target ISA (amd64).

Is it not completely crazy that this is even possible? This sounds like wizardry to me.

It's quite common way to get good performance out of emulated code, althought usually it's JIT.

But yeah, it is crazy complex

Post reply on HN