Master Thesis 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 HALMSTAD UNIVERSITY
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
i
This page has intentionally been left blank
ii
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.
iii
This page has intentionally been left blank
iv
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
v
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
vi
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.
1
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.
2
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.
3
This page has intentionally been left blank
4
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.
5
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).
6
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.
7
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/
8
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
9
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.
10
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,
Figure 4 User settings
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
11
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
12
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.
13
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.
14
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.
15
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
16 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.
17
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.
18
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
19
(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.
20
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
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:
21
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
Figure 12 Output files from hactoolnet 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:
22
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.
23
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
Figure 15 File structure of pictures and videos
“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:
24
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.
25
This page has intentionally been left blank
26
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.
27
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.
28
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.
29
This page has intentionally been left blank
30
Conclusion 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? There is a lot of forensically relevant information available by extracting a NAND image by using the Fusée Gelée exploit. One of the most significant pieces of information comes from the PlayEvent file, which is located in the 80000000000000F0 folder on the SYTEM partition. This is a log file which records most actions of any user, for example launching and exiting an application and turning the console on and off, all including user ID’s and timestamps. This information cannot be found using manual extraction. The second useful folder is 80000000000000D1 which contains msgpack serialized crash logs. The user interface only shows the last ten crash logs, whereas the previous fifty crash logs are readable from the NAND. These crash logs contain information such as timestamps, monitor (screen) information, internet connection information and the application that is currently opened. Another useful folder on the SYSTEM partition is 8000000000000010, which contains the user’s email address among other user information. The full, non- censored email address is only visible here. Information on the other partitions can also be found 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? The SD card contains game save data, game files and optionally screenshots. Save data can theoretically be read by using the SD seed from a file in the main memory. However, the researchers were unable to reproduce this. The screenshots and videos are, however, forensically relevant as they contain a timestamp in the file name and EXIF data by default. No exploit is required to obtain these images and videos. 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? Because most data is encrypted it is not possible to analyse the contents of the packets. Some domain names were found, but this is most likely not very useful in a forensic investigation of an individual console.
31
This page has intentionally been left blank
32
Table of Figures Figure 1 A Nintendo Switch in Handheld Mode ...... 1 Figure 2, Topology of network for traffic capture ...... 10 Figure 3 Network information ...... 11 Figure 4 User settings ...... 11 Figure 5 Hekate running on a Nintendo Switch ...... 13 Figure 6 Error log in the GUI ...... 14 Figure 7 The content of the file accountID_user.json...... 17 Figure 8 The content in the file current.msgpack ...... 18 Figure 9 File structure of the USER partition (Switchbrew, 2020) ...... 21 Figure 10 Output from hactoolnet ...... 21 Figure 11 NCAs found on USER partition ...... 22 Figure 12 Output files from hactoolnet ...... 22 Figure 13 The content of one of the .nca files ...... 23 Figure 14 File structure of the SD card (Switchbrew, SD Filesystem, 2020) ...... 23 Figure 15 File structure of pictures and videos ...... 24 Figure 16 Metadata about 2020032916101100-57B4628D2267231D57E0FC1078C0596D.jpg ...... 25
33
This page has intentionally been left blank
34
References Ayers, R., Brothers, S., & Jansen, W. (2014). Guidelines on Mobile Device Forensics. National Institute of Standards and Technology. Retrieved from https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-101r1.pdf
CTCaer. (2020, March 22). Hekate - CTCaer mod. Retrieved from Github: https://github.com/CTCaer/hekate
Flash Filesystem - Nintendo Switch Brew. (n.d.). Retrieved from switchbrew.org: https://switchbrew.org/wiki/Flash_Filesystem
Garoxas. (2019, October 6). PlayEvent.py. Retrieved from github: https://gist.github.com/garoxas/012111ee0860dc68496603eb566dda55
GBATemp. (2019, August 7). List of Switch's Exploits. Retrieved from GBATemp wiki: https://wiki.gbatemp.net/wiki/List_of_Switch_exploits
Gilbert, B. (2018, August 2). Nintendo is just shy of reaching 20 million Switch consoles sold, but momentum is slowing. Retrieved from BUSINESS INSIDER: https://www.businessinsider.com/nintendo-switch-lifetime-sales-2018-8?r=US&IR=T
Is My Switch Patched? (n.d.). Is My Switch Patched? Retrieved from Is My Switch Patched?: https://ismyswitchpatched.com khang06. (2018, August 16). Switch SD Dumping 101 . Retrieved from Github: https://gist.github.com/khang06/84aabeac507fa99a676d22bb6120cea8
Lagerholm, F., & Roos, A. (2019, October 23). Project - Introduction to digital forensics, Smartphone malware forensics. Unpublished.
Ludocode. (2020, March 12). msgpack-tools. Retrieved from github: https://github.com/ludocode/msgpack-tools lz4. (2020, January). LZ4 - Extremely fast compression. Retrieved from github: https://github.com/lz4/lz4
Martin, C. (2017, Jul 28). New Nintendo 2DS XL news: Release date, price and specs. Retrieved from techadvisor: https://www.techadvisor.co.uk/news/gadget/new-nintendo-2ds-xl-3658421/
MessagePack. (n.d.). MessagePack. Retrieved from MessagePack: https://msgpack.org/
Modux. (2019, June 30). Nintendo-Switch-Forensics. Retrieved from Github: https://github.com/modux/Nintendo-Switch-Forensics
Nintendo Co., Ltd. (2019, 12). Nintendo Privacy Policy. Retrieved from Nintendo: https://www.nintendo.com/privacy-policy/
Noren, K. (2019, February 19). Minor Switch firmware update 7.0.1 out now. Retrieved from GBATemp: https://gbatemp.net/threads/minor-switch-firmware-update-7-0-1-out- now.531731/
Osborne, J. (2018, July 11). Nintendo Switch hardware patch reportedly found in brand new units. Retrieved from Techradar: https://www.techradar.com/news/nintendo-switch-hardware- patch-reportedly-found-in-brand-new-units
I perillamint. (2018, July 1). MemXPlorer. Retrieved from Gitlab: https://gitlab.com/perillamint/nx- memxplorer
Phillips, A. (2018, December 27). SSL Decryption Guide: How to Decrypt SSL with Wireshark. Retrieved from Comparitech: https://www.comparitech.com/net-admin/decrypt-ssl-with- wireshark/
Roussel-Tarbouriec, G. T., Menard, N., True, T., Vi, T., & Reisyukaku. (2019). Methodically Defeating Nintendo Switch Security.
Shah, M. S., Saleem, S., & and Zulqarnain, R. (2017). Protecting Digital Evidence Integrity and Preserving Chain of Custody. Journal of Digital Forensics, Security and Law: Vol. 12 : No. 2 , Article 12.
SimonMKWii. (2018, May 14). CertNXtractionPack - Get your Switch cert from a NAND dump! Retrieved from GBATemp: https://gbatemp.net/threads/certnxtractionpack-get-your- switch-cert-from-a-nand-dump.503844/
Stewart, P. (2010). Forensic Analysis of the Nintendo Wii Game Console . Glasgow.
Switchbrew. (2019, November 12). libnx. Retrieved from Github: https://github.com/switchbrew/libnx/blob/master/nx/include/switch/services/pdm.h#L78
Switchbrew. (2019, November 24). Title list/Games. Retrieved from Switchbrew: https://switchbrew.org/wiki/Title_list/Games
Switchbrew. (2020, March 25). Calibration. Retrieved from Switchbrew: https://switchbrew.org/wiki/Calibration
Switchbrew. (2020, February 19). Capture Services AlbumFileDateTime. Retrieved from Switchbrew: https://switchbrew.org/wiki/Capture_services#AlbumFileDateTime
Switchbrew. (2020, January 11). Flash Filesystem. Retrieved from Switchbrew: https://switchbrew.org/wiki/Flash_Filesystem
Switchbrew. (2020, March 17). SD Filesystem. Retrieved from Switchbrew: https://switchbrew.org/wiki/SD_Filesystem
Team AtlasNX . (2019). Before Starting. Retrieved from Homebrew Guide: https://switch.homebrew.guide/gettingstarted/beforestarting
Temkin, K. (2018, April 22). Vulnerability Disclosure: Fusée Gelée. Retrieved from Github: https://github.com/Qyriad/fusee-launcher/blob/master/report/fusee_gelee.md
Thealexbarney. (2020, April 10). LibHac. Retrieved from Github: https://github.com/Thealexbarney/LibHac
Type_O_Dev. (2018, July 23). How to edit Memory and change in-game values (NSwitchDebugger). Retrieved from GBATemp: https://gbatemp.net/threads/how-to-edit-memory-and-change- in-game-values-nswitchdebugger.512335/ van den Berg, J., & de Oliveira, V. A. (2019). Forensic Analysis of a Nintendo Switch. van Dijk, R., & Geist, D. (2016). Forensic analysis of the Nintendo Wii U. Amsterdam.
II
Appendix A. Experiment 1: Network Capture
Before every step note the time to see what belongs where Step by step plan: 1. Turn on the console a. 20:20 2. Go to settings and note the internet configuration (IP, MAC address etc.) a. 20:21 b. 192.168.137.55 3. Perform a connection test a. 20:21 b. Global ip 83.209.94.211 4. Go to User,
A-1
This page has intentionally been left blank
A-2
Appendix B. Experiment 2: NAND
Computer time: 16:08
Switch time: 16:08 Battery percentage: 28% Connected to Sharp TV docked mode Screenshot taken of error history, all details of first error report and the last two error reports. Latest error report: Error report: 04/03/2020 14:14 Error code: 2002-2520 Software name: Splatoon 2 Second to last error report: Error report: 19/07/2019 23:15 Error code: 2124-8006 Software Name: Youtube Last error report: Error report: 18/07/2019 17:37 Error code: 2110-2004 Sofware name: Super Mario Maker 2
Flight mode: cannot set while the console is connected to a TV Screenshot taken of internet configuration Internet configuration: Connection status: connected via wifi Console mac address
Internet settings, automatically searched for wifi networks. Registered networks: D-Link Netgear-Wifi 5GHz Qualityguest TELE2-E935DF Ziggo193 Kasteelberg Apeldoorn2015 EGA by NETGEAR 2.4 GHz Telia wifi WiFi in de trein
B-1
FRITZ!Box 5490 WI Ziggo5311645 WGW17 Scandic_easy VGV7519CCB2C9
Networks found: Netgear Jas Jas_5GHz Selected manual setup, made no changes.
Selected Test connection Result: Connection name – SSID: D-link Internet connection: success Global IP address: 83.209.94.211 NAT type: A Download Speed: 17.9 Mbps Upload speed: 10.6 Mbps
Selected Data Management Selected Software List of software: Animal crossing: New Horizons Played in the last week 66.6 MB local 6.4 GB SD total 6.5 GB
Splatoon 2 Played in the last week
Pokemon let’s go pikachu Not played
SUPER MARIO MAKER 2 Last played a month or more ago
The legend of Zelda: breath of the wild Not played
Super Smash Bros Ultimate Not played
Celeste
Pokemon HOME Last played a month or more ago
B-2
Tetris 99 Not played
VOEZ Not played
Cadence of Hyrule: Last played a month or more ago
There are more but we have enough evidence
Selected User Users:
Selected Manage blocked-user list There are no blocked users at this time
Select Social network posting settings Facebook: link Twitter: unlink
Sleep mode Auto-sleep (playing on console screen) 10min Auto-sleep (playing on TV screen) 1hr Disable auto-sleep while playing media content: off Wake when AC adapter is Disconnected: ON
TV Output TV Resolution: 1080p RGB Range Automatic Screen burn-in reduction On Match TV Power State: on TV Sound Stereo
System Current system version: 9.2.0 Console Nickname:
B-3
Synchroninse clock via internet: on Time zone: Madrid, Paris, Amsterdam, Brussels
Serial numbers Console serial number :
Automatic Software Updates: on Share error information: on
News channel settings All channels
Opened game Splatoon 2, selected user
Removed game cartridge. Tried taking screenshot, but error unable to take a screenshot now. Error says: The software was closed because the game card was removed. Always close the software before removing the game card. Back to error history. The error did not show up in the history. After being confused we took a look at the latest error report which was our test to see if it would create one. The error message is different than what we got right now. It says Unable to access game card. Please reinsert the game card. To
More in the list but this is enough
Friend suggestions Phone: it has names and then the game this player knows them from. Games listed: Animal crossing: pocket camp Fire Emblem Heroes
B-4
Facebook: Not linked
Twitter:
3DS:
WiiU:
Add friend (interesting for network capture) Search for users you’ve played with. Shows list of players with timestamps. Made screenshot. Example:
Really long list, made screenshot of the end of the page. Last user:
Went to news channel. Opened first article. Ring fit adventure free content update
Went to Nintendo eshop. User
Account information (it’s in dutch, unable to change). Current balance:
Main system: this system
Wishlist: cadence of hyrule – bought Pokemon let’s go pikachu – bought
Nintendo switch online Individual membership Expires
B-5
Settings for passes: you have no passes
Opened random store page: duck souls
Back to main menu, opened album Total of 362 screenshots and videos
Current console time: 17:08 Taken out of dock, powered off at above time. Accidentally turned on again at 17:11, immediately turned off, went into rcm and injected payload.
Noted that Hekate has a very different time than what the switch UI showed. It says 23:50 now.
B-6
Appendix C. Notes Analysis This document was originally intended to keep notes in for the analysis of the NAND. There turned out to be so much information that not everything could be documented in the thesis, so this is now added as an appendix. Information about any folder and partition can be found here, including information that is not very relevant.
There are 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
Let’s check out every partition individually.
PRODINFO
You can find information about it here https://switchbrew.org/wiki/Calibration
It’s a binary file that contains all sorts of cool stuff such as MAC address, serial number, battery ID, “HomeMenuSchemeMainColorVariation” and “LcdBacklightBrightnessMapping”. The most interesting thing in this file is probably the SSL key and certificate. We managed to extract both of these using a tool found on the internet. https://gbatemp.net/threads/certnxtractionpack-get- your-switch-cert-from-a-nand-dump.503844/page-13#post-8274335 We tried decrypting our pcap data with it but it seems like it didn’t work. What I found out is that you can use this key and certificate to download stuff from the Nintendo CDN https://gbatemp.net/threads/cdnx-cdn-downloader.504155/. There is however a very high chance that your certificate will get banned and that you’re not able to access Nintendo services anymore with your Switch, so we will absolutely not be doing this.
When comparing the before and after PRODINFO.bin files, it gives the exact same file. This makes sense because this file is made with the initial setup of the Switch and is never changed after that.
PRODINFOF
This is a FAT12 filesystem containing a number of folders and files. This is also a calibration partition, so the files before and after are exactly the same.
It contains the results of some tests that were performed at the first setup of the console. For example, it tested if USB and Bluetooth were working. The results are saved in files in this partition, but it doesn’t show any unique information about these components.
C-1
In the root directory there are three files that contain device ID’s and product codes. Namely: DeviceIdWithEmsBit.dat, Ecid.dat and prodCode.dat. The file names are very descriptive of what they contain.
BCPKG2-1-Normal-Main
This partition contains “package2”, which contains the Switch kernel and built-in system modules https://switchbrew.org/wiki/Package2. Specifically, it includes title ID 010000000000081A which is “BootImagePackageSafe”. I tried comparing the before and after files, but they’re the same. This makes sense, because the firmware didn’t change in any way. I also tried comparing one of these files to an old BCPKG2-1-Normal-Main file from 2019. This was a lot different. Also makes sense, because that was made on a different firmware version. This also confirms that there is no config data or anything in this partition. Worth ignoring.
BCPKG2-1-Normal-Sub
This is the backup partition for BCPKG2-1-Normal-Main. It’s exactly the same fie as -Main.
BCPKG2-3-SafeMode-Main
This partition contains the firmware package “BootImagePackageExFatSafe”. When comparing the before and after file, it is again the exact same.
BCPKG2-4-SafeMode-Sub
Backup partition for -Main. Again, the same as Main.
BCPKG2-5-Repair-Main
This partition is installed in the factory and then never changed again. Therefore, this will not contain any valuable information. I tested it and they’re obviously the same.
BCPKG2-6-Repair-Sub
You guessed it.
SAFE
This is a FAT32 filesystem. There is not much documentation about this partition, so it’s unclear what it does. When you mount it there doesn’t seem to be anything, but when you save it as a file then you can see some (seemingly useless without documentation) data. These files were compared to each other and they’re the same, so it’s probably not that useful anyway.
C-2
SYSTEM
The system partition contains save data of system applications. This partition had a lot of changes between the two images. Any changed file was thoroughly investigated using a program called hactoolnet.
The partition contains three folders: Contents, save and saveMeta. The contents folder contains .nca files, which is a Nintendo Content Archive file. These are raw applications. No user-specific data is saved here so these files will be ignored. (https://fileinfo.com/extension/nca)
The save folder is more interesting, because this contains the save data of system applications. These files are of interest:
- 8000000000001060
This file contains files that make up the http cache. Its structure looks like this: httpCache files 00000001.dcf 00000002.dcf 00000003.dcf ... Cache.fat HttpCache.fat NaAuthToken.dat
NaAuthToken.dat contains an authentication token. It is unclear where this is used for. Cache.fat is the main cache file which contains a lot of 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 be a javascript file, a jpg image or a text file. For image files you can simply change the extension to .jpg to open it.
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 basically impossible to determine whether the data is accurate. This file does not prove with a hundred percent certainty whether someone was using the console at the time of the http cache timestamp.
- 8000000000000180
Contains a list of software versions. Might be useful but probably not.
- 8000000000000120
IMKVDB, not sure. It’s not interesting that’s for sure.
- 8000000000000100
Apprestrictions.dat contains nothing for us, probably because we didn’t set any parental restrictions.
- 80000000000000F0
C-3
This file 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 (not sure what this is)
Every entry contains the following: Application ID User ID Time Date
It also contains statistics: Index for the first and last time this application was played Timestamp for the first and last time this application was played Total play time Total amount of launches
The problem with this file, however, is that it is very difficult to read. There is some documentation online about this file, but it is very complicated. There is a script available online that parses this file, but it is incomplete, and we found that it is also incorrectly labeling some data.
There are four event types:
0 – Applet
1 – Account
2 – PowerStateChange
3 – OperationModeChange
4 – Initialize
This script only parses the first event type; applet. This applet event type has six different types on its own:
0 – Launch
1 – Exit
2 – In focus
3 – out of focus
4 – exit
5 – exit
C-4
The script has a variable called event_type. It is unclear whether this means applet event type or main event type. One would assume it is the main event type because the output values are between 1 and 4, but value 4 is supposed to be only at the very first entry to initialize. I added the following line to the code:
If event_type == 2:
print(timestamp)
This line outputs a lot of extra data that was not available in the first output. It means that the script is both inaccurate and incomplete. We are not skilled enough to “repair” this code, but we added the above piece of code for each event type with an indicator of which event type it is. This 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 will make 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.
- 80000000000000e4
No clue to be honest. File names are version.bin, /record/valid.bin and /saved/94abc9b34ceb84d5
- 80000000000000e3
Again version.bin and now a ticket_list.bin which are both just filled with NULL bytes.
- 80000000000000e2
Version.bin, ticket_list.bin and ticket.bin. Completely in the dark here. Says something about root- CA though.
- 80000000000000e1
Same as previous.
- 80000000000000e0
This gives four files in the folder /certificate. They’re called XS00000024, XS00000021, XS00000020 and CA00000003. Not sure what to do with it. This might be useful: https://switchbrew.org/wiki/Ticket. “Tickets are a format used to store an encrypted title key”. Probably not very useful for us.
- 80000000000000d1
Contains crash logs which are serialized using msgpack. These contain a lot of useful information that presumably gets send to Nintendo in order to debug their application. For us this is extremely interesting because it contains a lot of 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 10 crash dumps are shown on the Switch, but there are 50 files. This is presumably every crash dump or the last 50 ones.
A sample crash log can be found in appendix D.
Timestamps are in epoch time which is easy to convert. I converted all crash dumps into json format.
- 80000000000000c1
C-5
Gives one file in the ‘dc’ directory: task.bin. Unreadable and no information to be found online.
- 80000000000000a1 & a2
These both contain play report msgpack files with an .lz4 extension. Despite this extension, they do not appear to be actual lz4 compressed files when compared to the structure of an actual lz4 file (e.g. must start with header 04 22 4d 18). They are also not msgpack files, because it is not possible to convert these to json, unlike actual msgpack files. However, it is still possible to make out the data in these files.
There has to be a way to decompress these files, but I can’t figure out how. The closest I’ve been able to get with this is this command: msgpack2json -cdp -i
The file current.msgpack seemingly contains the last power state change:
This information seems to be accurate with our test results. It should be noted that the timestamp is in UTC (GMT?).
The output should be investigated more and check if it relates to 80000F0.
- 80000000000000a0
Statistics_srepo.bin, statistics.bin and id.bin. Not very readable, no information available online. Switchbrew says it’s “Play Report system information.”
- 8000000000000090 - 92
Contains news messages in msgpack format. This can be converted to json. The files contain the time of publishing, but not the time of opening the news story. The presence of a news msgpack file could prove that this message has been opened, because the only file that is different from the before image is the news story that was opened during the experiment. On the other hand, I don’t remember going to the news channel as often as there are files.
- 8000000000000082
Contains profile images of every friend.
- 800000000000007x
C-6
Everything in the 70 range is the NIM, Network Install Manager. Since we didn’t install any games this does not give any output to us.
- 8000000000000060
List of SSL certificates.
- 8000000000000050 – 54
These contain settings. However, it is not human readable. This might not be a problem because this data is most likely the same data as seen on the device itself in the settings menu.
- 8000000000000046
I don’t know. Gives the files tsl and signature. Both not human readable, no documentation.
- 8000000000000044
File “private”. Not readable. Switchbrew says “Content update context.”
- 8000000000000045
List of software versions. This is not readable but it might be able to be parsed just like the playevent file. However, all the software versions are already readable on the Switch itself so we won’t go into this rabbithole.
- 8000000000000040
A bunch of .val files. Can’t figure out what they do.
- 8000000000000041
More .val files. Switchbrew says “Home menu icondata/lru list for recently played games.”.
- 8000000000000043
Files “private” and “private1”. Private is used for nca extraction from the sd card.
- 8000000000000010
Contains account information. The file
Nickname, birthday, id, language, loginID (nothing in our case), isChild (true or false), gender, region (nothing in our case), country, email, timezone, analyticsForTargetMarketingPermitted (true or false), analyticsForInternalAnalysisPermitted (true or false), screenname (this is the censored email address), isNnLinked (true or false, presumably Nintendo Network), isTwitterLinked, isFacebookLinked, isGoogleLinked.
The information that is not available by looking at the Switch itself is the full, uncensored, email address, the birthday, ID, if analytics are permitted (might not be useful) and if a Google account is linked.
There are also some other files available such as profile pictures and some tokens (not sure what it’s useful for).
- 8000000000000000
C-7
Contains the key value database. Not sure what it is used for.
- 000000000000002f
Contains the files id_list_meta, id_list_entry, app_id_list_meta, app_id_list_entry, store_meta and store_entry. These files are not easily readable and judging by the names it probably is not very interesting for us.
- 0000000000000012
Another playevent.dat. However, the script of before doesn’t see this as a valid playevent.dat file. This means that it must be different from the first file. It is not humanly readable and there is no other documentation available.
- 000000000000000c
Savedata.dat. Filled with NULL bytes.
- 0000000000000004
VisitedLink.dat, WebStorage.dat, Cookie.dat and Autofill.dat. From the filenames it seems to be very useful, but they contain non-readable data. In 0000000000000003 these same files are available, but they are filled with NULL bytes.
- 0000000000000001
Contains a number of files, one of which is history.bin that contains the last x players 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 is file is in is not very readable unfortunately, 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 certain user has played with another user at some point.
The file friend.cache contains usernames of all friends and their profile pictures. This information is already available on the console however.
The file setting.cache contains the user’s friend code, username and profile picture.
In conclusion for SYSTEM. The following files are important:
- 8000000000001060. Contains the http cache. - 80000000000000F0. The play event file. Contains logs of everything that was done. - 80000000000000D1. Crash logs. A lot of interesting information that is not available on console. - 80000000000000a1 & a2. More log files. - 8000000000000010. Account information. - 0000000000000001. Friend data.
There are a couple of other potentially interesting files, but only in very specific cases.
C-8
USER
The following is the structure of this partition:
(Switchbrew, 2020)
Over every file in this partition, only one file was changed:
This is presumably the Splatoon 2 save file.
We will be discussing the Album folder in the SD card section.
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:
Note that these are not all games that are installed on the system, only the games that are installed on the internal memory.
With the –listncas option in hactoolnet we can see that there are more NCAs than titles on the system:
C-9
Let us try examining title ID 01002B30028F6000 (random choice). This is the title ID of the game ‘Celeste’ (Switchbrew, Title list/Games, 2019). We used the following command: hactoolnet.exe -t switchfs -k prod.keys --title 01002B30028F6000 --outdir
These files can be decrypted using the –plaintext option. This 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:
C-10
The only file that was changed is ‘000000000000000f’ in the save directory. Opening it with hactoolnet, we get the file save.dat. This file is not human-readable. However, hactoolnet outputs some interesting information:
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 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.
It is unclear what the savemeta folder contains. Hacdiskmount is not able to read the .meta files and there is no information avaiable online. The temp directory is empty.
C-11
SD Card
The structure of the SD card is as follows:
Comparing everything except album:
The only file that is different is the private1 file in /Nintendo, which stores 0x20 bytes with the last 0x10 being random (Switchbrew, SD Filesystem, 2020). This 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.
The structure of the album folder is the same as on the USER parition 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 will capture 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. Then there are 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 appear 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 extention. Using exiftool to examine its metadata, this timestamp can be confirmed:
C-12
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, you need an sd-seed. This can be found in the file called private in 8000000000000043 on the SYSTEM partition. There are tutorials avaiable on how to extract the nca files using this sd seed, for example: (khang06, 2018). We however learned from the nca extraction process on the USER partition that this does not give much relevant information. This 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. We ran into a problem where hactoolnet does not recognise our sd seed. The error for both NCA and save files is that the header is not valid. Unfortunately it is not possbile to read these files because of this.
C-13
This page has intentionally been left blank
C-14
Appendix D. Crash Log
{ "UsbTopology":
D-1
"AcpCacheStorageSize": 0, "AcpCacheStorageJournalSize": 0, "AcpCacheStorageDataAndJournalSizeMax": 0, "AcpCacheStorageIndexMax": 0, "AcpBcatDeliveryCacheStorageSize": 0, "AcpAocRegistrationType": 1, "AcpAocBaseId": 72279008368717824, "AcpRuntimeAocInstall": 0, "AcpPlayLogPolicy": 0, "AcpPlayLogQueryCapability": 0, "AcpStartupUserAccount": 1, "AcpStartupUserAccountOptionFlag": 0, "AcpUserAccountSwitchLock": 0, "AcpAttributeFlag": 0, "AcpSupportedLanguageFlag": 221, "AcpParentalControlFlag": 0, "AcpScreenShot": 0, "AcpVideoCapture": 2, "AcpDataLossConfirmation": 0, "AcpPresenceGroupId": 72279008368713728, "AcpLocalCommunicationId": [ 72279008368713728, 72279008368713728, 72279008368713728, 72279008368713728, 72279008368713728, 72279008368713728, 72279008368713728, 72279008368713728 ], "AcpLogoType": 0, "AcpLogoHandling": 0, "AcpCrashReport": 0, "AcpHdcp": 0, "AcpSeedForPseudoDeviceId": 72279008368713728, "AcpRepairFlag": 0, "AcpRequiredNetworkServiceLicenseOnLaunchFlag": 0, "AcpRuntimeParameterDelivery": 0, "NetworkClockContextOffset": 1476977348, "NetworkClockContextTimeStampValue": 93763917, "UserClockContextOffset": 1476977348, "UserClockContextTimeStampValue": 93763917, "FsPooledBufferPeakFreeSize": 4505600, "FsPooledBufferRetriedCount": 0, "FsPooledBufferReduceAllocationCount": 0, "FsBufferManagerPeakFreeSize": 0, "FsBufferManagerRetriedCount": 4334, "FsExpHeapPeakFreeSize": 2399520,
D-2
"FsBufferPoolPeakFreeSize": 5154400, "FsPatrolReadAllocateBufferSuccessCount": 349, "FsPatrolReadAllocateBufferFailureCount": 0, "FsBufferManagerPeakTotalAllocatableSize": 9748480, "FsBufferPoolMaxAllocateSize": 299008, "UnknownControllerCount": 0, "AttachedControllerCount": 2, "BluetoothControllerCount": 0, "UsbControllerCount": 0, "ControllerTypeList":
D-3
1020000000, 0, ], "ModuleClockEnableFlags":
D-4
"BatteryChargePercent": 41746, "BatteryChargeVoltage": 3671, "BatteryAge": 96386, "PowerRole": 0, "PowerSupplyType": 0, "PowerSupplyVoltage": 0, "PowerSupplyCurrent": 0, "FastBatteryChargingEnabled": true, "ControllerPowerSupplyAcquired": false, "OtgRequested": false, "FocusedAppletHistory": [ 72057594037932037, 72057594037932032, 72057594037932051, 72057594037932032, 72057594037932051, 72057594037932032, 72057594037932038, 72057594037932032, 72057594037932051, 72057594037932032 ], "RunningAppletList": [ 72057594037932037, 72279008368713728, 72057594037932044, 72057594037932032 ], "RunningApplicationId": "0100c9600a88e000", "RunningApplicationTitle": "Picross S2", "RunningApplicationVersion": "1.0.0", "RunningApplicationStorageLocation": "SdCard", "RunningApplicationPatchStorageLocation": "None", "RunningApplicationVersionNumber": 0, "RunningApplicationProgramIndex": 0, "TemperaturePcb": 29187, "TemperatureSoc": 29437, "CurrentFanDuty": 51, "LastDvfsThresholdTripped": 23687, "EdidBlock":
D-5
"GameCardAsicInitializeCount": 108, "GameCardAsicReinitializeCount": 0, "GameCardAsicReinitializeFailureCount": 0, "GameCardAsicReinitializeFailureDetail": 0, "GameCardRefreshSuccessCount": 0, "GameCardAwakenCount": 110, "GameCardAwakenFailureCount": 0, "GameCardReadCountFromInsert": 37, "GameCardReadCountFromAwaken": 0, "GameCardLastReadErrorPageAddress": 0, "GameCardLastReadErrorPageCount": 0, "Throttled": false, "ThrottlingDuration": 0, "ThrottlingTimestamp": 1570810884, "PerformanceMode": 0, "PerformanceConfiguration": 131075, "CurrentSystemPowerState": 3, "PreviousSystemPowerState": 4, "DestinationSystemPowerState": 3, "AbortFlag": false, "HasSyslogFlag": true, "AccessPointSSID": "Netgear-Wifi 5GHz", "AccessPointSecurityType": "Wpa2-Psk(Aes)", "AccessPointChannel": 44, "OsVersion": "9.0.1", "PrivateOsVersion": "NintendoSDK Firmware for NX 9.0.1-1.0 (2a6263de)", "SerialNumber": "
D-6
"NANDCID":
D-7
"AlternateDNSIPAddress": "45.248.48.62", "ConnectionStatus": "Wireless", "ErrorCode": "2160-8007", "CipherKey":
Note: some information that is deemed forensically irrelevant has been cut to reduce the size of this document, for examples the values in CpuDvfsTableClocks to ModuleClockFrequencies.
D-8
Appendix E. Python Script Parsing Playevent.dat #!/usr/bin/env python3 import struct import sys from datetime import datetime with open('PlayEvent.dat', 'rb') as fin: magic = struct.unpack('i', fin.read(4))[0] if magic != 0: print('Not a valid PlayEvent file', file=sys.stderr) sys.exit(1)
number_of_entry = struct.unpack('I', fin.read(4))[0] for i in range(0, number_of_entry): event_data = fin.read(0x1c) event_type = struct.unpack('B', fin.read(1))[0] fin.read(3) # padding timestamp_user = struct.unpack('Q', fin.read(8))[0] timestamp_network = struct.unpack('Q', fin.read(8))[0] timestamp_steady = struct.unpack('Q', fin.read(8))[0]
event_type_string = str(event_type) if event_type == 0: title_id = [] title_id.append(struct.unpack('I', event_data[0x0:0x4])[0]) title_id.append(struct.unpack('I', event_data[0x4:0x8])[0])
applet_id = event_data[0xc] storage_id = event_data[0xd] log_policy = event_data[0xe] event_type = event_data[0xf]
version = None if applet_id == 1: version = struct.unpack('I', event_data[0x8:0xC])[0]
print('%08x %s %d %s %08x%08x %s %d %d %d %d' % ( fin.tell() - 0x38, "ET0", event_type, datetime.fromtimestamp(timestamp_user), title_id[0], title_id[1], str(version) if version is not None else '', applet_id, storage_id, log_policy, event_type))
if event_type_string.startswith('1'): print('%08x %s %s' % (fin.tell() - 0x38, "ET1", datetime.fromtimestamp(timestamp_user))) if event_type_string.startswith('2'): print('%08x %s %s' % (fin.tell() - 0x38, "ET2", datetime.fromtimestamp(timestamp_user))) if event_type_string.startswith('3'): print('%08x %s %s' % (fin.tell() - 0x38, "ET3", datetime.fromtimestamp(timestamp_user))) if event_type_string.startswith('4'): print('%08x %s %s' % (fin.tell() - 0x38, "ET4", datetime.fromtimestamp(timestamp_user)))
Adapted from https://gist.github.com/garoxas/012111ee0860dc68496603eb566dda55 by Garoxas.
E-1
Jelle van den Berg
Filip Lagerholm
PO Box 823, SE-301 18 Halmstad Phone: +35 46 16 71 00 E-mail: [email protected] www.hh.se