• No results found

It is both a portable and a stationary device, which makes it so that it could contain valuable information about the usage of the console at home and elsewhere

N/A
N/A
Protected

Academic year: 2021

Share "It is both a portable and a stationary device, which makes it so that it could contain valuable information about the usage of the console at home and elsewhere"

Copied!
76
0
0

Loading.... (view fulltext now)

Full text

(1)

Master Thesis

HALMSTAD

UNIVERSITY

Master's Programme in Network Forensics, 60 credits

Forensic Analysis of the Nintendo Switch

Digital Forensics, 15 credits

Halmstad 2020-06-06

Jelle van den Berg, Filip Lagerholm

(2)
(3)

i

Forensic Analysis

of the Nintendo Switch

Master Thesis Network Forensics

June 2020

Authors Filip Lagerholm Jelle van den Berg

Supervisor Ross Friel

Examiner Stefan Axelsson

(4)

ii This page has intentionally been left blank

(5)

iii Abstract

In this thesis, we did a forensic analysis of a Nintendo Switch gaming console. It is both a portable and a stationary device, which makes it so that it could contain

valuable information about the usage of the console at home and elsewhere. Multiple methods of data extraction were used, including using an exploit to obtain storage memory, extracting the contents of the SD card and capturing network traffic. The findings from the analysis of these data sources were compared to the information on the user interface. Any information that could not be found on the user interface was reported. The main findings of memory analysis were a detailed log file of user interactions, JSON files with personal information such as email addresses, and crash logs with information about the state of the console during the crash. The SD card mainly contains screenshots with embedded timestamps, and the network capture does not contain any forensically relevant information. The combination of these different types of information could make the Nintendo Switch a useful source of evidence during an investigation.

Keywords: Nintendo Switch, forensic analysis, hardware vulnerability, network capture.

(6)

iv This page has intentionally been left blank

(7)

v

Table of Contents

Introduction ... 1

Background ... 1

Purpose ... 1

Problem ... 2

Problematization ... 2

Limitations ... 2

Literature Review ... 5

Related work ... 5

Ways of extracting data ... 5

Manual extraction ... 5

Logical extraction ... 5

Hex Dumping / JTAG (Joint Test Action Group) ... 6

Chip-off ... 6

Micro read ... 6

Fusée Gelée vulnerability ... 6

Method ... 7

Tools, software and hardware used ... 8

To be analysed ... 8

To perform the experiments ... 8

For analysing the results ... 9

Experiments ... 10

1 – Network capture... 10

Method ... 11

Recording the data ... 11

Analysing the data ... 12

2 – NAND dump ... 12

Method ... 12

Extracting the data ... 12

Analysing the data ... 14

Results ... 15

Experiment 1 – Network capture ... 15

Experiment 2 – NAND dump ... 16

NAND ... 16

0000000000000001 ... 17

8000000000000010 ... 17

(8)

vi

80000000000000A1 & A2 ... 18

80000000000000D1 ... 18

80000000000000F0 ... 19

8000000000001060 ... 20

USER Partition ... 21

SD Card ... 23

Discussion ... 27

Ethical aspects ... 28

The result compared with current research ... 28

Further work... 29

Conclusion ... 31

Table of Figures ... 33 References ... I Appendix A. Experiment 1: Network Capture ... A-1 Appendix B. Experiment 2: NAND ... B-1 Appendix C. Notes Analysis ... C-1 Appendix D. Crash Log ... D-1 Appendix E. Python Script Parsing Playevent.dat ... E-1

(9)

1

Introduction

A Switch is a gaming console developed by Nintendo Co., Ltd. It was released in 2017, and it is a hybrid stationary and portable device, meaning that it is possible to use on its own with its touch screen, but also to put it in a docking station to play games on a television screen. The portability of the console is an excellent thing from a forensic position because it connects to many different networks and screens, which all leave behind traces on the console itself and other devices such as the routers and televisions.

Figure 1 A Nintendo Switch in Handheld Mode

Background

We learned from a previous project that it is possible to extract the entire 32GB flash memory from the console by exploiting a hardware vulnerability on the CPU and loading a custom bootloader (van den Berg & de Oliveira, 2019). The exploit and vulnerability are referred to as Fusée Gelée by the community (Temkin, 2018). The exploit and vulnerability are described in more detail in the literature review chapter.

The console also has support for micro SD cards which are much easier to extract the data from, because the data is stored on an easily removable storage media, so the data is immediately available after plugging the SD card into any computer. The data can then be extracted using a forensic data extraction tool. Due to time

constraints, we could not do any in-depth analysis of the extracted NAND-dump and SD card image in the previous study - NAND refers to the console’s flash memory, the result of extracting this memory is referred to as a NAND-dump. This research is aiming to build upon the previous project by analysing the NAND to find more or better potential evidence and verifying this output as well.

The project concluded that there is much useful information available on the console by extracting the memory using the exploit. However, because it was not possible to in-depth with the research, it lacks in detail and methodology. This research aims to expand the previous work by doing an in-depth analysis of both the SD card and NAND filesystem, as well as analysing network traffic.

Purpose

The forensic procedures of a Nintendo Switch have not been adequately

documented before, or at not least easily accessible. This paper is a step in the direction towards the goal of well documented and clear documentation on how to approach a forensic investigation of the Nintendo Switch.

(10)

2

Problem

The problem can be summarized into three research questions. The goal of the research is to extract information from different sources to then analyse this data and determine whether it is useful in a forensic investigation:

- Is there any forensically relevant information that can be acquired by using the Fusée Gelée exploit on the Nintendo Switch, that cannot otherwise be

acquired by using manual extraction

- Is there any forensically relevant information that can be acquired by

examining the contents of the SD card of the Switch, that cannot otherwise be acquired by using manual extraction?

- Is there any forensically relevant information that can be acquired by

capturing the Switch’s network traffic, that cannot otherwise be acquired by using manual extraction?

Problematization

Forensically relevant is an abstract and subjective term, but it does cover the goal of the research. What is relevant in one case might be useless in another. What is meant by forensically relevant in this case is any information that might be useful in a given, hypothetical investigation. Information that is always the same such as file and partition names, the operating system itself and random, useless data is unlikely to be forensically relevant. Information about a user such as personally identifiable information, timestamps and Wi-Fi settings are likely to be forensically relevant. The reason the term forensically relevant was chosen is that we needed a definition of what data is going to be presented. Presenting all data would be unnecessary and probably confusing.

Limitations

We are only going to do a forensic data extraction on the original Nintendo Switch model, not on the Nintendo Switch Lite. Although some of the data extractions methods used apply to the Lite model of the Nintendo Switch as well. Some of the extraction methods are only applicable to a limited number of copies of the unit, manufactured before June 2018 (Osborne, 2018). In the beginning of August the same year, an article published by the Business insider, state that Nintendo Co., Ltd has sold almost 20 million Nintendo Switch consoles (Gilbert, 2018).

The firmware version that is used is version 9.2.0, which is the latest version as of the time of writing. Other versions are out of scope. Using the current version is the most realistic scenario for future investigations. It is unlikely to find older firmware versions during investigations, because Nintendo Co., Ltd sometimes forces people to update their firmware to continue play certain games. The Fusée Gelée exploit works on any firmware version. There is currently no known software vulnerability on the latest firmware version. The last software version that had a known vulnerability and exploit is version 7.0.1 (GBATemp, 2019), which allowed for full system access.

(11)

3

This version is more than a year old as of the time of writing (Noren, 2019) and is therefore not relevant anymore.

From the literature review, it has been concluded that Random Access Memory (RAM) extraction outside of a game is not possible with the currently available tools.

There are some tools available such as NSwitchDebugger (Type_O_Dev, 2018) and Nintendo Switch Memory Explorer (perillamint, 2018) that have RAM editing

capabilities. However, these are not useful here due to their focus on game editing.

Even if there was a tool available for RAM extraction of the entire system, it must already be installed on the target system as the Fusée Gelée exploit requires a reboot of the system which removes the contents of RAM.

We are only going to use vulnerabilities found in the actual gaming console itself, and not in any other software or hardware addon—for example, a game or

attachment to the console. We are also limiting ourselves to only extract data from the console and not from any games. This information is highly dependent on the installed games, and the information is most likely not relevant enough in a forensic investigation.

(12)

4 This page has intentionally been left blank

(13)

5

Literature Review

The reason why similar work on other gaming consoles from the same manufacturer could be interesting is that it might be similarities between different consoles. In how they are built or how the software is designed, to work. Different features and

functions.

Related work

There has been previous work similar to this one but on other gaming consoles where researchers have done forensic analysis on other gaming consoles manufactured by Nintendo Co., Ltd. One example is “Forensic Analysis of the Nintendo Wii U” (van Dijk & Geist, 2016) where they also used an exploit to extract the memory as well as the RAM of a Nintendo Wii U. From the extracted RAM they were able to extract the browsing history of another user on the Wii U, than they were logged in as. This browsing history was not accessible from the GUI for the correct user.

Another related study is about a forensic investigation of the Nintendo Wii (Stewart, 2010). This study provides a very comprehensive overview of the Nintendo Wii for forensic purposes, and it goes over different methods of NAND extraction, including using software exploits, hardware tools and extraction via JTAG. Stewart

disassembled a Wii console and did experiments for most of the methods, this with varied results. He also analysed the NAND at the end of his research and showed that recently sent and received messages, saved contacts, internet bookmarks, web browsing history and many more items could be found.

It is worth noting that the authors of this paper have not been able to find any academic papers about the forensic analysis of a Nintendo Switch. However, there has been much research about this topic, mainly by the Switch hacking community to develop exploits and homebrew applications.

Ways of extracting data

The National Institute of Standards and Technology has a publication called Guidelines on Mobile Device Forensics. (Ayers, Brothers, & Jansen, 2014) Where they describe five (5) different ways of extracting data for forensic analysis

(Lagerholm & Roos, 2019). They are as follows:

• Manual Extraction

• Logical Extraction

• Hex Dumping / JTAG (JointTest Action Group)

• Chip-off

• Micro Read

Manual extraction is when a forensic analyst is manually navigating the device via its interface and documenting the output of the device, often the one on the screen.

Logical extraction. Software on a computer is used to extract data from the mobile device, often via a USB cable, RS-232 or wirelessly via Bluetooth or another wireless interface.

(14)

6

Hex Dumping / JTAG (Joint Test Action Group) This technique also uses a computer to connect to the mobile device, often via a cable directly to the JTAG interface on the chip in mobile devices. This gives logical access to the filesystem, on a lower level than the previous method. Hex dumping is performed by uploading a custom boot loader, that does a hex dump of the device and sends it back to the computer.

Chip-off is when the flash memory is removed from the device, and the data is read straight from the chip. This is the mobile forensic equivalent of doing a physical image of a hard drive in traditional digital forensics. JTAG is more common than this method.

Micro read, this is almost as low level as it gets. The technique is using an electron microscope to observe the physical states of the gates in a NOR or NAND chip. To get something useful of this, the structure of the chip first needs to be completely reverse engineered, and then a copy of the data can be created (Lagerholm & Roos, 2019).

There is no password protection to access the console, so anyone with physical access can use a vast amount of functions on the Switch. The only exception is the optional password protection of the Nintendo eShop which is disabled for the

experiment. Manual extraction is possible because of this. The system’s regular input devices, such as controllers and its touch screen, is used to navigate the

system. All possible useful information that is outputted to the screen is documented.

Fusée Gelée vulnerability

The vulnerability that will be exploited has been named Fusée Gelée by the

community, which is how it will be referred to here. It is a vulnerability in the Switch’s System on a Chip made by NVIDIA, that allows for full unauthenticated arbitrary code execution (Temkin, 2018). What this allows us to do is to load up a custom bootloader, which can then run custom firmware. Normally this is used for example for homebrew applications or playing illegally downloaded games, but in this case the bootloader will allow us to make a memory image.

To exploit the vulnerability, the Switch must first be set into recovery mode, also called RCM. RCM is achieved by connecting the console to a computer, holding down pins one and ten on the right side of the console where the controller normally slides in and then holding down the volume up button and the power button at the same time. Holding down the pins is done using a so-called jig, a plastic piece with metal contacts on the sides that slide down the rail of the console. Using a program called TegraRCM, it is then possible to inject a payload such as a bootloader or a key dumping program. Some payloads also require some additional files to be installed on a micro SD card (Team AtlasNX , 2019).

(15)

7

Method

This chapter explains what methods are going to be used to answer the problems stated in the Introduction section of the paper.

The work is split in two separate experiments. To answer the first question, a custom bootloader will be used to dump the internal NAND memory to a micro SD card. The bootloader Hekate has been chosen for this experiment, because it contains all the needed functionality and is compatible with the latest firmware version (CTCaer, 2020). The most important functionality is NAND acquisition. From the image of the memory it is possible to extract information such as all recently connected displays, recent game history, crash dumps, saved games and more. To do this, the Fusée Gelée vulnerability must first be exploited.

This exploit only works on systems sold before June 2018. It is possible to check whether a system is vulnerable to the exploit by looking at its serial number. It was determined that the system that will be used in the experiment is vulnerable to Fusée Gelée by comparing its serial number to a public list of known vulnerable serial

numbers (Is My Switch Patched?, sd).

In order to develop a method for this experiment, the evidence (which will be the result) must adhere to some requirements. Firstly, in order to acquire forensically sound evidence, evidence integrity must be preserved. This means that evidence must be reserved in its original form, without any changes. Any necessary changes must be well motivated, explained and researched. Evidence integrity needs to be protected in order for it to be admissible in a court of law (Shah, Saleem, & and Zulqarnain, 2017). Information such as system time, software versions, battery percentage, internet settings and more will be collected to provide corroboration that the evidence is accurate. The hashing functionality of bootloader Hekate will also be used to verify the integrity of the image.

Secondly, the output must be representative of an actual use case. That is why we will be using an account on a Switch that has been actively used for several years.

Finally, it must be presented in a way that is easy to analyse. For this reason, a second image will be made before the experiment for comparison.

From the previous project (van den Berg & de Oliveira, 2019) we learned that crash logs contain a lot of useful information. A reliable way to generate a crash log is to remove the game cartridge while the game is running. Crash logs are stored in plain text under settings, which is how this method was verified. A hypothesis is that in order for crash logs to be sent over the internet, the option ‘share error information’

must be turned on. The user interface shows the ten most recent crash logs, the NAND dump might contain more than just these ten logs. Both of these hypotheses will be verified.

(16)

8

Tools, software and hardware used

Here follows a list of all the significant tools, software and hardware used to perform the experiments and analyse the results.

To be analysed Switch

- Nintendo Switch - Firmware version 9.2.0

- Serial number XAJ400026xxxx Screen

Noting the brand of the television screen to potentially find it in future evidence.

- Brand: Sharp

To perform the experiments Computer

- Windows 10 Home - Version: 1903

- Intel Core i5-6300HQ @ 2.3 GHz

- 8GB RAM

Payload Loader

Used to insert the payloads into the console using the exploit. Both the bootloader and the key dumper need to be inserted using this program.

- TegraRcmGUI version 2.6

- https://github.com/eliboa/TegraRcmGUI/releases Bootloader

This is the graphical user interface on the Switch after inserting it using the loader. Normally it is used to load custom firmware but during the experiment it will be used to dump the NAND memory.

- Hekate version 5.1.3

- https://github.com/CTCaer/hekate/releases Key Dumper

Encryption keys are needed to decrypt the extracted NAND. This payload is used to dump these keys.

- BisKeyDump version 9

- https://github.com/rajkosto/biskeydump Network Capturing Software

Wireshark will be used to capture and save the information going to and from the console.

- Wireshark version 3.2.1 - https://www.wireshark.org/

(17)

9 For analysing the results

Computer

• Windows 10 Home

• Version: 1903

• Intel Core i5-6300HQ @ 2.3 GHz

• 8GB RAM

Forensic Analysis Tools

This is used to quickly find information about the console using user-made scripts.

- The Sleuth Kit’s Autopsy Version 4.14.0 - https://www.sleuthkit.org/autopsy/

- Nintendo Switch Autopsy Scripts

- https://github.com/modux/Nintendo-Switch-Forensics Forensic Imaging Tool

FTK Imager will be used to make an image of the SD card.

- FTK Imager Version 4.2.1.4

- https://accessdata.com/product-download Switch Filesystem Mounting and Decrypting

After obtaining both the NAND dump and the encryption keys, a tool is needed to decrypt the content of the dump using these keys and to mount it on a local machine.

- HacDiskMount Version 1055 - https://switchtools.sshnuke.net/

Network Capturing and Analysing Software

Wireshark will be used to analyse the captured network traffic going to and from the console.

- Wireshark Version 3.2.1 - https://www.wireshark.org/

Switch Filesystem Analysis Tool

A specific tool is needed to unpack the files in the filesystem and to read metadata about these files.

- HacToolNet Version 0.10.0

- https://github.com/Thealexbarney/LibHac/releases Reading the Log File

A script is needed to parse the log file playevent.dat (for more details, see results chapter).

- PlayEvent.py

- https://gist.github.com/garoxas/012111ee0860dc68496603eb566dda55

(18)

10 Reading msgpack Files

The Switch uses the msgpack format to store certain data (see results chapter for more details). A script must be used to convert this to readable data.

- Msgpack2json

- https://github.com/ludocode/msgpack-tools Hex Editor

Some data can easiest be read using a hex editor.

- HxD version 2.3.0.0

- https://mh-nexus.de/en/hxd/

Experiments

This chapter is going to explain how the two experiments are going to be executed, and which steps are going to be taken to make sure that the findings can be

analysed.

1 – Network capture

This experiment is going to make capture of the Nintendo Switch’s network traffic, while doing pre-determined actions. For example, it will be capturing during the bootup, when checking for updates, entering the eShop and starting a game. The exact timestamp of every action should be noted in the report to later determine which action causes which network activity.

The topology of the network capture setup is as follows:

Figure 2, Topology of network for traffic capture

The Nintendo Switch is docked in its docking station and it has an ethernet cable connected to it via a USB to ethernet adapter. The other end of the cable is connected to a network card on a computer (marked as eth1 in Figure 1). This network card is then bridged with another network card (eth0) on the computer, that is then connected to the router, which is connected to the internet. In this

configuration the computer is able to listen to and record the network traffic to and from the Nintendo Switch.

The software that is being used to capture the traffic is Wireshark version 3.2.1.

(19)

11 Method

Before every step, the time was documented so it is possible to match the

timestamps in the packet capture and corresponding traffic with the actions taken on the Switch.

Recording the data Step by step plan:

1. Connect the Switch to the computer.

2. Turn on the console

3. Go to settings and note the internet configuration (IP, MAC address etc.)

Figure 3 Network information

4. Under the same tab, perform a connection test

5. Go to User, <username>, check account information and log in to view e-mail

address

6. Go to system, date and time and open disable synchronise clock over internet, then enable it again.

7. Go to ‘News’ and open a random news article, return to main menu 8. Go to ‘Nintendo eShop’, choose user

9. Open the default user’s page (top right main menu) 10. Open every tab on the left and scroll through them 11. Open a game with online multiplayer capabilities

12. Let the game load to where it will get data from the internet, return to main menu

Figure 4 User settings

(20)

12

13. Open another game with online capabilities

14. Let the game load to where it will get data from the internet, return to main menu

15. Open a game without any online capabilities, return to main menu 16. Turn off the console

Analysing the data

To analyse the captured network traffic, Wireshark version 3.2.1 is used.

The analysis was done by hand, looking at the unencrypted data to see which information is possible to extract. Looking at the timestamps and in the step by step plan for the experiment to see what actions were taken to generate the network traffic from the Switch at that certain time. This was done for all the steps in the plan.

2 – NAND dump

This experiment will capture the contents of the NAND memory of some pre- determined actions. To determine what the impact of these actions have on the NAND, an image must be taken before and after the experiment. Both the NAND and the contents of the SD card will be tested using this logical data extraction method.

The prerequisites are that the console must be connected to the internet, the option

‘share error information’ must be turned on and the BIS keys must be obtained beforehand. These BIS keys are encryption keys that are used to decrypt the NAND.

Obtaining the keys can be done by using the bis key dump payload in TegraRCM.

Method

Extracting the data Step by step plan:

1. Put the console in RCM mode, then use TegraRCM to load the Hekate payload

2. Use Hekate to make a full eMMC RAW GPP backup, verify the hash

(21)

13

Figure 5 Hekate running on a Nintendo Switch

3. Insert the SD card in a computer and use FTK imager to make an image of the SD card, verify the hash.

4. Insert the SD card back into the console and turn it on

5. Write down the system time and battery percentage (top right) 6. Go to settings and write down / screenshot the following values:

Under support: error history (all details of the first and last crash logs)

Flight mode (on/off)

Internet configuration

Test Network connection

Users and user settings

Data management, list of software and when it was last played

Sleep mode settings

Under system: current system version, console nickname, date, serial numbers, automatic software updates (on/off), share error information (on/off).

7. Open the game Splatoon 2, choose user ‘jelluh24’

8. Join an online match.

9. When the match has started, note all the players that are in the current match 10. Remove the game cartridge to generate an error report, make a screenshot of

this using the built-in screenshot button.

(22)

14

Figure 6 Error log in the GUI

11. Go to account and write down all the information 12. Go to ‘news’ and open a random news article 13. Go to Nintendo eShop, choose user ‘jelluh24’

14. Choose the icon in the top right to go to user information, write down:

Current balance

Current points

Credit card data

Paypal account

Payment method for recurring payments

Password settings

Main system

15. Open a random game page

16. Go back to the main menu and open Album. Write down total number of screenshots and videos.

17. Write down the current time on the console

18. Turn the console completely off (hold down the power button), then turn it back on again

19. Put the console into sleep mode and immediately unlock it again.

20. Write down the console time

21. Turn the console off for exploitation.

22. Use Hekate to make a full eMMC RAW GPP backup

23. Copy the dump file from the SD card to a computer and delete the files on the SD card

24. Use FTK imager to make an image of the SD card Analysing the data

The combined result of both experiments will be a pcap file, two SD card images, before and after, two NAND images, before and after. Network and memory analysis require different methods.

The before and after images will be compared using Kdiff3. Any information that has changed could be traced back to the actions taken during the experiment and is potentially forensically relevant. Another method of analysis is using public knowledge of interesting files such as Nintendo Switch Autopsy scripts (Modux, 2019) and the Switchbrew wiki pages (Switchbrew, 2020).

See also the list of software used at the start of this chapter.

(23)

15

Results

Both experiments were executed successfully on the 29th of March 2020. The only thing that did not go as expected is the fact that removing the game cartridge while it was running did not generate a crash report. It generated a different error message than in an earlier test. The hypothesis is that this is because the cartridge was removed at a different time while the game was running. It was decided not to investigate this further and to continue the experiment without a crash log due to time constraints. The reports of the experiments can be found in appendix 1 for the network capture, and appendix 2 for the NAND.

Experiment 1 – Network capture

Traffic in the network capture is for the most part encrypted with Transport Layer Security (TLS encryption). The non-encrypted traffic was mostly using the following two protocols: Domain Name Service (DNS) and Address resolution protocol (ARP).

One attempt to break the TLS encryption was made, but unfortunately with no luck In a forensic perspective this did not give a lot of valuable information especially because the user of the Nintendo Switch could not use it to browse the web. It might have been valuable traffic in a reverse engineering perspective, but that is out of the scope for this report.

It was possible to see the destination IP-addresses of the traffic, which led to Nintendo Co., Ltd and Amazon Web Services, Inc.

At the second step in the step by step plan in the experiment, the console is powered on. The first thing it does is a HTTP 1.1 GET / request to ctest.cdn.nintendo.net and if it has an internet connection, it will get a response just containing ok. This

One finding that is not very relevant but still might could come in handy in cloud forensics, is that the Switch connected to www.google-analytics.com and to

stats.g.doubleclick.net. Because the Switch can be connected to a Google account, (see experiment 2) it might be possible to extract some data about the Switch or about how it has been used from Googles cloud.

The third research question says:

“Is there any forensically relevant information that can be acquired by capturing the Switch’s network traffic, that cannot otherwise be acquired by using manual extraction?”

When navigating the user interface, it is not very clear that the Switch is using Google analytics for targeted ads, but it exists an option to turn it off. The analytic function is documented in their privacy policy but not that they use google analytics (Nintendo Co., Ltd, 2019).

This information itself is not interesting for a forensic investigation, but it might lead to some interesting information, if the analytic function has been turned on, and data been sent to google.

(24)

16

Experiment 2 – NAND dump NAND

Data on the NAND dumps was analysed by going through every file on every

partition to answer the research question. This chapter focuses on the most relevant files. Documentation of other files can be found in appendix 3.

When mounted using HacDiskMount, you can see that the filesystem consists of the following partitions:

PRODINFO

PRODINFOF

BCPKG2-1-Normal-Main

BCPKG2-2-Normal-Sub

BCPKG2-3-SafeMode-Main

BCPKG2-4-SafeMode-Sub

BCPKG2-5-Repair-Main

BCPKG2-6-Repair-Sub

SAFE

SYSTEM

USER

Some of these partitions are encrypted (namely PRODINFO, PRODINFOF, SAFE, SYSTEM and USER) using AES-XTS (Switchbrew, 2020). The encryption keys necessary to decrypt these partitions were already extracted using biskeydump.

Every partition has its own file system. For example, the SAFE, NORMAL and USER partitions use FAT32 and PRODINFO is a binary file (Switchbrew, 2020).

The PRODINFO partition is a calibration file that is created during the initial setup of the console (Switchbrew, 2020). This was verified by comparing the file from before the experiment to the file after the experiment. They are the same. The file contains information such as the Switch’s MAC address, serial number and battery ID. It also contains an RSA key and certificate. We tried applying these files to the network capture of the other experiment to decrypt the traffic, but with no success. Failing to decrypt the traffic likely happens because decrypting SSL (TLS) is not commonly used anymore due to Perfect Forwarding Encryption. A one-time key is generated and stored in RAM, which is then required to decrypt TLS packets (Phillips, 2018).

Furthermore, it is unclear for what traffic this certificate is used. In practice, it was used by people to download content from Nintendo’s content distribution network (SimonMKWii, 2018).

The PRODINFOF partition is a FAT12 filesystem that contains logs of the system calibration. The BCPKG2 partitions contain system boot configuration files

(Switchbrew, 2020). None of these partitions contain anything of significance. It is unclear what the function of the SAFE partition is. There is no documentation available, and the file is not human readable.

The SYSTEM partition, however, is very interesting from a forensic perspective, because it contains save data of system applications. It also contains the raw system applications themselves, but those are going to be ignored since they are always the

(25)

17

same. The save directory contains the save data. Each file in this folder consists of one or more “hidden” files. The files that contain other files will be referred to as folders. The hidden files can be extracted using HacToolNet (Thealexbarney, 2020).

The following files are of interest:

0000000000000001

This folder contains several files. One of these files is history.bin, which contains the last hundred users a user has played with online. Every player that was in the

Splatoon 2 match during the experiment can be found back here. The format this file is in is unfortunately not very readable, but every line in this file contains a username and then the username of the console user. It does not contain any timestamps, so this only proves that a specific user has played with another user at some point.

The file friend.cache contains usernames of all friends and their profile pictures.

The file setting.cache contains the user’s friend code, username and profile picture.

The information in these last two files is already available on the user interface; the information in history.bin is not.

8000000000000010

Every user registered on the system has an account ID. In this folder, the information is saved in the format accountID_user.json. It contains the following information:

Figure 7 The content of the file accountID_user.json

The user’s birthday, id, gender, email address, analytics preferences and if their Google account is linked was not found using manual extraction. A user’s screen name, the censored version of their email address, is shown on the console.

However, it is impossible to see their full email address without logging in to their Nintendo account or using the NAND extraction method.

8000000000000010 also includes a token for each user, but it is unclear what the purpose of this token is.

(26)

18 80000000000000A1 & A2

Both of these folders contain a lot of .msgpack.lz4 files. Msgpack is similar to json, but -as the creators put it themselves- fast and small (MessagePack, sd). Lz4 is a fast, lossless compression algorithm (lz4, 2020). One would assume that these files are therefore lz4 compressed msgpack files, but when trying to decompress these files, lz4 outputs “Error 44 : Unrecognised header : file cannot be decoded”. When comparing the header of these lz4 files to the header of a typical lz4 file, it is entirely different. This could mean that they are either not lz4 files or that Nintendo uses a custom implementation of the lz4 format. Despite not being able to decompress the files, there is still much readable information available. The problem, however, is that the values are not readily readable without any decompression.

There are some readable strings but making sense out of this is complicated and unreliable. The UTC timestamp takes place during the experiment, however. We can conclude that something happened at this time, but what exactly is too vague. Until these files can be decompressed, it is too unreliable to conclude anything about the contents of these files.

The file current.msgpack is not compressed and exists in A1 and A2. It is the same file in both. This file contains the following information after the experiment:

Figure 8 The content in the file current.msgpack

The shutdown timestamp and date are accurate with the time the console was last shut down before imaging but offset by two hours. We can conclude that these timestamps are in UTC since the console time zone is set to CEST, which is two hours ahead of UTC.

80000000000000D1

Contains crash logs which are serialised using msgpack. This time they are not compressed so they can easily be converted to JSON and read. They contain a lot of useful information that presumably gets send to Nintendo Co., Ltd to debug their application. In this case, this is extremely interesting because it contains much information that cannot be obtained by simply looking at the user interface. Even when comparing the output of these files to the error history on the Switch, there is a lot more information available. Only the last ten crash dumps are shown on the Switch, but there are fifty crash log files both before and after the experiment.

(27)

19

What type of information is shown sometimes depends on what caused the error.

For example, when there is a network error, it shows certificate information.

However, with a game crash, it might not show that and shows other information such as the value “GameCardRemovalCount”. The following values are generally the most relevant. A full overview in the form of a sample crash log is provided in

appendix 4.

- Monitor information such as: monitor manufacturer, product code, serial number, manufacture year, refresh rate and resolution

- Battery information such as: charging on or off and battery percentage.

- History information such as: focused applet history which shows ids of recently opened applications.

- Currently opened application title, ID, version and where it is stored.

- Internet information such as: SSID, security type, channel, IP, MAC address, subnet mask, DNS servers, gateway IP, proxy information,

- Timestamps, both system and internet time in epoch time format. Also includes elapsed time since power on, last awake and last launch.

The latter timestamps are most likely in milliseconds since these values range from tens of thousands to tens of millions.

The values NetworkClockContextOffset, NetworkClockContextTimeStampValue, UserClockContextOffset and UserClockContextTimeStampValue seem to be in epoch time, but they are inaccurate since they have times from 1972. To get accurate timestamps, use the OccurenceTimestamp or OccurenceTImestampNet values. The log also includes whether NTP is enabled, which might help with determining which one of the two values to use.

80000000000000F0

This folder contains playevent.dat, which is one of the most useful files for forensic purposes. It is a log file that records the following actions:

Launching an app

Exiting an app

Application out of focus (going to main menu)

Application in focus

Power state change

Operation mode change (refers to handheld or docked mode) Every entry contains the following:

Application ID

User ID

Time

Date

(28)

20 (Switchbrew, libnx, 2019)

The problem with this file, however, is that it is complicated to read. There is some documentation available about this file, but it is very complicated. There is a Python script available online that parses this file (Garoxas, 2019). However, this script was found to be incomplete. There are five event types:

0 – Applet 1 – Account

2 – PowerStateChange 3 – OperationModeChange 4 – Initialise

This script only parses the event type Applet. The following line can be added to parse events of type 2:

If event_type == 2:

print(timestamp)

This line outputs a lot of extra data that was not available in the first output. It confirms that not all data is being parsed. It is out of the scope of this research to improve this code, but we edited the code with the above piece of code for each event type with an indicator of which event type it is. The updated code can be found in appendix 5. The code does not provide all the available information, but it gives a more complete view of the data. For example, if the event type is 2, then it means that the console was either turned on or off. By looking at the context, it makes sense which one the two it is. The timestamps were verified by comparing it to the experiment results, and they were determined to be accurate to the second—this time, the timestamps are not in UTC but in the local console time.

PlayEvent.dat proves to be extremely useful for forensic purposes because the file records timestamps of actions since the initial setup of the console.

8000000000001060

This folder contains files that make up the HTTP cache.

Cache.fat is the primary cache file which contains much useful information. Each line in this file contains the cached URL, then its HTTP content type (for example

application/javascript and image/jpeg), the corresponding .dcf file and a UTC

timestamp. The dcf files are the cached content itself, so this could, for example, be a javascript file, a jpg image or a text file. For image files, you can simply change the extension to .jpg to open them.

The problem with the cache.fat file is that it is seemingly random what data is cached and when. There is no timestamp present from during the experiment, so it is

impossible to determine whether the data is accurate. This file does not prove with a hundred per cent certainty whether someone was using the console at the time of the HTTP cache timestamp.

(29)

21

The cache mainly contains data from the Nintendo eShop, since the console does not have a traditional web browser.

USER Partition

The USER partition contains all data that is not system-specific, for example, game saves and the raw game application files. (Switchbrew, 2020)

The following is the structure of this partition:

Figure 9 File structure of the USER partition (Switchbrew, 2020)

Over every file or folder in this partition, only one file was changed during the experiment. Presumably, this is the Splatoon 2 save data, because this is the only non-system application that was opened during the experiment. The only folder that was changed is ‘000000000000000f’ in the save directory. Opening it with hactoolnet (using the command hactoolnet -t save -k prod.keys --outdir <outdir>

path/to/000000000000000f) the file save.dat gets extracted. This file is not human- readable. However, hactoolnet outputs some interesting information using the same command:

Figure 10 Output from hactoolnet

The title ID is the ID for Splatoon 2 (Switchbrew, Title list/Games, 2019), which is the only game that was launched during the experiment. The timestamp also matches up with the time of the experiment. This time is most likely the last time the game was saved. For a game to save it must at the very least be open in the foreground, so this is good evidence that somebody was playing the game at this time.

The contents folder contains .nca files, which are the raw non-system applications (e.g. games). The following NCAs were found on the USER partition using the – listtitles options with the switchfs content-type:

(30)

22

Figure 11 NCAs found on USER partition

Note that these are not all games that are installed on the system, only the games that are installed on the internal memory.

Using the listncas option, it is possible to see all the NCA files. Every title appears to have three to five NCAs with different types: Program, Meta, Control, Manual and PublicData. Inspecting a random title by using the command “hactoolnet.exe -t switchfs -k prod.keys --title 01002B30028F6000 --outdir <outdir>

NAND\USER” outputs four files

These files can be decrypted using the plaintext option. The decrypted data does not give much more information. The most important piece of information that can be extracted with this method is whether it was downloaded from the eShop or if it was installed using a cartridge. Other information is the actual application itself, which is always the same, so not forensically relevant:

Figure 12 Output files from hactoolnet

(31)

23

Figure 13 The content of one of the .nca files

It is unclear what information the savemeta folder contains. Hacdiskmount is not able to read the .meta files, and there is no information available online. The Album

directory has the same structure as the Album directory on the SD card, which is discussed in the next chapter. The temp directory is empty.

SD Card

The structure of the SD card is as follows:

Figure 14 File structure of the SD card (Switchbrew, SD Filesystem, 2020)

The only file that has changed during the experiment is the private1 file in /Nintendo, which stores 0x20 bytes with the last 0x10 being random (Switchbrew, SD

Filesystem, 2020). The fact that only one file was changed means that all files are the same before and after the experiment, most likely because the only game that was opened is stored on the console itself and not the SD card.

(32)

24

The structure of the album folder is the same as on the USER partition on the main NAND. The Switch has a build-in screenshot and recording function. By pressing a button on the controller a screenshot can be made, holding down this button

captures the last thirty seconds in mp4 format. The folders inside the album directory are structured by year, month and day. For example:

The screenshot filenames start with the date and time in the following format:

YYYYMMDDHHMMSS. There are then two numbers that are used when two screenshots are made in the same second, this is usually two zeroes (Switchbrew, Capture Services AlbumFileDateTime, 2020). It is then followed by a dash and a title-unique hex ID.

The timestamp is in the local time of the console and appears to be accurate. For example, the first screenshot during the

experiment was taken at 16:10, its filename is

“2020032916101100-57B4628D2267231D57E0FC1078C0596D.jpg”. The same format is used for video files, but with a .mp4 extension. Using exiftool to examine its metadata, this timestamp can be confirmed:

Figure 15 File structure of pictures and videos

(33)

25

Figure 16 Metadata about 2020032916101100-57B4628D2267231D57E0FC1078C0596D.jpg

The modify date value has the same date and time as the filename.

Moving on to the contents folder. The NCA files that are saved to the SD card are saved here. It is not possible to extract these in the same way as from the USER partition. Instead of using the encryption keys, a so-called SD seed is required. The SD seed can be found in the folder called private in 8000000000000043 on the SYSTEM partition. There are tutorials available on how to extract the NCA files using this SD seed, for example: (khang06, 2018). In the previous chapter we, however, learned that this does not give much relevant information. The SD seed is extracted from the SYSTEM partition, which also means that an exploited Switch is required.

All information these NCA files give can already be found by using much easier methods on an exploited console.

The save folder contains five files. These files also require the SD seed to decrypt.

The researchers ran into a problem where hactoolnet does not recognise the SD seed. The error for both NCA and save files is that the header is not valid.

Unfortunately, it is not possible to read these files because of this.

(34)

26 This page has intentionally been left blank

(35)

27

Discussion

There is a surprising amount of useful information to be found by simply examining the user interface. From for example network information, the approximate amount of time a user has played a certain game to the last ten crash logs which include

timestamps and system information at the time of the crash. This information alone could constitute investigating a suspect’s Switch. Combined with the lack of a password functionality to hide this information makes the console an interesting piece of evidence.

The various timestamps in different log files on the console can strengthen the fact that the console was in use at a specific moment or not. This can both be used against someone in court as well as defending one’s self. Some timestamps are more trustworthy than others, however. For example, the file name and EXIF data of screenshots on the SD card can easily be modified, whereas this is more difficult with the playevent.dat file. Editing save files is popular in the Switch modding

community (mostly for cheating), so modified files are not unheard of. However, the chance that somebody would go out of their way to edit or remove files is most likely very low.

Another problem with this kind of evidence is that it is required to exploit the Fusée Gelée vulnerability in order to acquire a NAND image. As mentioned before, this vulnerability only works on consoles sold before June 2018, as hardware after this date patches this vulnerability. For now, in 2020, it is not uncommon to have one of these older consoles. However, these consoles will become more and more sparse over the coming years, partly because they are in great demand due to their ability to be exploited (which makes playing illegally downloaded games possible).

Even when using the exploit is impossible, we still think that the Switch can serve as a supporting piece of evidence in some cases. For example, crash logs and

screenshots contain timestamps and all previously connected to Wi-Fi networks are stored on the console. The problem with these timestamps is that you must be

“lucky” that you took a screenshot at a certain time or had a game crash for the console to register it. This should not be the main piece of evidence since it is so unreliable.

One limitation we introduced at the start of the research is that we are only using firmware version 9.2.0, which was the latest version at the time. Now, a couple of months later, there have been two new firmware versions. Both introduced some new features, but also some changes in the memory. We suspect that the basic structure of the filesystem will stay the same, because it has not changed much historically. Some things might however be different in future versions, such as file structures or names.

The choice of method, doing experiments, has had a positive impact on the report.

Because there has not been a formal investigation of a Nintendo Switch we had to use unofficial crowd sourced information on forums and GitHub about the Switch’s hardware. The authenticity of this information could later be confirmed by our own findings in the second experiment.

(36)

28

The first experiment gave little to no valuable results. This because almost all traffic was encrypted and our attempt to decrypt the traffic did not succeed. There was some unencrypted traffic and we could get some metadata about the encrypted traffic such as the destination and timestamps, which we could corelate to the actions taken on the Switch at the same time. Despite the unsuccessful result, we still think this can give some insight in how a Switch makes it present on a network, and what services it shares data to. From a privacy perspective this might be interesting, but from a forensic perspective this is mostly useless.

Ethical aspects

An ethical aspect of the report could be that the exploit we used could inspire people to exploit their Switch to install illegally downloaded games or to cheat in games. We believe that the information about the exploit in the report is not comprehensive enough to be used as basis to perform these kinds of actions.

The result compared with current research

The already existing research in this subject mostly consists of independent persons doing research on their spare time. This is mostly done to break the security to be able to play unofficial games or to run unofficial software on the Switch. At the moment, this is the only scientific paper that does forensic research on the console.

(37)

29

Further work

In order to get the same information out of the NAND in the future, in consoles produced after June 2018, a new exploit is required. Currently, such a vulnerability has not been found so we could not use the same sort of exploit on a newer console.

Further work could include finding a new hardware or software exploit in order to extract the NAND again.

Further investigation on some of the files could also be of interest. For example, Playevent.dat is currentlly difficult to parse, further work could include making a script that parses all data from this file. Folders the researches were unable to fully extract are 80000000000000A1 & 80000000000000A2 in the SYSTEM partition.

These appear to be lz4 compressed files, but using the standard lz4 library for decompression seems to be impossible. Further research is required here.

For any file it is entirely possible that useful information has been missed during the research due to human error or the lack of some specific knowledge. Trying to reproduce the experiment is encouraged.

(38)

30 This page has intentionally been left blank

References

Related documents

A study of rental flat companies in Gothenburg where undertaken in order to see if the current economic climate is taken into account when they make investment

Object A is an example of how designing for effort in everyday products can create space to design for an stimulating environment, both in action and understanding, in an engaging and

Respondenterna beskrev att information från HR-verksamheten centralt som förs vidare från personalcheferna på personalgruppsmötena ut till förvaltningarna kanske blir sållad

pedagogue should therefore not be seen as a representative for their native tongue, but just as any other pedagogue but with a special competence. The advantage that these two bi-

While the theoretical possibility to subvert one’s gender role is seen in Katherine when her performative patterns change in the desert, she never breaks free from

The teachers at School 1 as well as School 2 all share the opinion that the advantages with the teacher choosing the literature is that they can see to that the students get books

First of all, we notice that in the Budget this year about 90 to 95- percent of all the reclamation appropriations contained in this bill are for the deyelopment

When Stora Enso analyzed the success factors and what makes employees &#34;long-term healthy&#34; - in contrast to long-term sick - they found that it was all about having a