Difference between revisions of "Notes vulnerability"
(→Basics) |
|||
(16 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
− | |||
=== Basics === | === Basics === | ||
− | The notes | + | The notes functionality is basically a HTML browser included in the iPod. |
− | Some | + | 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 | + | * 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, | + | * the links point to other files, notes, or media files. |
− | *the link is limited to 256 chars. | + | * the link is limited to 256 chars. Apple documents this limit, but they don't say it can cause a buffer overflow ;) |
− | There | + | 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. | ||
− | + | 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 [http://unicode.org/faq/utf_bom.html#utf16-2 UTF16]. | |
− | |||
− | |||
− | The | + | 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 | + | 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 38: | Line 42: | ||
− | 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. | + | 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 == | == 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, | + | 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" 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 | + | 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 | + | The processor arrives at the notes payload in supervisor state, with interrupts activated (menu scrolling) and so on. |
− | Caches are activated | + | 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 | + | 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 == | == UART == | ||
− | The UART is exactly the same | + | The UART is exactly the same as described in the datasheet (if one did indeed exist). |
− | See [http://pargon.nl/?p=6 | + | 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]] | |
− | *left board : DLC5 | + | * 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 | + | * 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, | + | 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 == | ||
− | + | USB was eventually figured out so we no longer needed the UART cables. | |
− | |||
− | |||
− | |||
− |
Latest revision as of 02:15, 24 November 2010
Contents
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:
- 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.
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:
- 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.