It's not safe on the streets... especially for your 3DS!

Exploring a new attack surface on the 3DS

State of 3DS hacking

• many userland exploits, patched kernel flaws and lots of documentation
• hardware keyscrambler broken (32c3)
• bootroms dumped (33c3)
• derive secret AES keys as a result
• permanent unpatchable bootROM exploit (33c3 & 33.5c3)

What is left unexplored?

Could we use these keys to attack features that were protected until then?

StreetPass

What is StreetPass ?

• local wireless communication feature
• automatically communicates with nearby 3DS systems
• allows applications to exchange data (custom levels, messages, Miis, ...)

Hacker point of view...

How does it work?

What to attack?

StreetPass Protocol?

• a bit of documentation on the pairing sequence
  • never been successfully reproduced...
• unknown encrypted protocol operating according to IEEE 802.11 standards (use AES keyslot 0x2E)

Pairing

Pairing Sequence

Pairing ✓

• netlink protocol to communicate with drivers (libnl)
• use nl80211 to send/recv probe requests/responses
• everything else is handled by the driver :)

Encryption

Session Key Derivation

Decryption ✓

• uses AES-CCMP
• nl80211 lets you register CCMP keys
  • receive and send encrypted packets using raw sockets and send/recv syscalls :)

Reversing the Protocol

Early Analysis

						59 59 30 00 AD DE AF BE 00 00 00 00 00 00 00 00
						0C 10 B8 38 00 00 00 00
					

						59 59 68 00 AD DE AF BE 00 00 00 00 00 00 00 00
						0C 38 B8 38 00 00 00 00 63 63 00 00 43 00 00 00
						00 00 00 00 10 00 00 00 1B 00 10 00 1A 80 0F 00
						FF FF FF FF 74 54 12 00
					

						59 59 56 00 AD DE AF BE 00 00 00 00 00 00 00 00
						0C 38 B8 38 00 00 00 00 63 63 FF FF 12 00 00 00
						00 00 00 00 16 00 00 00 11 0A 00 05 16 00 30 00
						02 08 00 00 F0 08 A3 E1 84 BD C0 05 BF 49
					

Two Protocols!

• StreetPass Transmission Control Protocol (SPTCP)
  • quite similar to TCP but for local communication
  • ensures reliability
  • handles data segmentation


• StreetPass Message Transfer Protocol (SPMTP)
  • sends packets over SPTCP
  • handles exchanging streetpass messages

SPTCP

SPTCP Security

• found no deadly bug
  • maybe some minor unexploitable ones
• attack surface is not that large
  • SPMTP is much more interesting!

SPMTP

Two Types of Packets

						63 63 00 00 43 00 00 00 00 00 00 00 10 00 00 00
						1B 00 10 00 1A 80 0F 00 FF FF FF FF 74 54 12 00
					

						61 61 00 00 80 30 00 00 00 16 05 00 00 00 00 00
						01 00 00 00 60 60 00 00 6C 30 00 00 48 0D 00 00
						04 23 00 00 00 16 05 00 00 00 00 00 00 00 00 00
						00 00 00 00 12 1D AA 64 90 76 5A CB 00 00 ...
					

Info Packets

• fixed size data
  • nothing fancy...
  • Friend Code, MAC address, date & time, etc.
• variable size data
  • application list, message box metadata list, etc.
  • much more interesting! any buffer overflow in sight?

Box Metadata List Parsing

						
void copy_box_info_list(box_info_list* dst, box_info_list* src)
						{
						  memcpy(dst, src, sizeof(box_info_list_header));
						  if(dst->header.magic == 0x6565)
						  {
						    dst->box_count = dst->header.count;
						    for(int i = 0; i < dst->box_count; i++)
						      memcpy(&dst->box_info[i],	&src->box_info[i],
									sizeof(box_info_entry));

						  }
						}
					

Box Metadata List Parsing

How do we exploit it?

1. embed a small ROP-chain in the box list
2. send another one in a packet
3. stack-pivot to the second chain

Message Box Packets

• list of StreetPass messages (max 64)
• stored in temporary files ("TMP_XX")
  • let's call them "TMP Box"
• parsed once the communication is over

TMP Box File Loading

						int load_TMP_file(tmp_box* dst, tmp_file* file_buffer,
							size_t file_size) {
						  ...

						  message* current_msg = file_buffer->messages;
						  while(dst->header.msg_count > i && end_of_file > current_msg) {
						    uint32_t msg_size = message_get_size(current_msg);
						    dst->msg_pointers[i] = current_msg;
						    dst->msg_sizes[i] = msg_size;
						    current_msg += msg_size;
						    i++;
						    glob_tmp_box_alloc_mode  = POINTER_MODE; // POINTER_MODE  = 0
						  }

						  dst->header.msg_count = i;
						  return 0;
						}
					

TMP Box Overflow

What can we do?

						int load_TMP_file(tmp_box* dst, tmp_file* file_buffer,
							size_t file_size) {
						  ...

						  message* current_msg = file_buffer->messages;
						  while(dst->header.msg_count > i && end_of_file > current_msg) {
						    uint32_t msg_size = message_get_size(current_msg);
						    dst->msg_pointers[i] = current_msg;
						    dst->msg_sizes[i] = msg_size;
						    current_msg += msg_size;
						    i++;
						    glob_tmp_box_alloc_mode  = POINTER_MODE; // POINTER_MODE  = 0
						  }

						  dst->header.msg_count = i;
						  return 0;
						}
					

What to overwrite?

						void parse_all_TMP() {
						  [...]
						  tmp_box tmp_box;
						  critical_section* lock; // overwritten by overflow in parse_TMP_file!
						  [...]
						  for(int i = 0; i < TMP_file_count; i++) {
						    enter_critical_section(&lock, &global_lock); // restore lock value!
						    file_buffer = malloc(TMP_file_size[i]);
						    [...] // file reading, etc.
						    parse_TMP_file(&tmp_box, file_buffer, TMP_file_size[i]);
						    write_messages_from_tmp_box(...);
						    [...] // deleting file, etc.
						    free_tmp_box(tmp_box);
						    leave_critical_section(&lock); // lock = arbitrary value!
						  }
						  [...]
						}
					

Critical Section?

						void leave_critical_section(critical_section** lock_ptr) {
							*lock_ptr->count--;
							[...] // actual unlocking code...
						}
					

Allocation Modes?

						void free_tmp_box(tmp_box* box) {
						  if(box->header.msg_count && glob_tmp_box_alloc_mode != POINTER_MODE){
						    for(int i = 0; i < box->header.msg_count; i++) {
						      if(box->msg_pointers[i]) {
						        free(box->msg_pointers[i]);
						        box->msg_pointers[i] = NULL;
						      }
						    }
						    [...]
						  }
						}
					

We have a problem...

						int load_TMP_file(tmp_box* dst, tmp_file* file_buffer,
							size_t file_size) {
						  [...]

						  memcpy(dst, file_buffer, sizeof(tmp_box_header)); // copy header
						  if(dst->header.size != file_size)                 // if invalid size
						    return 0xC8E1086A;                              // return error

						  while(dst->header.msg_count > i && end_of_file > current_msg) {
						    [...]
						    glob_tmp_box_alloc_mode = POINTER_MODE; 
						  }
						  [...]
						}
					

Whatever...

						void parse_all_TMP() {
						  [...]
						  tmp_box tmp_box;
						  critical_section* lock;
						  [...]
						  for(int i = 0; i < TMP_file_count; i++) {
						    enter_critical_section(&lock, &global_lock);
						    file_buffer = malloc(TMP_file_size[i]);
						    [...] // file reading, etc.
						    parse_TMP_file(&tmp_box, file_buffer, TMP_file_size[i]);
						    write_messages_from_tmp_box(...);
						    [...] // deleting file, etc.
						    free_tmp_box(tmp_box);
						    leave_critical_section(&lock);
						  }
						  [...]
						}
					

What can we do so far?

• send a first TMP box
  • overwrite the lock & decrement the alloc mode
• send a second TMP box (invalid header)
  • parser returns early so msg_pointers is not updated
  • all pointers in msg_pointers are freed

What do we do next?

• the 3DS heap is insecure
  • classic unsafe-unlink
  • one arbitrary write for each chunk you free
• rewrite the heap free-list head pointer
  • make it point to the stack
  • next malloc call will return a pointer to the stack!

Exploit scenario

Second RCE in CECD ✓

Again?

Third RCE in CECD ✓

Post-Exploitation

Taking over the ARM11 kernel

IPC: Static Buffers

• for regular large buffers
  • map parts of the sender's memory into the receiver's
• for regular small buffers
  • receiver can register some static buffers
  • copy from the sender's buffer to the receiver's buffer done by the ARM11 kernel
• for buffers sent to the ARM9 (over PXI)
  • ARM11 kernel writes pairs of {physical address, size} to static buffers for the ARM9 side to understand
  • copy of data done by Process9 (ARM9 side) using the given physical address

LazyPixie

1. check alignment of the destination static buffer
2. check size of the destination static buffer
3. check permissions for the source buffer
4. check permissions for the destination buffer
5. cache operations, etc.
6. copy metadata to the destination static buffer

ARM11 Kernel has fallen!

Road to full system control

safehax

• race condition in firmware header parsing
  • take over ARM9 if you control ARM11 kernel
• fixed in version 9.5.0 for regular (native) firmware
  • remains unfixed in safe mode firmware
• mitigated in version 11.3.0 and 11.4.0

Mitigated? Not Patched?

How do they prevent it?

safehax "Mitigation"

• add a global boolean flag on ARM9 side
  • set to 1 ⇒ panics when trying to launch safe mode firmware
• flag set to 1 when applications are launched
  • except for home menu and system modules

Full control RCE ✓

without user interaction ✓

Demo Time!

Some Takeaways

• you'd better check your return values
• don't hide behind cryptography
  • your encryption might get broken faster than you think
• assessing hard-to-reach features is arduous but can lead to amazing (yet dangerous) results!
• fix you flaws
  • don't implement poor mitigations...
• there're still things to do on 3DS!
  • amazing system to work on
  • check out the documentation on 3DBrew!

Acknowledgements

• @TuxSH: LazyPixie, joint effort on leveraging safehax
• @hedgeberg: recurrent support, help with so many things it would not fit in the slide...
• 3DBrew contributors: amazing documentation
• Nintendo: allowing me to talk about these great things and patching the flaws

Contact