Hacking Storing Webpages for Offline in the Browser (HTML and Images)

[vgmoose]

I've come across some interesting behavior with the Wii U browser using Data URIs. A Data URI is a weird quirk of browser that allow full documents (HTML, Images, Videos, etc) to be stored entirely in the URI.

So for example, if you copy and paste the bellow Data URI in your PC browser as a URL:

data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/XBs/fNwfjZ0frl3/zy7////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAABAALAAAAAAQABAAAAVVICSOZGlCQAosJ6mu7fiyZeKqNKToQGDsM8hBADgUXoGAiqhSvp5QAnQKGIgUhwFUYLCVDFCrKUE1lBavAViFIDlTImbKC5Gm2hB0SlBCBMQiB0UjIQA7

You'll get a little star image. The star image is entirely encoded in the above URI and isn't stored on an external server. The concept is similar to magnet links.

The same can be done for HTML documents:

data:text/html,<marquee direction=right><h1>hello%20world</h1></marquee>

The above isn't base64 encoded, but encoding into base64 is useful when the data in question isn't text.

I made a sample webpage that demonstrates this:
wiiu.vgmoose.com/d

If you visit that on your Wii U, the first two links are to Data URI pages. For example, clicking the image example (second link), will load the above star image on your Wii U via a Data URI. You can then exit the browser, power off the Wii U, and the image will be there! And the coolest part is, even if there are no valid wifi networks configured the content loaded by the Data URI will always render. (can people test that this is actually true?)

So this is very close to getting any webpage to be able to be visited offline. But there's one major issue: I can't get this to work with video URIs! This seemingly prevents running Wii U Homebrew from a Data URI, as they are encoded as mp4's for 5.5.1.

It's not just homebrew mp4s that don't load, however. As seen at this url: https://iandevlin.com/html5/data-uri/video.php , Even valid .mp4 files don't play if they're data-uri encoded.

So the purpose of this thread is to seek answers... If we can get Data URIs to work with videos on the Wii U, then completely offline storage should be possible.

Why don't mp4 data URIs work?
I can't imagine Nintendo specifically blocked data-uri's specifically for videos, so I have a few theories:

1. the mime type "video/mp4" isn't actually what the Wii U uses for a video mime types (despite it working in HTML5, maybe it matters for data-uri
2. the mp4 url is getting truncated? I think this is unlikely, however, as you can see I have tests 1 through 6 demonstrating increasingly larger data uri links at my site, and the Wii U seems to handle all of them

Possible Workarounds
1. "Fix" the mime type?
2. Somehow load the video another way via javascript (not as a data URI)
3. use html5 blob objects?

Any insight is welcome. I'm pretty sure that something can be done here. MP4's can be saved (embedded in JS as HTML) to NAND via this trick, but they can't be executed!

Sidenote: if there are any non-mp4 based homebrew that exist, then this data uri trick should also work.

How to make a data URI

echo "data:video/mp4;base64,"$(cat helloworld.mp4 | base64 | tr -d "\n")

Where video/mp4 is the mime type. For an HTML page you can use text/html .

 

[Deleted User]

Sidenote: if there are any non-mp4 based homebrew that exist, then this data uri trick should also work.

All of the 5.3.2 and below homebrew is in HTML and JavaScript, so would these actually work with your URI method?
But that literally only consists of the kernel exploit and outdated TCPGecko etc. builds.
Though you will need to be able to close your browser quickly enough before the exploit launches in order to store it... or you could type it manually to insert it into your bookmarks, lol.

You're using "video/mp4" as the MIME type: does "application/mp4" work?

 

[QuarkTheAwesome]

All of the 5.3.2 and below homebrew is in HTML and JavaScript, so would these actually work with your URI method?
But that literally only consists of the kernel exploit and outdated TCPGecko etc. builds.
Though you will need to be able to close your browser quickly enough before the exploit launches in order to store it... or you could type it manually to insert it into your bookmarks, lol.

The cool thing about this is that you could set up a GUI with html and close the browser on that; essentially allowing a fully offline exploit. It's still annoying that this doesn't work on mp4s though.

 

[vgmoose]

All of the 5.3.2 and below homebrew is in HTML and JavaScript, so would these actually work with your URI method?
But that literally only consists of the kernel exploit and outdated TCPGecko etc. builds.
Though you will need to be able to close your browser quickly enough before the exploit launches in order to store it... or you could type it manually to insert it into your bookmarks, lol.

You're using "video/mp4" as the MIME type: does "application/mp4" work?

Just tried application/mp4, looks like that gets a "Filetype not supported" error.

For the HTML payloads, yes they should work if converted to data-uri. Is there anyone with a 5.3.2 or lower Wii U who can test? (And also, more up to date payloads?)

 

[OriginalHamster]

That's a pretty clever solution to get the exploit working offline. Out of curiosity, what is the size of the mp4 payload?

 

[vgmoose]

k... update, I might have some answers:
https://discussions.apple.com/thread/5842398?tstart=0

Apparently this has been broken in webkit on iOS7, but was fixed in iOS8. I'm guessing it's the same problem (or similar) issue here, seeing how old the Wii U's webkit is.

I've added two more samples to wiiu.vgmoose.com/d using createObjectURL and MediaSource, but neither of these are supported on the Wii U either.

I'm hoping there's another way to get binary data into an HTML5 <video> element, but it doesn't look likely! Can any web developers chime in?

 

[KiiWii]

I have 5.3.2 if I get spare time I can test

 

[Drak0rex]

I just started up my wii u and opened up the internet browser, on which I previously had the 5.5.1 exploit hosted from xampp. This time I didn't even have xampp running and it still ran loadiine and loaded games. I didn't know that was a thing.

 

[CJB100]

k... update, I might have some answers:
https://discussions.apple.com/thread/5842398?tstart=0

Apparently this has been broken in webkit on iOS7, but was fixed in iOS8. I'm guessing it's the same problem (or similar) issue here, seeing how old the Wii U's webkit is.

I've added two more samples to wiiu.vgmoose.com/d using createObjectURL and MediaSource, but neither of these are supported on the Wii U either.

I'm hoping there's another way to get binary data into an HTML5 <video> element, but it doesn't look likely! Can any web developers chime in?

Add me on Skype (same user name) or message me on here. My specialty is HTML, CSS, SQL, Java and ASP.NET web development. I think we should be able to figure this out. Just fyi though I am a VERY busy person atm. I won't have time to help until Friday afternoon, but with some time and dedication, I'm basically 100% confident we could get this working somehow.

 

[CJB100]

This may be a tough one. I think, as was discussed in iandevlin's blog, and pointed out by vgmoose, there might be an issue with the Wii U being able to play URI HTML5 videos -- like an actual bug, not something Nintendo actually intended. The error that I get consistently is one that a lot of people have said is due to improper audio formatting in the file. Mixing down to stereo often resolves the issue on legitimate video files, but files that play normally do not play as URI and give that error. I have an inclination to believe that this may be more to do with the way the Wii U browser initially tries to load the video, though, when it attempts to start playing. The thing is, I wonder what would happen if we could switch the src half-way through the video? Normally you can't do this with the Wii U, however:

https://www.nintendo.com/wiiu/built-in-software/browser-specs/extended-functionality/

It is possible to play mp4 videos inline if you have a high enough firmware. That means the user can watch a video and do other things on the page at the same time.

Tomorrow, I might make a really quick mock page that has a legitimately linked video, see if I can also put in a java user control that takes in a user string (pre-populated with the URI text for a exploit mp4), and then see if I can switch the src of the video in mid play if the user clicks submit by editing the video or source tags' src attribute, just to get a feel for what will happen. Honestly, I'm just expecting some sort of browser crash or error message, but I'm just out of ideas at the moment. Even if it "works," I don't know how we could go about switching the src in a fully contained environment, or how we would get the Browser to believe there is actually a video linked long enough to start playing while a system would be offline. Once I know what switching the src half-way through a video does, if by some miracle it works out, I'll have to see if any java functions can be fudged or if JS (I hate JS :/) has any similar functionality.

Or, you know.. if someone gets to it before I do.

Are there any exploits that work with images or any other parts of the browser? I don't think the Wii U Browser even supports audio outside mp4's and -- oddly enough -- 3gp files. So that's a no go.

 

[vgmoose]

[...] Tomorrow, I might make a really quick mock page that has a legitimately linked video, see if I can also put in a java user control that takes in a user string (pre-populated with the URI text for a exploit mp4), and then see if I can switch the src of the video in mid play if the user clicks submit by editing the video or source tags' src attribute, just to get a feel for what will happen. Honestly, I'm just expecting some sort of browser crash or error message, but I'm just out of ideas at the moment. Even if it "works," I don't know how we could go about switching the src in a fully contained environment, or how we would get the Browser to believe there is actually a video linked long enough to start playing while a system would be offline. [...]

Are there any exploits that work with images or any other parts of the browser? I don't think the Wii U Browser even supports audio outside mp4's and -- oddly enough -- 3gp files. So that's a no go.

This is interesting, so kind of tricking the Wii U into believing there's a legit video URL behind the <video> by swapping out a real one with a data-uri mid way. I'd be curious to see if that worked, but like you said that still leaves us with the issue of needing to contain it all within a data-uri environment.

As for other entrypoints, I believe there's one other private one for 5.5.1, but I don't know whether it uses mp4 or not. And those "in-the-know" would likely want to save the next entrypoint for the next update, rather than spend it just to enable offline homebrew in 5.5.1 (which is supposedly coming with iosu anyway).

@QuarkTheAwesome Are you able to somehow work some PPC assembly magic to figure out why exactly the Wii U Media Player refuses to play video if there's no real URL backing it? Since it throws the same error for both data-uri and blobs, it almost feels like it's a requirement of the media player to have an HTTP URL backing it.

EDIT: also not really related, but it's interesting that one can actually enable "Debug mode" in the browser settings, and then visit that IP on the Wii U itself to gain access to a webkit console. This might also prove useful for something if it can be used entirely offline.

 

[CJB100]

Well, I just attempted a lot of different things, and I have completely narrowed down the issue of getting URI videos to work. Surprisingly, changing the video source attribute of the HTML5 video player in the middle of a video already playing does work, even in the Wii U browser. However, if you interrupt a legitimate video with a URI video, you get the same error as any other time.

Unfortunately, I don't think this is something that we will be able to get around, as the issue is that no matter what happens, the browser must call a method called load() whenever an html5 video document object is created, inserted or any time the source on the html5 video document object is changed. Essentially, you can start a video playing, and change the src attribute of the html5 video, but the original video will keep playing until the buffer ends -- or in other words until you reach the end of what the browser has cached of the video. But you cannot view or stream information from the new source until you call the load() method or until it is called for you by some other means.

I have tried everything I can think of to get around this. Looping has no programmatic holes to exploit, as once the video from the original source ends, the browser seems to start the video over from the browser cache in some fashion, and it won't try to load the video from the new source. I'm guessing part of the load() method is to get the location of the original source into a string variable. Whenever the browser loops html5 videos, if it has run out of actual video cache (I set a several minute video to loop, and I doubt the Wii U Browser has a lot of cache dedicated to video), it appears that it refers to this string to get the source, rather than the new src which has been changed with Java or JS. The only way to get the browser to acknowledge the newly defined source is to call the load() method, at which point, if you are attempting to switch to a URI, it freaks out as expected.

At one point I did manage to keep the mp4 player on the web browser from completely crashing after getting the URI error. You can do this by starting a video inline, then changing the src attribute of the video while the video is playing, then pausing the video, then calling the load() method. You get an error, but if you click cancel, the MP4 object doesn't go to its typical player symbol with a stop symbol overlayed on it. Instead, the controls are all there, still loaded, and operable. But since the Wii U doesn't see a legitimate MP4 file, you can't really do anything with this.

Since the browser is what does the work of converting a data URI into the original file, perhaps there is a way to force the browser to save the data URI to browser cache or somewhere on NAND (browsers typically do not cache URI's), and modify the src attribute with Java or JS to retrieve it? Although, I don't know of a way to manipulate what a browser caches off the top of my head, and I can't even begin to know where the Wii U Browser caches anything, so I doubt this would work unless someone knows where the browser cache is.

TL;DR:
I don't think a fully offline exploit webpage will be possible, at least with the MP4 method. There is apparently a method where code is directly embedded into a webpage, but this doesn't give kernel permissions, I think? Even if I or someone else still feels like tinkering with this long enough to get a "URI substitution" video working, I don't know how we would get the browser to believe it is reading a legitimate video in the first place without the user actually being online.

Here's the code I was using in my html page:

Spoiler

<html>
  <body>
    <video id='videoPlayer' width="320" height="240" controls="controls" webkit-playsinline>
       <source id='mp4Source' src="HankHill.mp4" type="video/mp4" />
    </video>

    <button onClick="change()">Change</button>
    <button onClick="play()">Force Play</button>
    <!-- You MUST give your sources tags individual ID's for the solution to work. -->
  
    <script>
        var player = document.getElementById('videoPlayer');
        player.loop = true;
        player.preload = false;
    </script>
  
    <script>
      function change()
      {
          var player = document.getElementById('videoPlayer');

          var mp4Vid = document.getElementById('mp4Source');

          //player.pause();

          // Now simply set the 'src' property of the mp4Vid variable!!!!

          mp4Vid.src = "data:video/mp4;base64,AAAAGGZ0eXBtcDQyAAAAAGlzb21tcDQyAAALQG1vb3YAA......"; //this was the full base64 video DramaticChipmunk.mp4
          //player.load();
          //player.play();
      }
    
      function play()
      {
    
          var player = document.getElementById('videoPlayer');
          player.load();
      }
    </script>
  </body>
</html>

Here is the easy to use base64 converter I utilized, I can testify it works.
https://www.giftofspeed.com/base64-encoder/

Here are some helpful links for HTML5 Video Document Objects:
http://www.w3schools.com/tags/ref_av_dom.asp
http://www.w3schools.com/html/html5_video.asp
https://www.nintendo.com/wiiu/built-in-software/browser-specs/extended-functionality/

The ROOT folder of my apache installation is attached.

I'm probably giving up on this for now unless someone finds out something that peaks my interest.

 

[QuarkTheAwesome]

@QuarkTheAwesome Are you able to somehow work some PPC assembly magic to figure out why exactly the Wii U Media Player refuses to play video if there's no real URL backing it? Since it throws the same error for both data-uri and blobs, it almost feels like it's a requirement of the media player to have an HTTP URL backing it.

I'll take a peek; not sure if I'll find much though.
It might be time to start trawling through CVEs anyway... Do we know the exact version of WebKit on 5.5? I suppose this is for another thread.

 

[rw-r-r_0644]

I'll take a peek; not sure if I'll find much though.
It might be time to start trawling through CVEs anyway... Do we know the exact version of WebKit on 5.5? I suppose this is for another thread.

Yes, we do
That code is actually used to identify the version for running the correct exploit;
5.5.1 webkit version is 3.0.4.2.12 but it has some patched to fix some exploits of succsssive versions.

 

[QuarkTheAwesome]

Yes, we do
That code is actually used to identify the version for running the correct exploit;
5.5.1 webkit version is 3.0.4.2.12 but it has some patched to fix some exploits of succsssive versions.

Taking a peek at Nintendo's OSS WebKit download, there appears to be 3 versions of WebKit used on the Wii U - "WebKit_WiiU3.0b", "WebKit_WiiU3.1" and "WebKit_WiiU4.0". 3.0b and 3.1 seem to be from late 2011, while 4.0 is from early 2012. No idea which one is 3.0.4.2.12 and all the commits use revision numbers

Anyhow, I've found a few, uh, interesting commits which could serve as a good starting point. I am a bit worried though; they're quite recent and if Nintendo updates WebKit to patch them out, we'd end up with a pretty modern browser and not many places to go.

Edit: Scrap that bug, Nintendo's WebKit is so old the file the bug is in doesn't even exist. For those curious, I was mulling over this commit here.

 

[vgmoose]

Old thread!

Anyone ever try something like this using the newer 5.5.2 web exploit? I'm curious if it would work since it doesn't require the media player, but I'm not on 5.5.2 to try it out.

 

[jbuck1975]

Old thread!

Anyone ever try something like this using the newer 5.5.2 web exploit? I'm curious if it would work since it doesn't require the media player, but I'm not on 5.5.2 to try it out.

Do I need to just go to your Web page with the test?

--------------------- MERGED ---------------------------

I went to website and tried all of them. Got counts on the test. None of videos would load. Gave me can not load on everything

 

[vgmoose]

Do I need to just go to your Web page with the test?

--------------------- MERGED ---------------------------

I went to website and tried all of them. Got counts on the test. None of videos would load. Gave me can not load on everything

Oh, I hadn't updated the link on the site yet, was curious if anyone had tried it though.

@jbuck1975 I now added a 5.5.2 test at the top of http://wiiu.vgmoose.com/d/ . I took it from the stupiidhax website and turned it into a data uri.

 

[jbuck1975]

Mii went to sleep then error message about size (not all page could be displayed)

 

[jbuck1975]

But your originally thoughts
Maybe inject an html file with ftp to the wii u file system?