Difference between revisions of "Notes vulnerability"

From freemyipod.org
Jump to: navigation, search
(Link overflow)
m (Reverted edits by Owixyze (talk) to last revision by Cmwslw)
 
(13 intermediate revisions by 8 users not shown)
Line 1: Line 1:
== Notes vulnerability ==
 
 
=== Basics ===
 
=== Basics ===
  
The notes functionnality is basically a htm browser included in the ipod.
+
The notes functionality is basically a HTML browser included in the iPod.
Some doc can be found [http://developer.apple.com/ipod/iPodNotesFeatureGuideCB.pdf here].
+
Some documentation about it can be found [http://developer.apple.com/ipod/iPodNotesFeatureGuideCB.pdf here].
  
Basic rules are :  
+
Basic rules are:  
*64kB files are loaded just after the boot of the nano, however they are not kept in RAM
+
* 64kB files are loaded just after the boot of the iPod, however they are not kept in RAM
*each file is limited to 4kB
+
* each file is limited to 4kB
*the links point to other files, or to other notes, or to media files.
+
* the links point to other files, notes, or media files.
*the link is limited to 256 chars. apple documents this limit, but they don't say it can cause a buffer overflow ;)
+
* the link is limited to 256 chars. Apple documents this limit, but they don't say it can cause a buffer overflow ;)
  
There seem to be 2 buffers : one which is a perfect copy of the disc file, including BOM, etc..., and one after UTF16 processing
+
There are many buffers scattered throughout the RAM:
 +
# Some are perfect copies of the disc file, including BOM, etc... These are the ideal buffers to jump to.
 +
# Some have UTF16 processing. These are a burden but can be worked around.
 +
# Some have UTF8 processing. These are virtually unusable.
  
=== File loading ===
+
The main disadvantage to this vulnerability is that small buffers must be located in megabytes of RAM. The [[Pwnage 2.0]] vulnerability is now preferred since it does not have this disadvantage.
  
The htm file is converted to UTF-16 first. This limits the possible char sequences.
+
=== Dealing with UTF-16 ===
The best thing to to have most charset possibilities is  encode the exploit directly to [http://unicode.org/faq/utf_bom.html#utf16-2 UTF16].
 
  
forbidden values are :
+
If jumping to a UTF16-processed buffer, the possible character sequences are limited.
*FE FF : UTF16 BOM
+
The best thing to have the most charset possibilities is to encode the exploit directly to [http://unicode.org/faq/utf_bom.html#utf16-2 UTF16].
*D8 00 up to DF FF : not checked what happens if inserting them
 
*00 00 : would stop string processing
 
  
The opcodes to execute will be placed in the body of the htm file.
+
The forbidden values in UTF16 are:
 +
* FE FF: UTF16 BOM
 +
* D8 00 up to DF FF: not checked what happens if inserting them
 +
* 00 00: would stop string processing
 +
 
 +
The payload is placed in the body of the .htm file.
  
 
=== Link overflow ===
 
=== Link overflow ===
  
 
After loading the file, the links are then checked against the file system.
 
After loading the file, the links are then checked against the file system.
Many modified copiues of this string are present on the stack.
+
Many modified copies of this string are present on the stack.
 
We could identify the most important steps of this process, until the string overflow in the stack (order could be a little different):
 
We could identify the most important steps of this process, until the string overflow in the stack (order could be a little different):
  
Line 41: Line 45:
  
 
== Exploiting, getting execution ==
 
== Exploiting, getting execution ==
 +
 +
(Credit for the exploit goes to [[Sto]])
  
 
To exploit, we used [[Nano2G%2BHW%2Banalysis|JTAG]] to determine the correct paddings and return adresses of the buffers.
 
To exploit, we used [[Nano2G%2BHW%2Banalysis|JTAG]] to determine the correct paddings and return adresses of the buffers.
  
In my case, i had to put a second file to influence the buffer's location, in order to have a return adress which fits an UTF8 (no byte of the return adress >7F).
+
In my case, I had to place a second file to influence the buffer's location in order to have a return adress which conforms to UTF8 (no byte of the return address can be >7F).
  
An example of a working overflow file set [http://f4eru.free.fr/8701/Notes_overflow_example.zip here].
+
An example of a working overflow file set is [http://f4eru.free.fr/8701/Notes_overflow_example.zip here].
the file "Brokenlink.htm" contains first an UTF16 BOM, then "AA" as padding, then the overflowing link (return addr is 08640D60), then a NOP (opcode E1A01001) landing zone, and finlly a "while(1);"
+
The file "Brokenlink.htm" begins with a UTF16 BOM, then "AA" as padding, then the overflowing link (the return address is 0x08640D60), then a NOP (opcode E1A01001) landing zone, and finally a "while(1);"
  
This while(1) does not freeze or reset the ipod, but instead just crashes the background task. You can still scroll the menus, but hte ipod will freeze as soon as you press "play" or if you enter the notes menu, etc...
+
This "while(1);" does not freeze or reset the iPod, but instead just crashes the background task since interrupts are still enabled. You can still scroll the menus, but the ipod will freeze as soon as you press "play" or if you enter the notes menu, etc...
  
The processor arrives to the notes in supervisor state, with interrupts activated (menu scrolling), etc.
+
The processor arrives at the notes payload in supervisor state, with interrupts activated (menu scrolling) and so on.
Caches are activated, recommendation is to disable them if making complex IO & DMA stuff, else they can interfere.
+
Caches are also activated. Disabling them is recommended if you are performing complex IO & DMA stuff because they can interfere.
  
 
== Dumping memories ==
 
== Dumping memories ==
  
For dumping, first the cache was used (JTAG dumps), but very soon it turned out that the UART is more flexible.
+
For dumping the iPod's memories, first the cache was used (JTAG dumps), but it turned out that the UART is more flexible.
All these dumps can not be published here, due to copyright issues.
+
The dumps can't be published here, due to copyright issues.
  
 
== UART ==
 
== UART ==
  
The UART is exactly the same than described in the datasheet.
+
The UART is exactly the same as described in the datasheet (if one did indeed exist).
  
See [http://pargon.nl/?p=6 here] how to build an UART cable.
+
See [http://pargon.nl/?p=6 this guide] for building a UART cable for the iPod dock connector.
  
my complete setup is a little bit more complex : [[Image:Nanofighter.jpg|100px|thumb]]
+
My complete setup is a little bit more complex: [[Image:Nanofighter.jpg|100px|thumb]]
*left board : DLC5 jtag interface, modified for reset and USB switching
+
* left board: DLC5 JTAG interface, modified for reset and USB switching
*right board : some programmer board, only the ST232 is used
+
* right board: some programmer board, only the ST232 is used
*upper board : this was the jtag scanner, now only the power supply and 5V regulator are used
+
* upper board: this was the JTAG scanner, now only the power supply and 5V regulator are used
*middle board : all the switching stuff
+
* middle board: all the switching stuff
  
To automatically enter DFU mode, i wired transistors to the USB 5V line, and to the "play" and "enter" buttons of the clickwheel.
+
To automatically enter DFU mode, I wired transistors to the USB 5V line, and to the "play" and "enter" buttons of the clickwheel.
  
 
== USB ==
 
== USB ==
Because UART needs HW, USB will be used to debug in the future
+
USB was eventually figured out so we no longer needed the UART cables.
 
 
== Analysis of the dumps ==
 
 
 
to be documented
 

Latest revision as of 02:15, 24 November 2010

Basics

The notes functionality is basically a HTML browser included in the iPod. Some documentation about it can be found here.

Basic rules are:

  • 64kB files are loaded just after the boot of the iPod, however they are not kept in RAM
  • each file is limited to 4kB
  • the links point to other files, notes, or media files.
  • the link is limited to 256 chars. Apple documents this limit, but they don't say it can cause a buffer overflow ;)

There are many buffers scattered throughout the RAM:

  1. Some are perfect copies of the disc file, including BOM, etc... These are the ideal buffers to jump to.
  2. Some have UTF16 processing. These are a burden but can be worked around.
  3. Some have UTF8 processing. These are virtually unusable.

The main disadvantage to this vulnerability is that small buffers must be located in megabytes of RAM. The Pwnage 2.0 vulnerability is now preferred since it does not have this disadvantage.

Dealing with UTF-16

If jumping to a UTF16-processed buffer, the possible character sequences are limited. The best thing to have the most charset possibilities is to encode the exploit directly to UTF16.

The forbidden values in UTF16 are:

  • FE FF: UTF16 BOM
  • D8 00 up to DF FF: not checked what happens if inserting them
  • 00 00: would stop string processing

The payload is placed in the body of the .htm file.

Link overflow

After loading the file, the links are then checked against the file system. Many modified copies of this string are present on the stack. We could identify the most important steps of this process, until the string overflow in the stack (order could be a little different):

  • Fist, the link is extracted from the file, and copied to some heap or fixed buffers
  • The link is converted to UTF8. Every char >7F is encoded in many bytes
  • Then it is passed through an uppercase function
  • The URL encoding is decoded : %xx values are converted to their equivalent (limited to valid UTF8 or the like)
  • Finally, this link is copied in a limited buffer which is located on the stack. By putting a return adress repetitively in the link, the processor will jump to this adress.


For conveninece, the return adress is always encoded using %xx URL encodings. This avoids problems with some special chars and with lowercase chars. Possible values are 00 < xx <= 7F. (the unescaped chars seem to be transcoded from ISO-8859-1 to UTF8 again)

Exploiting, getting execution

(Credit for the exploit goes to Sto)

To exploit, we used JTAG to determine the correct paddings and return adresses of the buffers.

In my case, I had to place a second file to influence the buffer's location in order to have a return adress which conforms to UTF8 (no byte of the return address can be >7F).

An example of a working overflow file set is here. The file "Brokenlink.htm" begins with a UTF16 BOM, then "AA" as padding, then the overflowing link (the return address is 0x08640D60), then a NOP (opcode E1A01001) landing zone, and finally a "while(1);"

This "while(1);" does not freeze or reset the iPod, but instead just crashes the background task since interrupts are still enabled. You can still scroll the menus, but the ipod will freeze as soon as you press "play" or if you enter the notes menu, etc...

The processor arrives at the notes payload in supervisor state, with interrupts activated (menu scrolling) and so on. Caches are also activated. Disabling them is recommended if you are performing complex IO & DMA stuff because they can interfere.

Dumping memories

For dumping the iPod's memories, first the cache was used (JTAG dumps), but it turned out that the UART is more flexible. The dumps can't be published here, due to copyright issues.

UART

The UART is exactly the same as described in the datasheet (if one did indeed exist).

See this guide for building a UART cable for the iPod dock connector.

My complete setup is a little bit more complex:

Nanofighter.jpg
  • left board: DLC5 JTAG interface, modified for reset and USB switching
  • right board: some programmer board, only the ST232 is used
  • upper board: this was the JTAG scanner, now only the power supply and 5V regulator are used
  • middle board: all the switching stuff

To automatically enter DFU mode, I wired transistors to the USB 5V line, and to the "play" and "enter" buttons of the clickwheel.

USB

USB was eventually figured out so we no longer needed the UART cables.