Identification of NAND flash ECC algorithms in mobile devices

Digital Investigation 9 (2012) 34–48

Contents lists available at SciVerse ScienceDirect

Digital Investigation journal homepage: www.elsevier.com/locate/diin

Identification of NAND flash ECC algorithms in mobile devices Li Zhang a, b, *, Yu-an Tan a, Qi-kun Zhang a a b

School of Computer Science and Technology, Beijing Institute of Technology, Beijing, PR China Department of Computer and Information Technology, Nanyang Normal University, Nanyang, PR China

a r t i c l e i n f o

a b s t r a c t

Article history: Received 4 November 2011 Received in revised form 9 April 2012 Accepted 10 April 2012

In the field of mobile device forensics and in flash memory data recovery, physical chip extraction is an important method for acquiring data from flash memory. However, this method can result in random errors in the full copy of the flash memory data, which reduces the accuracy of extracted electronic evidence and of the recovered data. Therefore, it is necessary to determine which Error Checking and Correction (ECC) algorithm was used in the flash controller, and then to implement this same ECC algorithm in software to detect and correct random errors. This paper presents some methods for identifying the NAND flash ECC algorithm in mobile devices. The method starts with a determination the location of the ECC code bytes in the spare area of a chip, then proceeds with an analysis of the parameters of the possible ECC algorithm, and finally verifies the ECC algorithm in software. Our experimental results show that the proposed method is effective in identifying a Hamming algorithm that may serve as a substitute for the ECC hardware built into the flash controller to detect and correct errors in the data. ª 2012 Elsevier Ltd. All rights reserved.

Keywords: Physical chip extraction ECC algorithm NAND flash Mobile device forensics Data recovery

1. Introduction With the increasing popularity and technological advances of mobile devices (Jie et al., 2011), sales of consumer electronic products such as mobile phone, personal digital assistant (PDAs), and portable data storage devices have risen sharply. In these devices, flash memory is widely used for non-volatile storage of data. The great quantity of personal information often stored in flash memory is of interest to forensic experts. At present, there are two approaches available to forensic technicians to acquire data from flash memory. One is known as logical data acquisition, which can only extract the files present (active data) on the mobile device, and the other consists of physical data acquisition, which can acquire the full physical image of the flash memory (also called the full copy of flash memory). The physical * Corresponding author. School of Computer Science and Technology, Beijing Institute of Technology, No. 5, South Avenue Zhongguancun, Haidian District, Beijing, PR China. E-mail addresses: [email protected], [email protected] (L. Zhang). 1742-2876/$ – see front matter ª 2012 Elsevier Ltd. All rights reserved. doi:10.1016/j.diin.2012.04.001

image includes inactive data, such as deleted data and any data that is relevant to the memory management (Breeuwsma et al., 2007). Therefore, the second approach plays a dominant role in the current research on mobile device forensics (Willassen S, 2006; Breeuwsma et al., 2007; Fiorillo, 2009; Klaver, 2010). Physical data acquisition can be accomplished with ‘Flasher Tools’, JTAG (Joint Test Action Group) interface, and with physical chip extraction (Breeuwsma et al., 2007; Klaver, 2010). Although physical chip extraction has some disadvantages, it is recommended by Klaver (2010), for the acquisition of the full copy of flash memory in the forensic environment, especially in the well-known case involving flash chips. This method can guarantee that no data is modified during the process. The preservation of data in flash is an important principle when examining electronic evidence (Breeuwsma et al., 2007). Another advantage of physical chip extraction is that it enables data acquisition from mobile devices that are locked with security codes (Klaver, 2010). In most flash memories, an ECC algorithm is executed via dedicated ECC hardware in the flash controller

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

(Willassen H, 2007) in order to ensure the integrity of data (Eric, 2009). Physical chip extraction involves the removal of a flash chip from a printed circuit board (PCB), and then reading the content of the chip with an external reader (Breeuwsma et al., 2007). During this process, the ECC hardware is not effective, as it cannot detect and correct errors when the flash memory data is read to generate a physical image. Consequently, random errors can occur in the physical image. However, it is the physical image which must be analyzed to reconstruct the file system (Breeuwsma et al., 2007; Klaver, 2010), from which electronic evidence that includes regular files as well as deleted files can then be extracted (Calhoun and Coles, 2008; James and Stokes, 2008; David and Hauri, 2010). Therefore, the existence of data errors in the physical image can result in a loss of accuracy in electronic forensic evidence. In some other particular cases, physical chip extraction is the only method that allows for recovery of flash memory data. For example, the user data stored in a mobile device is usually no longer available when the device controller is damaged. However, if the flash chip remains intact, all data in the flash memory chip can still be read out by physical chip extraction, and the user data can subsequently be recovered. For such a case, the ECC hardware is also not effective, which can lead to random errors ending up in the full copy of the flash chip. As for the case described earlier, the file system must be reconstructed to recover all the data (including user data), so that data errors in the flash copy can cause the user data to be recovered incorrectly. The aim of this paper is to discuss some methods that can be used to identify the ECC algorithm that is performed by the ECC hardware in the flash controller for the two cases described above. After identification, one can implement that same ECC algorithm in software to detect and correct errors in the physical image, thereby improving the accuracy of the extracted data from the physical image. In our discussion, the physical image is acquired via physical chip extraction. The two main types of flash memory are NOR and NAND based. NOR flash is more reliable than NAND flash, so that use of an ECC algorithm is uncommon in NOR flash memory. Therefore, this paper will extend only to NAND flash chips. The paper is organized as follows: Section 2 describes the technology basics of NAND flash and some important characteristics of three common ECC algorithms. Section 3 explains how to identify the location of the ECC code bytes in the spare area of the chip based on the physical image. In Section 4, we discuss the method used to determine the ECC algorithm, according to the length of ECC code bytes. Experiments and their results are described in Section 5, followed by a conclusion and proposed future work in Section 6. 2. NAND flash and ECC algorithms 2.1. The technology basics of NAND flash Compared to NOR flash, NAND flash memory has higher density capabilities, is cheaper, but is less stable, and cannot access data randomly (Gal & Toledo, 2005). In NAND flash chips, storage is divided into blocks, and blocks are

35

divided again into pages. A page is usually a multiple of 512 bytes in size, to emulate the 512-byte sector size that is commonly found in file systems on magnetic media. The block is the smallest erasable unit, while the page is the smallest programmable unit. Each page is divided into two regions: the data area and the spare area. The spare area is used for memory management purposes that include storage of an ECC code, logical sector number (LSN), bad block information, etc. This sort of data is also known as meta data or out-of-band data (Fiorillo, 2009). The size of spare areas can vary with the size of different pages and is normally 16 bytes per 512-byte sector, but other sizes are also used (Scott, 2007), as shown in Table 1. There are two primary types of NAND flash technology: Single-level cell (SLC) and multi-level cell (MLC) (Eric, 2009). The SLC flash memory stores one bit of data in each cell, so it has the advantage of reliability, good performance, and favorable power consumption. On the other hand, MLC memory stores multiple bits of data in each cell, so that it achieves higher bit density and has a lower cost per bit. Therefore, MLC NAND flash memory generally lacks reliability and has a higher error rate as compared with the SLC flash type. 2.2. Three ECC algorithms An ECC algorithm is used to ensure data block integrity and can be implemented in hardware or software. A parity bit is computed based on the data block. In NAND flash memory, there are three commonly used ECC algorithms, namely the Hamming algorithm, the RS (Reed–Solomon) algorithm, and the BCH algorithm (Scott, 2007). Amongst the three, the Hamming algorithm is the most straightforward and easiest to implement and will be described in detail in Section 4.2.2. This algorithm only detects 2 bit errors and corrects 1 bit errors, so it is usually used in SLC flash, it having better reliability than the MLC flash. The RS and BCH algorithms use Galois Field arithmetic operations to add parity symbols and their corresponding code words, which include data block and parity bits belonging to the class of linear cyclic codes (Eric, 2009; Liu et al., 2006). These two algorithms are able to provide more robust error correction that can handle multiple errors. As a result, they are always used in MLC flash applications. While the two algorithms are similar, they are distinguished by the fact that RS codes perform correction over multi-bit symbols, while BCH algorithms perform correction over single-bit symbols. In other words, the RS algorithm is symbolbased and the BCH algorithm is a binary code. In addition, the encoding and decoding techniques in the BCH algorithm are relatively simple as compared with the RS algorithm. Specifically, given that an RS code may be specified

Table 1 Various sizes of spare areas on chips (in bytes) vs. page size. Page size

Spare area size

Data area size

528 538 2048 þ (64/104) 4096 þ (128/208)

16 26 (16/26)*4 (16/26)*8

512 512 2048 4096

36

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

Table 2 List of general parameters for RS code and BCH code. Symbols: n is the length of code word, k is the length of data block, s is the symbol size, t is the number of correctable errors, and 2m is the number of finite elements in the Galois field that generates the BCH code. RS code The number of code word The number of data block The number of parity

BCH code

n ¼ 2s  1 symbols k symbols

n*s ¼ (2s  1)*s bits k*s bits

n ¼ 2m  1 bits k bits

n  k ¼ 2*t symbols

(n  k)*s ¼ 2*t*s bits

n  k & m*t bits

as RS(n, k) with s-bit symbols and a BCH code can be defined as BCH(n, k) with 1-bit symbols, the relationship between the length of the code word n, and the length of the data block k is summarized in Table 2. The three algorithms described above require different parity lengths for data blocks with the same length, such as the 512-byte data blocks found in NAND flash memory (see Table 3). From Table 3, it can be seen that the Hamming algorithm requires either 24 parity bits per 512 bytes of data or 22 parity bits per 256 bytes of data. For a 512-byte data block, the length of parity bits in the Hamming algorithm is either 3 bytes, or 6 bytes in which 44 bits constitute the real parity bits and 4 bits serve as padding bits. The RS algorithm requires 2*t*s parity bits, where s is equal to or greater than 9, so the iPhone for example uses a 10 bit RS symbol, because n ¼ 2s  1 symbols and is also greater than 512 bytes, that is to say, (2s  1)*s is greater than 512*8 bits. BCH requires 13*t parity bits. Using an RS code word as an example, if a data block contains 512 bytes that consist of 9-bit symbols, and if the RS algorithm supports 8-symbol error correction, it will require 16 parity symbols that equate to 144 parity bits. In that case, the RS algorithm will be able to correct the entire symbol if any number of bits within a 9-bit symbol are corrupted. 3. Identification of the location of ECC code bytes When physical chip extraction is used to acquire a physical image, the location of the spare area in the physical image and the location of ECC code bytes in that spare area are both unknown. The location of the spare area is determined by the storage method that was used for the spare area, which is not provided in the datasheets for NAND flash chips, although some information such as the flash array organization and the page/block size is usually listed. The first task therefore is to determine the storage method used for the spare area.

3.1. Determination of the storage method for the spare area In NAND flash memory, there are two storage methods in use for spare areas: the spare area is located either adjacent to the data area or is separate from it (Micron, 2006), as shown in Fig. 1. For a flash chip whose page size is 512 þ 16/26 bytes (see Table 1), the spare area is certain to be adjacent to the data area. In other configurations (2048 þ 64/104 bytes, 4096 þ 128/208 bytes), we need to deduce the storage method used for the spare area. In the following heuristic approach, the assumption is made that in the NAND flash chip under investigation, a page contains multiple sectors whose size is 512 bytes, and that one sector in a page is in fact a data block that is used to compute the ECC code. Thus, each data sector is always associated with one 16/26-byte part of the spare area. The approach is as follows: Step 1: A physical image of the entire NAND flash memory is made. Step 2: A fragment of the physical image is selected. The fragment starts at address addr and its size is equal to the page size p_s, where addr % p_s ¼¼0. Moreover, this fragment excludes sectors filled with 0xFF data, because the spare areas associated with such 0xFF sectors might only contain 0xFF data. In other words, each sector in the fragment must have a useful spare area. Step 3: If the size of the spare area is a multiple of 16 bytes, four 16-byte data pieces are read at the offsets of 0x200, 0x410, 0x620, and 0x830 in the fragment. They are then stored in four arrays named spare_1[16], spare_2[16], spare_3[16], and spare_4[16], respectively. If the size of the spare area is a multiple of 26 bytes, then four 26-byte data chunks are read at the offsets 0x200, 0x41A, 0x634, 0x84E in the fragment and then placed into four arrays named spare_i[26] (i ¼ 1,2,3,4). Step 4: The elements with the same index number in four arrays from Step 3 are compared. If these corresponding elements have the same value, e.g. spare_1[m] ¼ spare_2 [m] ¼ spare_3[m] ¼ spare_4[m], and if the number of such occurrences is greater than or equal to 3, it means that the spare area in the examined NAND flash chip is adjacent to the data area. If not, Step 5 or Step 6 must be performed. Step 5: If the page size is 2048 þ 64/104 bytes, Step 3 is performed again, but the offsets are now changed to 0x800/ 0x800, 0x8100/x81A, 0x820/0x834, and 0x830/0x84E. Then the corresponding elements with the same index number are compared again. If the condition outlined in Step 4 is satisfied, it means that the spare area is separate from the data area. If not, Step 6 must be performed.

Table 3 The different parity lengths in three common ECC algorithms. Parameters

ECC algorithm Hamming algorithm

The number of correctable errors The number of parity bits per 512 byte data block

Per 256 bytes

Per 512 bytes

1 bit 22*2 ¼ 44 bits or 6 bytes

1 bit 24 bits or 3 bytes

RS algorithm

BCH algorithm

t symbols 2*t*s bits or (2*t*s)/8 bytes

t bits 13*t bits or (13*t)/8 bytes

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

37

Fig. 1. a: Adjacent data and spare areas. b: Separate data and spare areas.

Step 6: If the page size is 4096 þ 128/208 bytes, eight 16/26 byte data pieces are read at the offsets of 0x1000/0x1000, 0x1010/0x101A, 0x1020/0x1034, 0x1030/0x104E, 0x1040/ 0x1068, 0x1050/0x1082, 0x1060/0x109C, and 0x1070/ 0x10B6 in the fragment. These are stored in eight arrays, and elements with the same index number in these arrays are compared as before. If spare_1[m] ¼ spare_2 [m] ¼ spare_3[m] ¼ spare_4[m] ¼ spare_5[m] ¼ spare_6 [m] ¼ spare_7[m] ¼ spare_8[m] and the number of index numbers m for which this is true is greater than or equal to 3, the spare area in the examined NAND flash chip is separate from the data area. This approach assumes that each 16/26-byte part of the spare area always contains at least 3 bytes with the same value in the fragment of the physical image, because LSN bytes, the bad block information byte, and some other reserved bytes usually contain the same value in each 16/26-byte part of the spare area for a given page. Of course, this approach can only be used on NAND flash chips where the spare area is divided into multiple 16/26 byte parts. Using the above-described method, we performed experiments on a LG KM330 phone (with MTK 6229 CPU and a TC58NVG0S3AFT 128 þ 4 Mbyte NAND flash chip by Toshiba) as well as a Newsmy USB drive (with unknown flash controller, K9F1G08U0M 128 þ 4 Mbyte NAND flash chip by Samsung), where 128 Mbytes comprise the data areas and the spare areas consist of 4 Mbytes. From the datasheets of the NAND flash chips, one learns that the page size in a TC58NVG0S3AFT chip is 2048 þ 64 bytes (Toshiba), and that this is also the page size for a K9F1G08U0M flash (Samsung). The experimental results show that for the LG KM330, the spare area is adjacent to the data area (as shown in Fig. 1a), while for the Newsmy USB drive, the spare area is separate from the data area (as shown in Fig. 1b). Figs. 2 and 3 depict the file fragments from the physical images of the LG KM330 and the Newsmy USB drive, respectively, in which the rectangular area represents the spare area and the offset is the absolute address in the physical image. Note that this method can be modified slightly in order to apply to other sizes, which are not included in Table 1.

3.2. Ascertaining the location of ECC code bytes in the spare area Breeuwsma et al. (2007) describe a method for determining the location of LSN bytes in the spare area, which can be applied to ascertaining the location of ECC code bytes after minor modification. To illustrate, we investigated a Philips F511 phone (with MTK6235 CPU and a HY27xA081G1M/A 128 þ 4 Mbyte NAND flash memory chip by Hynix). 3.2.1. The observational method The page size in the Philips F511 phone is 512 þ 16 bytes, so the spare area lies adjacent to the data area. To determine the location of ECC code bytes, a python script was implemented to read the 16 bytes in all spare areas in the physical image, and then count the frequency that each byte value occurs in each byte of the spare area, with a possible byte value ranging from 0 to 255. The total frequency counts were put into a table of 16 * 256 elements as described in Breeuwsma et al. (2007). A fragment of this kind of spare area frequency table is presented in Table 4. In columns 9 to 14, a regular distribution of all possible values can be seen, except for 0 and 255, indicating that the possible values in these columns are distributed randomly within a limited range. This implies that the ECC code might be stored in these bytes, because all data in the data area is distributed “randomly” throughout the NAND flash chip; since the ECC code is generated from this random data, the values in the ECC code bytes should also be distributed randomly. To be more specific, in Fig. 4 it can be seen that the data in columns 9, 10, 12 and 13 range from 1650 to 1950, while the data in columns 11 and 14 range from 800 to 1000. Further investigation reveals that the distribution of data in columns 9 and 12 is similar; and the distributions in columns 10/13 and in columns 11/14 are similar as well. Clearly, there are two continuous fields where columns have a similar data distribution: columns 9w11 and columns 12w14, and we can conclude that they are two ECC code fields and that the length of each field is 3 bytes. Finally, in order to verify the location of ECC code bytes accurately, we select two sectors from the physical image

38

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

Fig. 2. Four adjacent 16-byte spare areas found in each page of the physical image from the LG KM330.

that have identical data areas, but which have different LSN bytes in their spare areas, such as those sectors in the data area that were filled with 0x00 data. From the corresponding spare areas of such two sectors, we found the values in bytes 9w14 are same, and it can be shown that the ECC code must therefore be stored in bytes 9w14. For mobile devices that use a FAT file system, we can always can find such sectors because they are usually included in the FAT system files, or they may be found in the user files whose actual file size is smaller than their storage area size. A discussion for those mobile devices that do not use the FAT file system (such as mobile phones that use the exe3 file system for example), goes beyond the scope of this paper. 3.2.2. The quantitative method There is another method that may be used to identify the location of ECC code bytes. Fig. 5 shows the characteristics of the frequency distributions for byte values in LSN data and ECC code, which is based on the results from the observational method described above. In Fig. 5, the real frequency values are not used on the y-axes because the frequencies of LSN bytes and ECC bytes are different in different physical images, and the frequency range of each byte is also different, even for bytes that all belong to the same LSN data or ECC code. Since LSN data and ECC code

form the majority of bytes found in the spare area, the location of the ECC code bytes can be identified only if we can distinguish between them. In Fig. 5, it can be seen that in the LSN data byte the difference between two adjacent frequencies is either zero or relatively large, while in the ECC code byte the difference is relatively small. Therefore, we may use the Coefficient of Variation (COV) as defined in statistics to quantitatively analyze the relative degree of dispersion for frequency differences in each column in the spare area frequency table, which allows us to distinguish between LSN data bytes and ECC code bytes. The outline for the method to determine the ECC code bytes based on the COV is as follows: Step 1: The spare area frequency table is built as described in Breeuwsma et al. (2007). Step 2: For the ith (i ¼ 1,2,3,.16) column in the frequency table, the number of non-0x00 frequency values is counted and placed into an array num_array[i], where i indexes the array (i ¼ 1,2,3,.16). The vector elements with frequency value 0x00 and those with byte value 0 or 255 are then removed. For the non-0x00 frequency values that remain in the ith column, we compute the magnitudes of the difference between two adjacent values and store these in the ith column of another table we will call the frequency difference table. This table will have 16 columns where each

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

39

Fig. 3. Four separate 16-byte spare areas found in the pages of the physical image from the Newsmy USB drive.

column has up to 255 vector elements. For example, in case of the ith column of the frequency difference table, dm ¼ jvj þ 1,i  vj,ij, dm þ 1 ¼ jvj þ 2,i  vj  1,ij, dm þ 2 ¼ jvj þ 3,i  vj  2,ij, . where vj,i, vj þ 1,i, vj þ 2,i, vj þ 3,i represent adjacent non-0x00 frequency values (excluding those with byte value 0 or 255). Step 3: For each column vector in the frequency difference table, the average value and the standard deviation are computed, as well as the standard score (also called Z-score) using the formulas:

x1 þ x2 þ . þ x n ¼ n

x ¼

Pn i¼1

xi

(1)

n

sffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi Pn 2 i ¼ 1 ðxi  xÞ s ¼ n

zi ¼

(2)

jxi  xj s

(3)

Table 4 Fragment of a spare area frequency table for a Philips F511 phone. Byte value

1

3w8

9

10

11

12

13

14

15

16

0 1 2 3 4 5 6 7

1182 611 611 611 611 611 611 611

2 788 178 678 208 0 0 0 0

544 0 0 0 0 0 0 0

2324 1835 1828 1831 1785 1806 1845 1817

2231 1764 1821 1730 1789 1828 1717 1816 ..

1372 889 873 916 929 864 857 880

2238 1805 1797 1805 1738 1819 1733 1807

2298 1741 1779 1874 1667 1806 1742 1785

1389 884 923 947 846 842 823 858

5166 4558 4590 4654 4588 4589 4556 4493

544 0 0 0 0 0 0 0

16 17 18 19 20 21 22 23

611 611 611 611 611 611 611 611

39,667 39,073 32,992 30,848 0 0 0 0

0 0 0 0 0 0 0 0

1787 1718 1762 1812 1722 1831 1792 1784

1717 1810 1786 1693 1784 1707 1793 1842 ..

892 896 896 822 859 917 864 926

1793 1773 1771 1813 1758 1757 1818 1748

1772 1741 1648 1746 1791 1749 1728 1828

879 875 929 881 830 945 908 884

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

40

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

b

1950

1950

the frequency value

the frequency value

a

1900 1850 1800 1750 1700 1650 0

32

64

96

128

160

192

1900 1850 1800 1750 1700 1650 0

224

32

the possible byte value

64

96

128

160

192

224

the possible byte value

Distribution of frequencies in column 9

the frequency value

d

the frequency value

c

Distribution of frequencies in column 12

1950 1900 1850 1800 1750 1700 1650 1600 0

32

64

96

128

160

192

1950 1900 1850 1800 1750 1700 1650 1600 0

224

32

the possible byte value

64

96

128

160

192

224

the possible byte value

Distribution of frequencies in column 10

f

the frequency value

1050 1000 950 900 850 800 750 0

32

64

96

128

160

192

224

the frequency value

e

Distribution of frequencies in column 13

1050 1000 950 900 850 800 750 0

32

the possible byte value Distribution of frequencies in column 11

64

96

128

160

192

224

the possible byte value Distribution of frequencies in column 14

Fig. 4. The different distribution of frequency values in columns 9–14. a. Distribution of frequencies in column 9 b. Distribution of frequencies in column 12. c. Distribution of frequencies in column 10 d. Distribution of frequencies in column 13. e. Distribution of frequencies in column 11 f. Distribution of frequencies in column 14.

Here xi denotes the ith vector element, n represents the number of elements, x is the average value of all elements, s denotes the standard deviation for all elements, and zi represents the absolute value of the standard score of the ith element. Experiments show that those vector elements with zi > 3.0 may be considered to be outliers, which can hinder identification of the location of the ECC code bytes. Consequently, these outliers should be removed from the frequency difference table. Step 4: After removal of outliers, the average value and the standard deviation are re-computed. At last, the COV is calculated for each column:

COV ¼ s

x

(4)

Experiments indicate that the COVs of those columns that contain the ECC code bytes are smaller than those of the columns storing the LSN bytes, and also that the COVs of the ECC code bytes are generally less than 1.0, although this might not be applicable to a flash memory which contains sparse user data (fortunately, such a scenario is not common). In our experiments we find that user data occupy at least half of the available storage space of the flash memory. Therefore, m consecutive columns (m S 3) whose COVs are less than 1.0 indicates candidates that might contain the ECC code bytes. Defining the indexes of

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

41

frequency table are generated by i ¼ j %16, where j represents the jth byte in the spare area. 4. Determining the ECC algorithm From the introduction of three common ECC algorithms in Section 2.2, we can see that the number of parity bits differs in each ECC algorithm. Therefore, these ECC algorithms can be distinguished based on the length of ECC code bytes found in the spare area. After the location of the ECC code bytes is identified, the length of ECC code can be calculated, from which we can deduce which ECC algorithm has been implemented in the flash controller. A final required step is to verify the ECC determination. Although the ECC algorithms used in NAND flash devices have been well studied in theory, in practice there are some pitfalls to be aware of:

1) The length of ECC code bytes may be greater than the theoretical code prescription because some padding bits may be set as 0 or 1 in the practical ECC code. 2) There may be errors in the ECC code, since random errors may exist in the data area which is used to generate the ECC code. 3) The parity bit position of a practical ECC code may be different from that defined in the theoretical prescription. Fig. 5. Representative frequency distributions for LSN & ECC code bytes. a. LSN data byte. b. ECC code byte.

these consecutive columns as ai (i ¼ 1, 2, 3, . m), we determine that these columns are indeed the ones with the ECC code bytes if num_array[ai] ¼ 2n (n is a positive integer and num_array[ai] is presented in Step 2 above) and Pm Pm i ¼ 1 ni  24, where i ¼ 1 ni is the length of ECC code bits. Using this quantitative method, the NAND flash chips from several mobile devices were examined and attempts were made to determine the location of ECC code bytes in their spare areas. The mobile devices included a Philips F511 phone (MTK6235 CPU and HY27xA081G1M/A 128 þ 4 Mbyte NAND flash memory), a Philips X800 phone (MTK6229 CPU and HY27xA081G1M/A 128 þ 4 Mbyte NAND flash memory), a LG KM330 phone (MTK6229 CPU and TC58NVG0S3AFT 128 þ 4 Mbyte NAND flash memory), a Kingmax USB flash drive (SK6211 controller and K9LBG08U0M 4 Gbyte þ 128 Mbyte NAND flash chip), and the Newsmy USB drive (with unknown flash controller and K9F1G08U0M 128 þ 4 Mbyte NAND flash chip). The experimental results are displayed in Table 5, which agrees with the results from the observational method. In addition, the length of ECC code bits (n) can be determined P using numberi ¼ 2n (where i is in bold in Table 5). It is noteworthy that the length of the spare area in some NAND flash chips exceeds 16 bytes but is a multiple of 16 bytes. For example, the TC58NVG0S3AFT flash chip in LG KM330 has a 64 byte spare area, as its data/spare area is given by 512/512/512/512/16/16/16/16. In such a case, the vector elements in the ith column of the spare area

These problems are addressed in the following section. 4.1. Deduction of the type of ECC algorithm The length of ECC code bits that have been implemented is found as described in Section 3.2.2, so the first problem can be solved easily, and based on that we can deduce which type of ECC algorithm we are dealing with. In general, the number of parity bits for the Hamming algorithm is less than that for the BCH/RS algorithms for data blocks with a given length, because the error correction abilities of the Hamming algorithm are more limited. For a 512-byte data block, the Hamming algorithm requires either 24 or 44 parity bits, while the BCH algorithm has 13*t parity bits and the RS algorithm requires 2*t*s parity bits (see Table 3). Here t represents the number of correctable errors, which in practice is usually t  4, and s represents the symbol size where generally s  9. Based on this analysis, we can conclude that the Hamming algorithm is in use if the length of ECC code bits in the spare area is 24 or 44 bits; if the length is greater, it is possible that a BCH/RS algorithm is used in the flash controller. In that case, we can distinguish between BCH and RS algorithms because the number of parity bits generated by a BCH algorithm is always divisible by 13, while for an RS algorithm this is usually not the case, since it uses 2*t*s bits which is only divisible by 13 if t or s are equal to 13. Some additional parameters used in BCH or RS algorithms can also be deduced. For example, if the length of ECC code bits is found to be 182 bits, we can guess that the code consists

42

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

Table 5 COV value and location of ECC code bytes using the quantitative method. Here i denotes the ith byte in the 16-byte spare area, number represents the number of non-0x00 frequency values for each column in the spare area frequency table, and COV denotes the coefficient of variation for every column in the frequency difference table. The red i represent the location of the ECC code bytes. The Philips F511 phone i 1 number 256 COV 5.33 i 9 number 128 COV 0.79 The Philips X800 phone i 1 number 256 COV 0.71 i 9 number 256 COV 0.79 The LG KM330 phone i 1 number 256 COV 0.74 i 9 number 256 COV 0.73 The Kingmax_1 USB flash drive i 1 number 256 COV 8.05 i 9 number 256 COV 0.69 The Newsmy USB drive i 1 number 3 COV 0 i 9 number 256 COV 0.83

2 15 1.95 10 128 0.98

3 5 0.54 11 256 0.75

4 5 0.65 12 128 0.93

5 1 0 13 128 0.96

6 1 0 14 256 0.82

7 1 0 15 51 1.3

8 1 0 16 27 1.39

2 16 0.49 10 16 0.69

3 256 0.68 11 256 0.85

4 16 0.81 12 66 1.87

5 6 1.41 13 256 1.35

6 2 0 14 256 2.82

7 3 0 15 128 6.04

8 2 0 16 33 0.83

2 16 1.11 10 16 0.66

3 256 0.82 11 256 0.72

4 16 0.54 12 16 0.51

5 256 1.02 13 1 0

6 256 8.51 14 1 0

7 4 0 15 256 0.59

8 2 0 16 23 1.34

2 16 2.28 10 256 0.76

3 256 5.4 11 256 0.73

4 2 0 12 256 0.64

5 256 0.76 13 256 0.78

6 256 0.73 14 256 0.79

7 256 0.71 15 256 0.71

8 256 0.79 16 8 0.36

2 3 0 10 256 0.78

3 256 3.56 11 64 0.65

4 256 1.29 12 3 0

5 128 1.51 13 3 0

6 23 0.58 14 256 0.62

7 3 0 15 256 0.79

8 3 0 16 64 0.67

of a BCH algorithm whose parameter t is 14, because 182 ¼ 13*14. If the length of ECC code bits is 144 bits, which is not divisible by 13, we can assume that an RS algorithm resides in the flash controller. From the Section 2.2, we know that the symbol size s in the RS algorithm usually obeys s  9 when the length of a data block is 512 bytes. In this case, 144 ¼ 2*9*8, and we can see that t ¼ 8 and s ¼ 9 in the RS algorithm. In our experiments, we found that for a Philips X800 phone (MTK6229 CPU and 128 þ 4 Mbyte HY27xA081G1M/ A NAND flash) the length of ECC code bits is 24 bits, although the ECC code occupies 4 bytes in the spare area (see Table 5). Therefore, we assume that a Hamming algorithm which generates ECC code using 512 byte data is adopted in this flash controller. For a Kingmax USB flash drive (Skymedi SK6211 controller and K9LBG08U0M NAND 4 Gbyte þ 128 Mbyte flash chip), the ECC code length is 91 bits, generated per 512 bytes of data (see Table 5). Thus, we guess that a BCH algorithm is used, where the number of correctable errors is t ¼ 7. 4.2. Verification of ECC algorithm deduction In theory, verification of the deduction of which ECC algorithm is present is straightforward. First, a sector (512 bytes) in the data area is selected at random. Second, the

corresponding ECC code is constructed according to the deduced ECC algorithm. Lastly, the ECC code is compared with that stored in the corresponding spare area. If they are identical, it indicates that the deduced ECC algorithm is the correct one. If not, it indicates that the deduced algorithm may be wrong. However, we have not yet encountered such a case. There are three main questions in this regard:

1) There could be data errors in both the data area and the spare area of the physical image. In that case, the ECC code which is computed based on the values in the data area (called computed ECC code in later sections) may be wrong, and the ECC code that is stored in the corresponding spare area (called stored ECC code in later sections) may also be incorrect. In such a scenario, a comparison of the two codes is meaningless. 2) The parity bit position of an ECC code as defined in theory may differ from the actual code that is stored in the spare area, with the result that the verified ECC algorithm may be correct even when the computed ECC code and the stored ECC code are not same. 3) For RS and BCH algorithms, asides from the number of correctable errors and the symbol size that have been

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

calculated in Section 4.1, we need to determine some additional parameters such as the generator polynomial, the actual length of a data block, and the seed values in the data scrambler before the ECC code can be computed. This is a relatively complicated task, so that the problem of verification of BCH/RS algorithms will be omitted in the following sections. As compared with

43

Note that the theoretical ECC code is constructed with the software Hamming algorithm, while the practical ECC code is generated by the algorithm residing in hardware. For Table 6, the generation rules for parity bits are described in Fig. 6 (Samsung_1, 2005) and Fig. 7 (Samsung_2, 2004), where the mathematical expressions of parity generation can be written as follows:

P1 ¼ bit7ð þ Þbit5ð þ Þbit3ð þ Þbit1ð þ ÞP1 P10 ¼ bit6ð þ Þbit4ð þ Þbit2ð þ Þbit0ð þ ÞP10 P2 ¼ bit7ð þ Þbit6ð þ Þbit3ð þ Þbit2ð þ ÞP2 P20 ¼ bit5ð þ Þbit4ð þ Þbit1ð þ Þbit0ð þ ÞP20 P4 ¼ bit7ð þ Þbit6ð þ Þbit5ð þ Þbit4ð þ ÞP4 P40 ¼ bit3ð þ Þbit2ð þ Þbit1ð þ Þbit0ð þ ÞP40 P8 ¼ bit7ð þ Þbit6ð þ Þbit5ð þ Þbit4ð þ Þbit3ð þ Þbit2ð þ Þbit1ð þ Þbit0ð þ ÞP8

BCH/RS algorithms, verification of a Hamming algorithm determination is relatively easy. The methods described in the next sections will focus on deterministic verification for Hamming algorithms. 4.2.1. Selecting sector data with regularity Using sector data that exhibits some regularity in the physical image can help in determining that there are errors in both the data area and the spare area. A good choice is to select a sector which contains only 0x00 or 0xFF data. In this case, an error-free stored ECC code can be found by comparing several spare areas, which solves the problem that arises from random errors in the ECC code itself. 4.2.2. Correspondence between parity bit positions in two kinds of ECC codes If sector data with regularity cannot be found in the physical image, the correspondence between the parity bit position of the stored ECC code vs. computed ECC code needs to be determined. Our experiments show that if there is such a correspondence, the deduced ECC algorithm will be correct. A Hamming algorithm either calculates ECC code per 256 byte data or per 512 byte data. The software implementation of this algorithm has been presented by Samsung Electronics Co., Ltd, where the parity bit positions of a theoretical ECC code are defined as in Table 6 (Samsung_1, 2005; Samsung_2, 2004). We can see that the element found in Bit 1 of Byte 2 represents the parity bit named P2048 (here ECC code is generated per 512 byte data). It is always set as ‘1’ for the case when ECC code is generated per 256 byte data. The element in Bit 0 of Byte 2 is similar.

Table 6 Parity bit position for Hamming ECC code for 512/256 byte data. Bytes

Bits Bit 7

Bit 6

Bit 5 Bit 4

Bit 3 Bit 2

Bit 1

Bit 0

P32 P320 P16 P160 P8 P80 Byte 0 P64 P640 Byte 1 P1024 P10240 P512 P5120 P256 P2560 P128 P1280 Byte 2 P4 P40 P2 P20 P1 P10 P2048/1 P20480 /1

In these expressions, “(þ)” represents a XOR operation. With i defined as the serial number of a data byte, the parity bits named P16, P32, P64.. P1024, P2048 are equal to the results of XOR operations on all bits in the ith byte, where i is different for each parity bit. For example, P16 corresponds to i ¼ 3, 4, 7, 8, 11, 12, 15, 16..507, 508, 511, 512 in Fig. 6; similarly P16 corresponds to i ¼ 3, 4, 7, 8, 11, 12, 15, 16..251, 252, 255, 256 in Fig. 7. P32 corresponds to i ¼ 5, 6, 7, 8, 13, 14, 15, 16, 20, 21, 22, 23...501, 502, 503, 504, 509, 510, 511, 512 in Fig. 6; similarly P32 corresponds to i ¼ 5, 6, 7, 8, 13, 14, 15, 16, 20, 21, 22, 23...245, 246, 247, 248, 253, 254, 255, 256 in Fig. 7. We have created a method which can determine the correspondence between parity bit positions for the two kinds of ECC codes (theoretical and practical), the prescription of which is as follows: Step 1: Multiple consecutive data sectors are selected from the physical image. Step 2: For each data sector, the Hamming code is computed according to the deduced Hamming algorithm. Step 3: For these computed Hamming codes, the values of the parity bits in the same position are added up and stored in a 1D array, named computed_ECC, and ordered as shown in Table 6. Step 4: Spare areas which correspond to the data sectors from Step 1 are selected from the physical image. Step 5: For the Hamming codes stored in these spare areas, the values of the parity bits in the same position are also added up and stored in a 1D array, named stored_ECC. Step 6: The elements in the two arrays are sorted and stored arrays named computed_ECC0 and stored_ECC0 . With the two sorted arrays, several comparisons may be performed that lead to the determination of the correspondence between parity bit position in the theoretical and practical ECC codes: Case one. The two arrays are both sorted in descending order. If each element in computed_ECC0 matches the elements in stored_ECC0 , we have found the correspondence between the element indexes in the arrays of computed_ECC and stored_ECC, where the indexes are the parity

44

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

Fig. 6. Parity generation for 512-byte data (Samsung_1, 2005).

bit positions of the Hamming code. A simple example is shown in Fig. 8. Case two. The two arrays are sorted in ascending and descending order, respectively. Then we may find that two corresponding elements in each array are not the same, but have the same summation. In this case, the correspondence between the two arrays can still be determined, according to the example that is presented in Fig. 9. In the figure, S represents the number of data sectors which are used to compute the ECC code, and a, b, c, d denote the number of the parity values of ‘1’ in the array computed_ECC0 , and a0 , b0 , c0 , d0 represent the number of the parity values of ‘1’ in stored_ECC’. Upon further analysis, we find a þ a0 ¼ S <¼> a ¼ S  a0 , where S  a0 represents the number of the parity value with ‘0’ in stored_ECC0 . For b, c, d, the procedure is similar to that for a. In summary, the number of the parity values of ‘1’ in the array computed_ECC is equal to the number of the parity values of ‘0’ in the array stored_ECC, from which we can conclude that the flash controller inverts the ECC code bits which are

generated in hardware before storing them in the spare area. Case three. If both arrays have neither the corresponding elements nor the same element summation after they are sorted, it will indicate that a correspondence does not exist. In this case, we can conclude that the deduced ECC algorithm is incorrect. In theory, data errors may have occurred not only in the data area which is used to compute Hamming code, but also in the spare area which is used to store Hamming code, which would cause a divergence between some of the values of two corresponding elements in the arrays. However, in practice this problem does not affect the correspondence between the parity bit positions of the computed and stored Hamming codes, because the typical raw bit error rates for SLC NAND flash memory are very low (Alan and Langlois, 2008). To illustrate the procedure explicitly, we applied this method on the Philips F511 phone (MTK6235 CPU and a 128 þ 4 Mbyte HY27xA081G1M/A NAND flash chip). We deduce that a Hamming algorithm which generates an ECC

Fig. 7. Parity generation for 256-byte data (Samsung_2, 2004).

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

45

Fig. 8. Generation of the correspondence between parity bit positions in practice and in theory.

code for every 256 bytes of data was used in this phone, because the length of ECC code bytes in the spare areas is 6 bytes (see Table 5). Upon selection of 1000 data sectors to compute the Hamming codes, we add up the values of parity bits at identical positions for the computed/stored Hamming codes. The results are stored in two arrays named computed_ECC and stored_ECC (shown in Table 7), where padding bits are found in locations computed_ECC [22], computed_ECC[23], stored_ECC[0], and stored_ECC[12]. After sorting these arrays (see Table 8), the correspondence between the parity bit positions in practice and in theory is described by the formula:

 j¼

13 þ i=2ði%2 ¼ ¼ 0Þ ði ¼ 0;1;2..21Þ...; i=2 þ 1ði%2 ¼ ¼ 1Þ

(5)

where i, j are labels for the indexes of computed_ECC and stored_ECC, respectively. The result shows that our deduced ECC algorithm is the correct one. 4.3. Identification of NAND flash ECC algorithm based on the physical image The bulk of the problem of data recovery is solved by ECC algorithm analysis based on examination of the physical image of NAND flash memory. The determined ECC algorithm is subsequently configured in software and used to detect and correct errors in the physical image. The complete procedure for analyzing the ECC algorithm and detecting errors is summarized as follows:

Fig. 9. Example of bit inversion for ECC code stored in spare area.

46

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

Step 1: The location of ECC code bytes in the spare areas is identified as per Section 3. Step 2: The ECC algorithm is deduced as per Section 4.1, using the length of ECC code bits which were found to be stored in the spare areas. Step 3: The deduced ECC algorithm is verified, as per Section 4.2, summarized here: (a) One sector with data regularity is selected to compute ECC code according to the deduced ECC algorithm. If such a data sector cannot be found, go to (c). (b) If the computed ECC code and the stored ECC code are found to be identical, the deduced ECC algorithm is correct, go to Step 4. If not, go to (c). (c) The correspondence between the parity bit positions in the computed ECC code and in the stored ECC code must be determined. If this correspondence exists, go to Step 4, otherwise it indicates that the deduced ECC algorithm is incorrect and Step 4 is not executed. Step 4: For each sector in the physical image, the data areas are used to generate ECC code based on the verified ECC algorithm. The ECC code that resides in the corresponding spare areas is transformed into a new ECC code according to the correspondence described above. This new ECC code is then compared with the computed ECC code. If they are same, there are no errors in this sector. If not, it means that there are errors in the sector, which can be corrected using the verified ECC algorithm. The procedure described above is universally applicable for not only Hamming algorithms, but also for RS and BCH algorithms, where only the detailed implementation of Step 3 is different for different ECC algorithms. However, the verification procedure for BCH and RS algorithms involves the determination of other parameters such as the generator polynomial, the seed values in the data scrambler, etc. Since this problem is relatively difficult, we restrict the discussion to Hamming algorithms in this paper.

5. Experimental results and discussion In our experiments, three mobile phones and three USB flash drives were used to study the efficacy of our methods for determining ECC codes in flash memory. The devices included the Philips F511 phone (MTK6235 CPU, 128 þ 4 Mbyte NAND flash), the Philips X800 phone (MTK6229 CPU, 128 þ 4 Mbyte NAND flash), the LG KM330 phone (MTK6229 CPU, 128 þ 4 Mbyte NAND flash), the Kingmax_1 USB flash drive (SK6211 controller, 4 Gbyte þ 128 Mbyte NAND flash chip), the Newsmy USB drive (128 þ 4 Mbyte NAND flash), and the Kingmax_2 USB drive (SK6211 controller, 8 Gbyte þ 256 Mbyte NAND flash chips). The physical images of these NAND flash chips were acquired by physical exaction as described in Breeuwsma et al. (2007). The results are summarized in Table 9, where we can see that the spare area storage method is related to the part number of a NAND flash chip, while the

Table 7 Statistical values for parity bits in computed_ECC and stored_ECC arrays. Before sort

The indexes and the corresponding elements of two arrays

Index computed_ECC stored_ECC Index computed_ECC stored_ECC Index computed_ECC stored_ECC

[0] 976 0 [8] 994 1043 [16] 1000 972

[1] 1009 1009 [9] 993 999 [17] 999 994

[2] 1008 983 [10] 1028 977 [18] 996 1028

[3] 983 965 [11] 961 1007 [19] 977 988

[4] 990 1015 [12] 988 0 [20] 968 982

[5] 965 993 [13] 975 976 [21] 1007 999

[6] 972 961 [14] 982 1008 [22] 2000 996

[7] 1015 975 [15] 1043 990 [23] 2000 968

location of ECC code bytes and the type of ECC algorithm implemented are both related to the type of controller that is used. In addition, the specific parameters of each ECC algorithm are dependent on both the type of controller and the part number of the NAND flash chip, as evident in the experimental results for the Kingmax_1 USB drive and that of Kingmax_2 USB drive (see Table 9). In Table 10, examples of two types of correspondences between the parity bit positions are shown, using results from the Philips X800 phone and the LG KM330 phone; two different values are separated by the symbol “/”. For the Philips F511 and X800 phones, the LG KM330 phone and the Newsmy USB drive, four versions of Hamming algorithms were implemented in software to detect and correct real data errors, as well as pseudorandom 1-bit errors that we introduced artificially. In each of the four physical image files, real errors were detected first, after which 1-bit errors were artificially and randomly distributed in several of the 512-byte data areas. The number of detected real data errors was 0,1,0,0, respectively, while the pseudo-random 1-bit errors were all detected, from which we conclude that the raw bit error rates (BER) for SLC NAND flash chips are very low, and an analysis of Hamming algorithms may not be necessary. However, complete detection of pseudo-random errors proves that the methods described in this paper do correctly identify NAND flash Hamming algorithms, and may be used to detect and correct raw data errors. As compared with circuits built in flash controllers that execute Hamming algorithms in hardware, our work takes on the same importance, especially in the field of mobile device forensics. Table 8 Statistical values for parity bits in sorted computed_ECC0 and stored_ECC0 arrays. After sort

The elements of two sorted arrays and their corresponding indexes before sort

Index before sort computed_ECC0 Index before sort stored_ECC0 Index before sort computed_ECC0 Index before sort stored_ECC0 Index before sort computed_ECC0 Index before sort stored_ECC0

[11] 961 [6] 961 [3] 983 [2] 983 [21] 1007 [11] 1007

[5] 965 [3] 965 [12] 988 [19] 988 [2] 1008 [14] 1008

[20] 968 [23] 968 [4] 990 [15] 990 [1] 1009 [1] 1009

[6] 972 [16] 972 [9] 993 [5] 993 [7] 1015 [4] 1015

[13] 975 [7] 975 [8] 994 [17] 994 [10] 1028 [18] 1028

[0] 976 [13] 976 [18] 996 [22] 996 [15] 1043 [8] 1043

[19] 977 [10] 977 [17] 999 [9] 999 [22] 2000 [0] 0

[14] 982 [20] 982 [16] 1000 [21] 1000 [23] 2000 [12] 0

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

47

Table 9 Experimental results for determination of ECC code byte location and nature of ECC algorithm. Mobile device

The part number of the NAND flash chip

The type of controller

The storage method for spare area

Philips F511 phone Philips X800 phone LG KM330 phone Kingmax_1 USB drive Newsmy USB drive Kingmax_2 USB drive

HY27xA081G1M/A, SLC HY27xA081G1M/A, SLC TC58NVG0S3AFT, SLC K9LBG08U0M, MLC K9F1G08U0M, SLC JS29F64G08CAMD2, MLC

MTK6235 MTK6229 MTK6229 SK6211 Unknown SK6211

Separate, 512 þ 16 bytes Separate, 512 þ 16 bytes Adjacent, 2048 þ 64 bytes Adjacent, 4096 þ 128 bytes Separate, 512 þ 16 bytes Separate, 512 þ 26 bytes

Mobile device

The location of ECC code(the index of byte location starts 1)

The deduced ECC algorithm

The determined ECC algorithm

Philips F511 phone

byte 9w11, 12w14

Philips X800 phone

byte 1w4

LG KM330 phone

byte 9w12 per 16-byte spare area

Kingmax_1 USB drive

Hamming algorithm per 256 bytes data and the correspondence is shown as Formula 5 Hamming algorithm per 512 bytes data and the correspondence is shown as Table 10 Hamming algorithm per 512 bytes data and the correspondence is shown as Table 10 not verified

Newsmy USB drive

byte 5w16(71 bits) per 16-byte spare area byte 9w11, 14w16

Kingmax_2 USB drive

byte 5w26(169 bits)

Hamming algorithm per 256 bytes data Hamming algorithm per 512 bytes data Hamming algorithm per 512 bytes data BCH (4219, 4128, 2t þ 1 ¼ 15) algorithm Hamming algorithm per 256 bytes data BCH(4297, 4128, 2t þ 1 ¼ 27) algorithm

Hamming algorithm per 256 bytes data and the correspondence is shown as Table 11 not verified

Table 10 Parity bit position correspondence in a Philips X800/LG KM330 phone. Philips X800/LG KM330

The correspondence between the parity bit positions of computed/stored Hamming codes

stored_ECC computed_ECC stored_ECC computed_ECC stored_ECC computed_ECC stored_ECC computed_ECC

[0] [15] [8] 1 is always [16] [14] [24] 1 is always

[1] [1] [9] set [17] [0]/[19] [25] set

[2] [3] [10]

[3] [5] [11]

[18] [2] [26]

[19] [4]/[21] [27]

More importantly, it is known that typical raw BER in SLC NAND flash memory range from 1 * 109 to 1 * 1011 errors per bit read, while typical raw BER for MLC type NAND flash memory range from 1 * 105 to 1 * 107 errors per bit read (Alan and Langlois, 2008). For an SLC flash chip with a (typical) storage capacity of 128 þ 4 Mbytes, the number of bit errors should be between 0 (corresponding to 1 * 1011 raw BER) and 1 (corresponding to 1 * 109 raw BER), which is just what was found in our experimental results. However, for an MLC flash chip with a (typical) storage capacity of 4 G þ 128 Mbytes, the number of bit errors should be between 3543 (corresponding to 1 * 107 raw BER) and 354,335 (corresponding to 1 * 105 raw BER). Therefore, the task of verifying the BCH and RS algorithms based on a physical image takes on more significance. In Table 11 Parity bit position correspondence in a Newsmy USB flash drive. Newsmy

The correspondence between the parity bit positions of computed/stored Hamming codes

stored_ECC computed_ECC stored_ECC computed_ECC stored_ECC computed_ECC

[0] [8] [8] [0] [16] [16]

[1] [9] [9] [1] [17] [17]

[2] [10] [10] [2] [18] [18]

[3] [11] [11] [3] [19] [19]

[4] [12] [12] [4] [20] [20]

[5] [13] [13] [5] [21] [21]

[6] [14] [14] [6] [22] [22]

[7] [15] [15] [7] [23] [23]

[4] [7] [12] [23]/[10] [20] [6] [28] [22]

[5] [17] [13] [9] [21] [16] [29] [8]/[20]

[6] [19]/[0] [14] [11] [22] [18] [30] [10]/[23]

[7] [21]/[4] [15] [13] [23] [20]/[8] [31] [12]

this light, the discussion in this paper lays the foundation for methods to determine the location of ECC code bytes in the spare areas of NAND flash memory (Table 11). 6. Conclusion and future work We have described a method whereby a particular Hamming algorithm, one of the three main ECC algorithms in use, can be identified if it has been deployed in the NAND flash memory of mobile devices. In order to determine the location of ECC code bytes in spare areas, a quantitative method based on the coefficient of variation has been proposed, in addition to an observational method. A road map for analyzing the parameters of the possible ECC algorithm was also laid out, allowing us to deduce which specific Hamming algorithm makes up the ECC code. Finally, a process has been presented that allows us to verify that the deduced Hamming algorithm is the correct one, by determining the correspondence between the parity bit positions in the software and hardware versions of the Hamming code. Experiments with several devices demonstrate that our methods are effective in identifying NAND flash ECC algorithms. In our experiments, all mobile devices that were examined use the FAT file system. In future work, we will investigate ECC algorithms in devices that use other file systems.

48

L. Zhang et al. / Digital Investigation 9 (2012) 34–48

When a flash controller is damaged, reverse engineering of the NAND flash ECC algorithm that resides in the flash controller makes it possible to recreate that ECC algorithm in software, which then allows us to detect and correct errors in the memory data. In physical chip extraction data recovery, the accuracy of the extracted data will be low if a large number of errors are present in the full copy of a flash memory chip. In such a scenario, identification of the ECC algorithm in the memory is necessary. Although current methods to identify ECC algorithms can only determine the details for Hamming algorithms, the foundation for identifying BCH and RS algorithms has been built. Since BCH and RS algorithms are usually used in MLC NAND flash memory where the raw bit error rates are high, finding methods to precisely identify BCH/RS algorithms are of significant importance and will be the topic of future work. Acknowledgments This work is supported by a grant from the Natural Science Foundation of He’nan Scientific Committee of China (No. 112300410196). References Alan R Olson, Langlois Denis J. Solid state drives data reliability and lifetime. Online, www.imation.com/PageFiles/83/SSD-ReliabilityLifetime-White-Paper.pdf; April 2008. Breeuwsma M, de Jongh M, Klaver C, van der Knijff R, Roeloffs M. Forensic data recovery from flash memory. Small Scale Digital Device Forensic Journal June 2007;1(1):1–17. Calhoun WC, Coles D. Predicting the types of file fragments. In: 8th annual DFRWS conference; August 2008. Baltimore, MD.

David Billard, Hauri Rolf. Making sense of unstructured flash-memory dumps. In: Proceedings of the 2010 ACM symposium on applied computing; March 2010. USA, New York. Eric D. Trends in NAND flash memory error correction. Online, www. cyclicdesign.com/whitepapers/Cyclic_Design_NAND_ECC.pdf; June 2009. Fiorillo Salvatore. Theory and practice of flash memory mobile forensics. Online, the 7th Australian Digital Forensics Conference, ; 2009. Gal E, Toledo S. Algorithms and data structures for flash memories. ACM Computing Survey 2005;37:138–63. James Luck, Stokes Mark. An integrated approach to recovering deleted files from NAND flash data. Small Scale Digital Device Forensic Journal June 2008;2(1):1–13. Jie Tang, Liu Shaoshan, Liu Chen, et al. Prefetching in embedded mobile systems can be energy-efficient. IEEE Computer Architecture Letters February, 2011;10(1):8–11. Klaver C. Windows mobile advanced forensics. Digital Investigation May 2010;6:147–67. Liu W, Rho J, Sung W. Low-power high-throughput BCH error correction VLSI design for multi-level cell NAND flash memories. In: Proc. Int. Workshop SiPS; 2006. p. 248–53. Micron. NAND flash 101: an introduction to NAND flash and how to design it in to your next product. Online, http://download.micron. com/pdf/technotes/nand/tn2919.pdf; 2006. Samsung Electronics. Datasheet of K9F1G08U0M NAND flash memory/ 1GBit (128M* 8Bits). Online, http://www.datasheets.org.uk/. Samsung_1. ECC algorithm(512 bytes). Online, www.elnec.com/sw/ samsung_ecc_algorithm_for_512b.pdf; June 2005. Samsung_2. m NAND flash ECC algorithm(256 Byes). Online, blogimg. chinaunix.net/blog/upfile2/080702112233.pdf; June 2004. Scott C. What types of ECC should be used on flash memory. Online, www.spansion.com/Support/AppNotes/Types_of_ECC_Used_on_ Flash_AN.pdf; November 2007. Toshiba Electronics. Datasheet of TC58NVG0S3AFT NAND E2PROM/1GBit (128M* 8Bits). Online, http://www.datasheets.org.uk/. Willassen S. Forensic analysis of mobile phone internal memory. Advances in digital forensics. IFIP International Federation for Information Processing March 2006;194:191–204. Willassen H Radke. Variable sector-count ECC. Online, http://www. google.com/patents/; September 2007. Pub.No.: US 2007/0226592 A1.