Skip to content

Exploits and bugs

james edited this page Jan 2, 2017 · 9 revisions

SD Card Overread (memory bug)(?)

For some reason the web client can access PPMs anywhere on the SD card (details here). While this is generally quite glitchy anyway, something of particular interest is the way it handles an SD card path to a PPM that both has an invalid filename and is not on the SD card. The SD card must also be inserted.

For example:

   <meta name="upperlink" content="sdmc:/t.ppm">

This will cause the top screen to glitch out. What's actually happening here is unclear, but it looks like it's trying to display either another part of the RAM or raw SD card data as a PPM. You'll note that only PPM colors are used.

Image Cache Overread (memory bug)

We can visually read into Flipnote Studio's image cache. This is achieved using a small .npf image (1px x 15px recommended for best results, with each pixel using a different color) as the src of an image element, but then setting the width and height of the image to much larger values (128px x 1024px recommended).

  <img src="overread.npf" width="128" height="1024">

This happens because .npf images don't have any dimension information in their headers, rather, they expect that the image element will have the correct dimensions for them to be displayed properly. However if we specify much larger dimensions, the renderer will get to the end of the image data then continue reading into the image cache. This can be done quite effectively with the .npf format, as each pixel represents 1 nibble (half-byte) of data.

Text Cache Overread (memory bug)

The text cache can be read into in a similar manner to the image cache. To achieve this, we link a special .txt file in an anchor tag, like so:

  <a href="overread.txt">overread</a>

If the .txt file only consists of null characters (0x00), then the text cache won't be overwritten when this link is loaded; instead the previously cached text will be displayed until the end of file.

In tests we've used a .txt file that was 100000 bytes long with no problem, however there is a length limit which will produce an error code if exceeded.

HTML Parsing Bugs

Table Overflow (layout bug)

Flipnote Studio's browser doesn't support the position or float CSS attributes, so having content overlap something else can be difficult. Negative margins are an option, but they require you to know the exact pixel height of the overlap content.

This is where the table overflow bug comes in. We start with a html table with one row containing one column, then make that column span two rows by adding the rowspan="2" attribute.

The content of the table column is rendered, however, when the browser tries to parse the next row and finds that there isn't one, the table's height gets collapsed to 0 before moving on to the next element.

Because of this, the rest of the page will be rendered as normal, but underneath the glitched table row content. The glitched table doesn't contribute to the page scroll height calculation either.

<table>
    <tr>
        <td rowspan="2">Overlapping content</td>
    </tr>
</table>

...
Content that gets overlapped
...

Missing body tag softlock

If the app encounters a HTML page without the <body></body> tag it will softlock, with the loading frog spinning around indefinitely.

Something like this is enough:

<html>
  <head>
    <title></title>
  </head>
</html>

Other body tag weirdness

The body tag can also be included in weird places, such as within the head tag:

<html>
  <head>
    <title></title>
    <body>
      body content
    </body>
  </head>
</html>

In this case, meta tags placed inside body will actually be parsed correctly:

<html>
  <head>
    <title></title>
    <body>
      <meta name="upperlink" content="background.nbf">
      body content
    </body>
  </head>
</html>

Meta tag placement

Meta tags can be placed anywhere above the closing </head> tag and still be parsed correctly. For example, this works:

<meta name="upperlink" content="background.nbf">
<html>
  <head>
  </head>
  <body>
    body content
  </body>
</html>

Ugomenu bug (parsing bug?)

According to PBSDS there is a bug in the .ugo parser that will cause the DSi to crash when an unexpected character is encountered. This is described in more detail here