Hacking Can we port Nintendo Switch OS on Nvidia Shield TV?

[smf]

Not true. You cannot port something you do not have the source code for.

It is true, you can port software without source code. I've done it.

You can disassemble binaries via assembly (processor) code to resemble behavior similar to original source code and the behavior is "emulated" on separate hardware.

That doesn't make sense. Disassembly and emulation are two completely different things.

I can open up a debugger, disassemble some code running on my pc and change it. I don't have the source code, it doesn't turn it into an emulator.

When Windows 7 was hacked to run on older hardware than Microsoft supported, they didn't have the source code. It wasn't an emulator. They disassembled and patched it.

This is what the definition of HLE and LLE are, keyword being emulation:

HLE refers to an emulation technique where programmable logic is used, which you ignore and instead rewrite your own implementation. I'm suggesting SwitchOS running natively on Shield, rather than using any form of emulation. Emulation techniques are irrelevant.

Also, emulation causes "overhead" in the I/O processing steam, meaning: in most cases the processor or hardware has to be more advanced, even if slightly, to run the instructions at full speed.

Correct, which is why you would port switchos to shield rather than emulating it.

What you are mistaking is baremetal performance as opposed to emulation running on top of an existing OS / kernel.

What you are mistaking is that the architecture of the two is pretty much identical, so you don't need an emulator.

Now before you say it doesn't need to be emulated, and I'm fairly sure that is what is coming next, I'm just going to stop you right there. You are then insinuating, by proxy of that notion, that you either have existing source code, or you can somehow reverse engineer the code, write your own switch OS and bootloader from the ground up, target compilation to the Nvidia Shield hardware specifications, and get it to run full speed BAREMETAL on hardware. To which I say, you would have just accomplished what has seemingly never have been done for a modern console and built your own game system.

WOW, you're going to run with this crap? Yes of course it doesn't need to be emulated. I'd love to find out what behaviour you think is different between the Tegra X1 in the Shield and the identical Tegra X1 in the Switch?

I am not going to rewrite the switch os, because the switch os will happily run on a shield. Because it uses the same chip. If I had the source code and compiled it for the Shield, it would be the same.

And yes, similar things have been done before. The gamecube OS has been run on the Wii (in Wii mode), it's called nintendont. The source code wasn't available for the gamecube OS. The games run full speed, with none of the overhead that you seem to think would be required in doing so. If anything the switch & shield are MORE similar, than the gamecube and Wii (in Wii Mode).

You are claiming that something has seemingly never been done, when that is provably false.

In short, "It wouldn't take much to get it running" is not an accurate statement.

In short, nothing in your post is accurate.

Your obsession with the requirement for source code is bizarre, it's just a representation of software to make it useful for humans. The computer itself runs a binary, if you're clever enough then you can just change that instead.

Dump all the code from the switch, patch it for minor memory and storage differences, run it, profit.

 

[playinthedruid]

Ooof, gonna need the burn unit up in this bitch

 

[Shadow LAG]

It is true, you can port software without source code. I've done it.

You need source code to port anything. Even if you have to re-write source code from reverse engineering, but making of series of patches around a binary is not "porting".

That doesn't make sense. Disassembly and emulation are two completely different things.
It is true, you can port software without source code. I've done it.
I can open up a debugger, disassemble some code running on my PC and change it. I don't have the source code, it doesn't turn it into an emulator.

Correct, Disassembly (Reverse Engineering) implies you are completely working a binary backwards and re-writing source code; however, as you've just stated, you don't have source code, so you are implying you are just "patching" binaries.

The Nivida shield is similar to the switch in that the processor is the same, but the hardware is fairly different. For instance, the Nvidia shield does not burn fuses, and the open source Kernel / Drivers do not work natively for the switch.

Also how are you debugging? Do you have a Nintendo Switch Development Kit with symbols? Doubtful. You would need to change a great deal of behavior in the Horizon kernel with hundreds of patches, which could only be done in memory at run time, and you would at least have to get Horizon booted, or create a custom bootloader first to do so.

There is no way you are expanding Binaries and blindly analyzing, changing, and adding Assembly instructions line by line. I have IDA which is one of the most powerful disassembly tools and without debugging hooks or symbols, you are basically shooting in the dark, which could take years, and that is not even tackling the re-write of source.

So if you aren't disassembling multiple binaries to re-write source code, or creating an emulation environment, then please elaborate and present your roadmap on how you plan to "port" the whole software environment to the Shield.

you can port software by loading a binary into a hex editor if you're good enough.
Then you could mostly port software between them by searching for hex sequences in the binary and replacing them.

I know this one was not a response intended for me, but I would like to bring this into the conversation here. No you can't. You need a disassembler and/or a debugger to even find what certain addresses even execute. You are not adding code to a binary using hex editor, especially for a whole OS.

When Windows 7 was hacked to run on older hardware than Microsoft supported, they didn't have the source code. It wasn't an emulator. They disassembled and patched it.

Patching is not porting. Windows 7 was designed to support third party hardware. There were specific hardware drivers ported not the OS, and the image was cut down using WinPE to target the hardware. Let me make this very clear, Windows is an open development platform that was created to accept third party software and provides public SDKs, Horizon is NOT. That's like comparing apples to oranges.

HLE refers to an emulation technique where programmable logic is used, which you ignore and instead rewrite your own implementation. I'm suggesting SwitchOS running natively on Shield, rather than using any form of emulation. Emulation techniques are irrelevant... Which is why you would port switchos to shield rather than emulating it. What you are mistaking is that the architecture of the two is pretty much identical, so you don't need an emulator.

Again, the hardware is different between an Nvidia shield and a Nintendo Switch, just because the chipset is the same doesn't automatically make software compatible. For instance, the Nvidia shield has 3GB of Sys RAM and 1GB dedicate for Vram stream. So you are going to "search for hex sequences in the binary and replacing them" and get horizon and games to run the Shield with less hardware resources than it's intended target? No.

WOW, you're going to run with this crap? Yes of course it doesn't need to be emulated. I'd love to find out what behaviour you think is different between the Tegra X1 in the Shield and the identical Tegra X1 in the Switch?...

I am not going to rewrite the switch os, because the switch os will happily run on a shield. Because it uses the same chip. If I had the source code and compiled it for the Shield, it would be the same.

Boot loader / fuses, Dedicated RAM capacity, Turbo Clock, WLAN/BT, baseboard layout, drivers to support the aforementioned... ect.

If you had the source code? Yeah that's called porting, but if you are insinuating you could just target the compiler for the shield without making extensive changes to the source code, you are far from correct.

And yes, similar things have been done before. The gamecube OS has been run on the Wii (in Wii mode), it's called nintendont. The source code wasn't available for the gamecube OS. The games run full speed, with none of the overhead that you seem to think would be required in doing so. If anything the switch & shield are MORE similar, than the gamecube and Wii (in Wii Mode).
You are claiming that something has seemingly never been done, when that is provably false.

Oh you mean this?

Nintendont is more like a bridge between an emulator and a virtual machine which runs Gamecube games natively.

Certain parts such as SI for controls, EXI for memory card and DI for data reads are emulated. The rest is just patched to match the newer Wii syscalls.

Source: https://gbatemp.net/threads/nintendont.349258/

The original Wii could run gamecube games and the Wii U backwards (vwii) compatibility literally had Wii components on the other board layer. It is clearly stated Nintendont just functions as an interpreter layer. You can see this behavior for yourself in the source code. That is NOT a full port. It is just calling behavior that already previously existed and modifying that. This is not an OS replacement. Again, keyword being source code, meaning Nintendont is not a binary modification.

By your logic, we should already have the switch cold booting lower firmware with "fuse patches" baked into the flash storage binaries without need for RCM if it was as easy as "searching for hex sequences in the binary and replacing them."

Dump all the code from the switch, patch it for minor memory and storage differences, run it, profit.

Jesus Christ...

 

[smf]

You need source code to port anything. Even if you have to re-write source code from reverse engineering, but making of series of patches around a binary is not "porting".

It is porting. Source code is just another representation of a computer program. If this is the basis for your argument then you don't understand enough about computers to continue this discussion.
Some programs are written directly by the programmer as binaries.

Correct, Disassembly (Reverse Engineering) implies you are completely working a binary backwards and re-writing source code;

No, because you can make changes to it without requiring source code. You don't have to rewrite it all, you can just make a few changes. Which is exactly what porting is.

however, as you've just stated, you don't have source code, so you are implying you are just "patching" binaries.

Right and that patching of the binary would port the software from one platform to another. Get it yet? Or is it going to take much longer?

The Nivida shield is similar to the switch in that the processor is the same, but the hardware is fairly different. For instance, the Nvidia shield does not burn fuses, and the open source Kernel / Drivers do not work natively for the switch.

You can patch out the fuse burning easily. Next?

Also how are you debugging? Do you have a Nintendo Switch Development Kit with symbols?

I've never needed symbols before, lots of people do this kind of thing without symbols. If you're never done it then that shows the lack of your experience.
One of these would be pretty useful https://developer.nvidia.com/embedded/buy/jetson-tx1-devkit

You would need to change a great deal of behavior in the Horizon kernel with hundreds of patches, which could only be done in memory at run time, and you would at least have to get Horizon booted, or create a custom bootloader first to do so.

You might patch at run time, but you'd mostly build a binary. Maybe do it using a custom bootloader which patches the OS.

There is no way you are expanding Binaries and blindly analyzing, changing, and adding Assembly instructions line by line.

I do that for fun yeah. I know other people who do it for fun too.

I have IDA which is one of the most powerful disassembly tools and without debugging hooks or symbols, you are basically shooting in the dark, which could take years, and that is not even tackling the re-write of source.

A tool is only as good as it's user. Shooting in the dark comes with the territory. You don't need to rewrite the source, most of the binary will just run.

So if you aren't disassembling multiple binaries to re-write source code, or creating an emulation environment, then please elaborate and present your roadmap on how you plan to "port" the whole software environment to the Shield.

Patch the binary, like I've done many time to move software between slightly different architectures in the past. Like I keep saying.

I know this one was not a response intended for me, but I would like to bring this into the conversation here. No you can't. You need a disassembler and/or a debugger to even find what certain addresses even execute. You are not adding code to a binary using hex editor, especially for a whole OS.

Oh, I need a disassembler? I wouldn't have known.. A good job I have written a load of them. You don't need a debugger to know what addresses would execute, but I've built emulation environments in the past to help with reverse engineering. But yeah, you could get something running using a hex editor. I've been showing this to my friends who have 40 years of hacking knowledge doing this kind of thing and they find you hilarious.

Patching is not porting.

Patching is a way of changing software, changing source code and recompiling is another way to change software.
Porting is a type of change to software that means it will run on a different piece of hardware. The method you use to achieve that is irrelevant.

Horizon is NOT.

Horizon is designed to run on a Tegra X1 board.

Again, the hardware is different between an Nvidia shield and a Nintendo Switch, just because the chipset is the same doesn't automatically make software compatible. For instance, the Nvidia shield has 3GB of Sys RAM and 1GB dedicate for Vram stream. So you are going to "search for hex sequences in the binary and replacing them" and get horizon and games to run the Shield with less hardware resources than it's intended target? No.

We're only talking about porting the OS. If games run out of memory then that is a different issue. I have patched games to use less memory, I had to build a list of all the instructions that use memory and feed it into an algorithm that I wrote. It was fun.

Boot loader / fuses, Dedicated RAM capacity, Turbo Clock, WLAN/BT, baseboard layout, drivers to support the aforementioned... ect.

If it were me then I'd just NOP all that out to start with. Getting the OS running is the first priority.

If you had the source code? Yeah that's called porting,

No, having the source code is nothing to do with porting. It's how most people do it because it's easy, most people have IDA and think it's great but don't know what to do with it too.

Source: https://gbatemp.net/threads/nintendont.349258/
The original Wii could run gamecube games and the Wii U backwards (vwii) compatibility literally had Wii components on the other board layer.

Wrong. The WiiU doesn't support gamecube mode & the Wii/WiiU in Wii mode is slightly different to gamecube (like the switch and shield are slightly different). He added runtime drive, controller, graphics & audio patches to make the games run in the slightly different environment. They are essentially ports. In gamecube mode you can't access the usb ports etc, which is why the games were ported to Wii mode.

It is clearly stated Nintendont just functions as an interpreter layer. You can see this behavior for yourself in the source code. That is NOT a full port.

But you said without source code the alternative was emulation which had a high overhead, this doesn't have a high overhead. He doesn't have the source code.

Again, keyword being source code, meaning Nintendont is not a binary modification.

You're making a circular argument that contradicts you, a world first. Nintendont does run time patching of games to run on different hardware. It doesn't use original nintendo source code & it's not emulation & doesn't have the huge overhead that you said was necessary because of the lack of source code. The patched games are running natively.

Jesus christ...

Give me strength. One day you'll get it.

 

[Shadow LAG]

It is porting. Source code is just another interpretation of a computer program. If this is the basis for your argument then you don't understand enough about computers to continue this discussion.

Some programs are written directly by the programmer as binaries.

Computer engineering is what I do for a living. Source code is what you need to compile a binary. You mean some programs are written in Assembly processor code, yeah small programs if you are a masochist and feel like spending months writing samples or live in pre-1995 world where applications consisted of a few bytes. Nobody in the modern age is writing several GIGS of operating system binaries in assembly, and neither are you.

No, because you can make changes to it without requiring source code. You don't have to rewrite it all, you can just make a few changes. Which is exactly what porting is. Patching of the binary would port the software from one platform to another.

That is nonsense. Just because a processor is the same does not mean you make a few changes in a hex editor and boom loaded. You are severely oversimplifying what is involved here, and you and I both know it. You first need to write a bootloader to even execute the boot chain.

You can patch out the fuse burning easily. Next?

The Shield doesn't even deal in fuse burning and the primary bootloader (not blob / fastboot) on the chip is not writable. You can patch out fuse burning with memory patches, but you are not cold booting a patched fuseset on a Nintendo Switch, nor an Nvidia shield without a custom bootloader. Again, oversimplifying.

I've never needed symbols before, lots of people do this kind of thing without symbols. If you're never done it then that shows the lack of your experience.

It's not impossible for small binaries; however, you just said you could debug the switch. You are not debugging several gigs of static memory loaded from an OS without a devkit and deep understanding at the code you are looking at. You are going to search thousands of opcodes and stored register values and read it like like a book?

One of these would be pretty useful https://developer.nvidia.com/embedded/buy/jetson-tx1-devkit

No, no it wouldn't because it has nothing to do with Horizon, and the baseboard even differs greatly from the Nvidia Shield. Again, the same chipset has NOTHING to do with the compatibility when the rest of the hardware and bootloader are extremely different. For instance, you are not taking L4T (Linux for Tegra) for Jetson and running it on the Nvidia shield, and you are not taking the Linux port from Shield and running it on the switch without RCM and extensive driver / kernel changes.

You might patch at run time, but you'd mostly build a binary. Maybe do it using a custom bootloader which patches the OS.

Okay, this is the most sense you've made so far. Yes a custom bootloader would be needed which is what I've been saying; however, that is something you will need to reverse engineer from the switch and compile the blob for the shield.

I could debate with you all day; however, as someone who is in the science field, I believe a theory is best establish through testing your hypothesis. From where I sit, what you are describing sounds extremely oversimplified with many holes, but I am willing to give you benefit of the doubt. If it's as easy as you say it is, I will put up a $600.00 bounty right now, just for you to prove me, and the few other commenters earlier that disagree with you, wrong. Go ahead and write all the custom drivers, bootloader, kernel patches, and optimization tweaks without source code, and only use of patches, and I will fulfill the bounty. Even if just for proof of concept, no need to even run a game.

 

[weatMod]

Okay, but I want to see recovery mode on a Shield first

what? shield still has no TWRP?
i don't own one so i never bothered to check but i assumes there was

 

[Shadow LAG]

what? shield still has no TWRP?
i don't own one so i never bothered to check but i assumes there was

WeatMod, he may be referring to RCM. The Shield definitely does have a recovery partition, I own one.

 

[smf]

Source code is what you need to compile a binary.

Well it's a good job we already have a binary.

Nobody in the modern age is writing several GIGS of operating system binaries in assembly, and neither are you.

You have an order of magnitude problem. The amount of code that will need changing in horizon is considerably less than gigs.

That is nonsense. Just because a processor is the same does not mean you make a few changes in a hex editor and boom loaded.

If the processor is the same then you can very much just load it, it might not be happy and generate errors. Telling it to ignore those errors enough to get something running isn't that hard.

You first need to write a bootloader to even execute the boot chain.

Yeah, it's a pity that it's impossible to write a boot loader and nvidia don't want to sell any x1 cpus so they make it impossible to load code.

Oh wait.

The Shield doesn't even deal in fuse burning and the primary bootloader (not blob / fastboot) on the chip is not writable.

The shield has the same RCM exploit. We already have loaders that work with it.

You can patch out fuse burning with memory patches, but you are not cold booting a patched fuseset on a Nintendo Switch, nor an Nvidia shield without a custom bootloader. Again, oversimplifying.

You're just saying random stuff that has nothing to do with what I'm saying.

It's not impossible for small binaries; however, you just said you could debug the switch. You are not debugging several gigs of static memory loaded from an OS without a devkit and deep understanding at the code you are looking at. You are going to search thousands of opcodes and stored register values and read it like like a book?

Well that is interesting, because you've gone from "it's impossible" to "it's possible but really hard".

Again, the same chipset has NOTHING to do with the compatibility

it has everything to do with how much code will need changing.

Okay, this is the most sense you've made so far. Yes a custom bootloader would be needed which is what I've been saying; however, that is something you will need to reverse engineer from the switch and compile the blob for the shield.

It only doesn't make sense because you misunderstand what I've said and argued against that.

I will put up a $600.00 bounty right now,

I was thinking more like 200k, $600 doesn't buy the equipment I'd use.

 

[hippy dave]

Remind me to stop coming in this thread, you guys are seriously beating this thing to death.
Btw the guy saying you don't necessarily need source code to port something is still right, but please give it a fucking rest now.

 

[Dominator211]

you must also remember that the ram pools are different, 4gb vs 3gb... What would the point of this be? To play switch games? That would be possible becuase the switch games would require the whole pool of memory and would not have anything leftover to use. i would much like to see NVIDIA shield games like Doom 3 and portal ported over to switch. Much more practical and useable

 

[Shadow LAG]

you can port software by loading a binary into a hex editor if you're good enough.
Then you could mostly port software between them by searching for hex sequences in the binary and replacing them.

Dump all the code from the switch, patch it for minor memory and storage differences, run it, profit.

You can port without source code, the hardware is mostly the same so it wouldn't take much to get something running.

I was thinking more like 200k, $600 doesn't buy the equipment I'd use.

Okay. I'm over this.

 

[smf]

Okay. I'm over this.

You're taking the hex editing argument out of context, I didn't say I would only use a hex editor to port horizon to shield. I normally end up writing domain specific languages for these types of projects. I only bought up hex editor because of your "you need source code to port" argument and I and my friends have done some ports using hex editors.

Most of the money was for my time. If I'm going to spend time hacking something that is no value to me (I don't have a shield, I already have a switch) then I want to get paid. I don't work for free, not for you or anyone else. Feel free to haggle down.

 

[zahimi]

it will never happen...

 

[eoinzy]

I'd be much happier if we could port the gamecube emulator in the asian nvidia shield to the switch (or even the western Shield!!).