<A> comex: I think you're a wee bit too excited about project m 
They are probably right. ;p
They are probably right. ;p
Thanks for all the information (Marcan, Comex, delroth, OBCD, etc). If Marcan and others did not care then they would not read and reply. I had somebody else being involved with Crediar being the dev working on something else. ONLY because his Nintendon't project is highly anticipated (see the thread and views)...and his twitter literally said something like, "Impossible is nothing Wii U base is next." Anyway, at least the interest is enough for everyone to share their views.
EDIT: Getting Windwaker HD and Mario 3D for Christmas, lol, mother-in-law bought for me which is the best price...and legit;-)
EDIT: Getting Windwaker HD and Mario 3D for Christmas, lol, mother-in-law bought for me which is the best price...and legit;-)
- Joined
- Apr 29, 2011
- Messages
- 31,284
- Trophies
- 2
- Age
- 38
- Location
- Dr. Wahwee's castle
- XP
- 18,969
- Country
Hmm, weird indeed, I remember that tweet as well, I wonder why he took it off, there has to be a legitimate reason. One would not dare ask him why though.
I just spread the word of this thread to Kongregate. Plus here is some useful Assembly, C (since again C is influenced BY Assembly) and C# stuff you might wanna look at Maxternal and maybe add to your starting post.
http://en.wikipedia.org/wiki/Assembly_language
http://en.wikipedia.org/wiki/C_(programming_language)
http://en.wikipedia.org/wiki/C_Sharp_(programming_language)
http://www.int80h.org/
http://www.atariarchives.org/mlb/introduction.php
http://www-03.ibm.com/systems/z/os/zos/bkserv/r8pdf/index.html#hlasm
http://c2.com/cgi/wiki?LearningAssemblyLanguage
http://mark.masmcode.com/
http://www.quitecode.com/
Plus here is some useful Assembly, C (since again C is influenced BY Assembly) and C# stuff you might wanna look at Maxternal and maybe add to your starting post. http://en.wikipedia.org/wiki/Assembly_language
http://en.wikipedia.org/wiki/C_(programming_language)
http://en.wikipedia.org/wiki/C_Sharp_(programming_language)
http://www.int80h.org/
http://www.atariarchives.org/mlb/introduction.php
http://www-03.ibm.com/systems/z/os/zos/bkserv/r8pdf/index.html#hlasm
http://c2.com/cgi/wiki?LearningAssemblyLanguage
http://mark.masmcode.com/
http://www.quitecode.com/
And here is a good guide at snes cpu to sound chip reverse engineering... its great because it includes real time data and voice handling on assembly
http://www.zophar.net/fileuploads/2/10779uuyvz/iceu10.html
http://www.zophar.net/fileuploads/2/10779uuyvz/iceu10.html
marcan, I'm asking in this thread because you are relatively active here, although I appreciate it is a little off-topic.
regarding the theoretical Wii U exploit, does it work on any Wii U, or does the Wii U need to be at a particular firmware level? In other words, is it worth users attempting to dump their Wii U firmware (using as SD card reader soldered to the Wii U motherboard) so that they have something they can downgrade to later? I'm thinking of the situation with the 3DS, where users (including myself) have been able to dump their firmware using such a method.
regarding the theoretical Wii U exploit, does it work on any Wii U, or does the Wii U need to be at a particular firmware level? In other words, is it worth users attempting to dump their Wii U firmware (using as SD card reader soldered to the Wii U motherboard) so that they have something they can downgrade to later? I'm thinking of the situation with the 3DS, where users (including myself) have been able to dump their firmware using such a method.
You need a NAND dumper as well as an eMMC dumper for the Wii U (the NAND has two banks, one for Wii mode and one for Wii U mode), and there is some amount of anti-downgrade protection for at least some parts of the firmware. Blindly playing the dump/restore game is difficult and probably won't always work.
efuse? On 3ds you could only go back to where you started. Read 4.0, later it has 5, so go back to 4. No way to "sign" or decrypt 3ds nand/emmc that is shared publicly. If people could recover vWii and Wii U, maybe more would be willing to explore....
That's interesting, I couldn't find some info about Wii U, even WiiUbrew.org is pretty bare bones, anyway does Wii U uses some similar fragmented OS as Wii in which different instructions are scatered among different IOS? Or it has a more unified system, asking in the wild since I'm not sure if you guys have gone so far
I posted a thread on Wii U emmc with all links I could find. Diagrams, pictures, threads, etc. Search for it.That's interesting, I couldn't find some info about Wii U, even WiiUbrew.org is pretty bare bones, anyway does Wii U uses some similar fragmented OS as Wii in which different instructions are scatered among different IOS? Or it has a more unified system, asking in the wild since I'm not sure if you guys have gone so far
The reason why I would like to have wii u homebrew are the hardware possibilities.
Emulators can use the increased horse power to get a better emulation.
Especially homecomputers (msx, atari, amiga etc.) can take advantage of the u gamepad (keyboard on touchscreen).
Furthermore you can transform the wii u to a media center. Think about an improved version of wiimc in combination with the upad.
It would be sufficient if the vWii can use the 2GB Ram and the power of one core (which is already more powerful than the cpu in the wii).
Maybe we have to think about a new approach of homebrew.
Keep it simple and smart.
You don't have to enable the whole hardware power at once.
Think about a step per step approach in which you enable more and more features.
E.g. Start with a "wii u homebrew channel" (similar or comparable to vWii) which only enables one core with the speed of the Wii CPU and for instance 256 MB RAM (it's more or less a clone of the vWii with more RAM). In this case you don't have to deal with difficulties like triple core coding.
Potential homebrew developers can start with programming or porting and in parallel the "u hackers" can enhance the "u homebrew channel".
In the next release, the "u homebrew channel" enables 1GB of RAM, one core at full speed and the UPad. (however you have to think about backwards compatibility)
From now on the Homebrew devs can use the additional power and features to improve their apps.
The next "u homebrew channel" release enables some GPU features. And so on.
This approach has a lot of benefits:
- You don't have to deal with complex drivers at the beginning (triples core driver, GPU features, etc.)
- You cannot use the "U Homebrew channel" for pirating U software (because the hardware power is restricted).
- Potential Homebrew developers can start with software.
- In parallel the "U homebrew channel" providers can enhance the homebrew channel with new features (especially if they see there is an interest in a homebrew community)
We know a lot about the vWii and especially how it is working.
So why not "re-coding" the vWii as "U Homebrew channel"
Marcan mentioned already a similar appraoch. Namely leaving the vWii sandbox.
However leaving the sandbox is extremely difficult. So why don't we build up a new sandbox (which runs wii homebrew and which can access more and more hardware power)
Emulators can use the increased horse power to get a better emulation.
Especially homecomputers (msx, atari, amiga etc.) can take advantage of the u gamepad (keyboard on touchscreen).
Furthermore you can transform the wii u to a media center. Think about an improved version of wiimc in combination with the upad.
It would be sufficient if the vWii can use the 2GB Ram and the power of one core (which is already more powerful than the cpu in the wii).
Maybe we have to think about a new approach of homebrew.
Keep it simple and smart.
You don't have to enable the whole hardware power at once.
Think about a step per step approach in which you enable more and more features.
E.g. Start with a "wii u homebrew channel" (similar or comparable to vWii) which only enables one core with the speed of the Wii CPU and for instance 256 MB RAM (it's more or less a clone of the vWii with more RAM). In this case you don't have to deal with difficulties like triple core coding.
Potential homebrew developers can start with programming or porting and in parallel the "u hackers" can enhance the "u homebrew channel".
In the next release, the "u homebrew channel" enables 1GB of RAM, one core at full speed and the UPad. (however you have to think about backwards compatibility)
From now on the Homebrew devs can use the additional power and features to improve their apps.
The next "u homebrew channel" release enables some GPU features. And so on.
This approach has a lot of benefits:
- You don't have to deal with complex drivers at the beginning (triples core driver, GPU features, etc.)
- You cannot use the "U Homebrew channel" for pirating U software (because the hardware power is restricted).
- Potential Homebrew developers can start with software.
- In parallel the "U homebrew channel" providers can enhance the homebrew channel with new features (especially if they see there is an interest in a homebrew community)
We know a lot about the vWii and especially how it is working.
So why not "re-coding" the vWii as "U Homebrew channel"
Marcan mentioned already a similar appraoch. Namely leaving the vWii sandbox.
However leaving the sandbox is extremely difficult. So why don't we build up a new sandbox (which runs wii homebrew and which can access more and more hardware power)
Because if anyone other than Nintendo does this using a Wii U mode exploit, it will take less than a month for any pro-piracy developer with half a clue to turn the exploit into a piracy patch, and remove the sandboxing.
Then it's not a sandbox.
A sandbox clearly defines walls in which the developers can act.
The only master of the sandbox is the one who is creating the box. He has to ensure that every measures have been taken that the developers can only act in the sandbox.
He is defining which registers to use (memory map), he defines which hardware components can be used etc. Furthermore everything in a secure way.
The exploit itself (or the installation process of the sandbox) must be secure. That should be clear. You only have to find a way to install a sandbox in a secure way, so that no pirate can take over the installation process. And also if the pirates gain control over the installation they have to create a loader. The loader has the same problems as homebrew. You have to develop interfaces concerning the whole hardware in order to run the software properly.
Create a "secure exploit" which is only accepting some kind of signed software.
The signed software is the sandbox (in our case the modified vWii) and finally you have a controlled environment.
At the moment you have everything on your side.
You have the exploit and you can create the sandbox to provide an extremely attractive homebrew solution (from my point of view).
A sandbox clearly defines walls in which the developers can act.
The only master of the sandbox is the one who is creating the box. He has to ensure that every measures have been taken that the developers can only act in the sandbox.
He is defining which registers to use (memory map), he defines which hardware components can be used etc. Furthermore everything in a secure way.
The exploit itself (or the installation process of the sandbox) must be secure. That should be clear. You only have to find a way to install a sandbox in a secure way, so that no pirate can take over the installation process. And also if the pirates gain control over the installation they have to create a loader. The loader has the same problems as homebrew. You have to develop interfaces concerning the whole hardware in order to run the software properly.
Create a "secure exploit" which is only accepting some kind of signed software.
The signed software is the sandbox (in our case the modified vWii) and finally you have a controlled environment.
At the moment you have everything on your side.
You have the exploit and you can create the sandbox to provide an extremely attractive homebrew solution (from my point of view).
How would that sandbox be different from a wiiu linux? I don't think wiiu games run on linux...
I never heared anyone (exept me) mention the possibilities that Ninty could fix the exploit. It doesn't seem to be a problem.
This obviously would mean that Ninty also couldn't stop any piracy software created with it, but,
it wouldn't be the first time I am wrong about something.
I never heared anyone (exept me) mention the possibilities that Ninty could fix the exploit. It doesn't seem to be a problem.
This obviously would mean that Ninty also couldn't stop any piracy software created with it, but,
it wouldn't be the first time I am wrong about something.
As explained a sandbox could be simpler. Like the vWii.
One Core, Same amount of RAM, same instruction set.
The potential homebrew developers can start right away.
A Linux has to deal with the whole architecture and the complexity of e.g. TriCore instructions.
Means until you get a proper running OS you need a lot of time and effort.
And even with the Linux you could run piracy software. Linux itself doesn't prevent piracy software.
The sandbox has a different approach (limited access to the hardware). However the difficulty is to install the sandbox in a secure way.
Marcan is fully right about the exploit. As soon as the exploit is released, other coders could take control over the exploit and release piracy stuff.
So you have to find a way that the exploit itself is only accepting the sandbox installer.
(there are some methods like secure loader and signed software, as mentioned above)
The other way would be to enhance somehow the vWii with the U hardware features. But this is extremely difficult because the vWii is shutting down some registers which are necessary for the other hardware features.
One Core, Same amount of RAM, same instruction set.
The potential homebrew developers can start right away.
A Linux has to deal with the whole architecture and the complexity of e.g. TriCore instructions.
Means until you get a proper running OS you need a lot of time and effort.
And even with the Linux you could run piracy software. Linux itself doesn't prevent piracy software.
The sandbox has a different approach (limited access to the hardware). However the difficulty is to install the sandbox in a secure way.
Marcan is fully right about the exploit. As soon as the exploit is released, other coders could take control over the exploit and release piracy stuff.
So you have to find a way that the exploit itself is only accepting the sandbox installer.
(there are some methods like secure loader and signed software, as mentioned above)
The other way would be to enhance somehow the vWii with the U hardware features. But this is extremely difficult because the vWii is shutting down some registers which are necessary for the other hardware features.
According to Team f0f, enhancing vwii is not extremely difficult, but impossible.
Once the registers with the settings are disabled, only a reset will enable those again.
While it's still possible to keep running all 3 cores, increasing their clock speed and enabling the extra memory is no longer possible.
Maybe creating a sandbox isn't possible either. It could be an all or nothing situation. (wiiu mode or vwii mode)
Even if it's possible and easier, Marcan said they have no interest in creating a homebrew environment for the wiiu.
Once the registers with the settings are disabled, only a reset will enable those again.
While it's still possible to keep running all 3 cores, increasing their clock speed and enabling the extra memory is no longer possible.
Maybe creating a sandbox isn't possible either. It could be an all or nothing situation. (wiiu mode or vwii mode)
Even if it's possible and easier, Marcan said they have no interest in creating a homebrew environment for the wiiu.
Thanks. I was aware that to dump the vWii firmware would require an Infectus or similar, which is trickier than the eMMC method for the Wii U firmware. Are you saying that we would have to dump the vWii firmware too, if we wanted any chance of later downgrading, even if all I was interesting in was Wii U mode, not vWii? Does the Wii U exploit use vWii mode?
Still, if they've got downgrade protection, then this is mostly irrelevant.
-
-
@
Xdqwerty:
@Psionic Roshambo, More or less those activities where two or more people do a exam instead of 1 (I still don't know how to explain) -
-
-
-
-
-
-
@
K3Nv2:
I wish we could comment on Google reviews some of them just sound like they were written by r tards+2 -
-
-
-
-
-
-
-
S @ StealthD0g99:I think we as a society should take the Cave Johnson approach to scientific studies
-
-
-
@
K3Nv2:
Lmao now I can live the life of Juan https://store.playstation.com/en-us/product/UP5805-CUSA47233_00-0050709204508097
-
-
-
-
-
