Web hosting

Tuesday, July 3, 2012

iPod Nano Device Sanitisation

Continuing my work on my, "Cloud and Internet Security" report. I'll revise my earlier estimate and say that its likely to be 500+ pages though the scope will depend on other factors. One of the issues that I wanted to explore was mobile device backup and sanitisation. In particular my iPod Nano. It sounds easy but if you haven't got a recent backup,  you're aware of how strongly iTunes and iPod devices are integrated, and have taken a look at the file directory structure of an iPod you'll realise just how awkward this can be.

Actual music files are stored on the device in the following format:

The command, "file ZRJR.mp3" yields the following:
ZRJR.mp3: Audio file with ID3 version 2.2.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo

knoppix@system:~/iPod_Control/iTunes/iTunes Library.itlp$ file *
Dynamic.itdb:       SQLite 3.x database
Extras.itdb:        SQLite 3.x database
Genius.itdb:        SQLite 3.x database, user version 2
Library.itdb:       SQLite 3.x database, user version 23
Locations.itdb:     SQLite 3.x database
Locations.itdb.cbk: data


Plugging the device in under Linux and mounting as as a USB mass storage device works but so does iPod/iPhone Explorer under Windows as well (though they have some quirks that need to be fixed (I picked up some unhandled exception during my experimentation)). They remind me a lot of Explore2FS which we had to use in the early days of Windows/Linux interoprability. They also allow you to drag and drop though conversion from stored file format to MP3 will take some time. 

TeraCopy (a more optimal version of Windows Explorer's copy functionality) sufferred from a number of stalls and the only notification that I had was a balloon popup on the toolbar indicating that it was due to the process of conversion. Would have liked to see something more informative regarding progress.

Some of the main database table structures extracted from various onboard files are provided below (This was extracted by using a SQLite Browser/Manager and then exporting it to SQL code.).

CREATE TABLE album (pid INTEGER NOT NULL, kind INTEGER, artwork_status INTEGER, artwork_item_pid INTEGER, artist_pid INTEGER, user_rating INTEGER, name TEXT, name_order INTEGER, all_compilations INTEGER, feed_url TEXT, season_number INTEGER, is_unknown INTEGER DEFAULT 0, has_songs INTEGER DEFAULT 0, has_music_videos INTEGER DEFAULT 0, sort_order INTEGER DEFAULT 0, artist_order INTEGER DEFAULT 0, has_any_compilations INTEGER DEFAULT 0, sort_name TEXT, artist_count_calc INTEGER DEFAULT 0 NOT NULL, PRIMARY KEY (pid));

CREATE TABLE artist (pid INTEGER NOT NULL, kind INTEGER, artwork_status INTEGER, artwork_album_pid INTEGER, name TEXT, name_order INTEGER, sort_name TEXT, is_unknown INTEGER DEFAULT 0, has_songs INTEGER DEFAULT 0, has_music_videos INTEGER DEFAULT 0, PRIMARY KEY (pid));

CREATE TABLE avformat_info (item_pid INTEGER NOT NULL, sub_id INTEGER NOT NULL DEFAULT 0, audio_format INTEGER, bit_rate INTEGER DEFAULT 0, sample_rate REAL DEFAULT 0, duration INTEGER, gapless_heuristic_info INTEGER, gapless_encoding_delay INTEGER, gapless_encoding_drain INTEGER, gapless_last_frame_resynch INTEGER, analysis_inhibit_flags INTEGER, audio_fingerprint INTEGER, volume_normalization_energy INTEGER, PRIMARY KEY (item_pid,sub_id));

CREATE TABLE category_map (id INTEGER NOT NULL, category TEXT NOT NULL, PRIMARY KEY (id), UNIQUE (category));
CREATE TABLE composer (pid INTEGER NOT NULL, name TEXT, name_order INTEGER, sort_name TEXT, is_unknown INTEGER DEFAULT 0, has_music INTEGER DEFAULT 0, PRIMARY KEY (pid));
CREATE TABLE genre_map (id INTEGER NOT NULL, genre TEXT NOT NULL, genre_order INTEGER DEFAULT 0, is_unknown INTEGER DEFAULT 0, has_music INTEGER DEFAULT 0, artist_count_calc INTEGER DEFAULT 0 NOT NULL, album_count_calc  INTEGER DEFAULT 0 NOT NULL, PRIMARY KEY (id), UNIQUE (genre));

CREATE TABLE item (pid INTEGER NOT NULL, revision_level INTEGER, media_kind INTEGER DEFAULT 0, is_song INTEGER DEFAULT 0, is_audio_book INTEGER DEFAULT 0, is_music_video INTEGER DEFAULT 0, is_movie INTEGER DEFAULT 0, is_tv_show INTEGER DEFAULT 0, is_ringtone INTEGER DEFAULT 0, is_voice_memo INTEGER DEFAULT 0, is_book INTEGER DEFAULT 0, is_rental INTEGER DEFAULT 0, is_itunes_u INTEGER DEFAULT 0, is_digital_booklet INTEGER DEFAULT 0, is_podcast INTEGER DEFAULT 0, date_modified INTEGER DEFAULT 0, date_backed_up INTEGER DEFAULT 0, year INTEGER DEFAULT 0, content_rating INTEGER DEFAULT 0, content_rating_level INTEGER DEFAULT 0, is_compilation INTEGER, is_user_disabled INTEGER DEFAULT 0, remember_bookmark INTEGER DEFAULT 0, exclude_from_shuffle INTEGER DEFAULT 0, part_of_gapless_album INTEGER DEFAULT 0, chosen_by_auto_fill INTEGER DEFAULT 0, artwork_status INTEGER, artwork_cache_id INTEGER DEFAULT 0, start_time_ms REAL DEFAULT 0, stop_time_ms REAL DEFAULT 0, total_time_ms REAL DEFAULT 0, total_burn_time_ms REAL, track_number INTEGER DEFAULT 0, track_count INTEGER DEFAULT 0, disc_number INTEGER DEFAULT 0, disc_count INTEGER DEFAULT 0, bpm INTEGER DEFAULT 0, relative_volume INTEGER, eq_preset TEXT, radio_stream_status TEXT, genius_id INTEGER DEFAULT 0, genre_id INTEGER DEFAULT 0, category_id INTEGER DEFAULT 0, album_pid INTEGER DEFAULT 0, artist_pid INTEGER DEFAULT 0, composer_pid INTEGER DEFAULT 0, title TEXT, artist TEXT, album TEXT, album_artist TEXT, composer TEXT, sort_title TEXT, sort_artist TEXT, sort_album TEXT, sort_album_artist TEXT, sort_composer TEXT, title_order INTEGER, artist_order INTEGER, album_order INTEGER, genre_order INTEGER, composer_order INTEGER, album_artist_order INTEGER, album_by_artist_order INTEGER, series_name_order INTEGER, comment TEXT, grouping TEXT, description TEXT, description_long TEXT, collection_description TEXT, copyright TEXT, track_artist_pid INTEGER DEFAULT 0, physical_order INTEGER, has_lyrics INTEGER DEFAULT 0, date_released INTEGER DEFAULT 0, PRIMARY KEY (pid));

CREATE TABLE item_to_container (item_pid INTEGER, container_pid INTEGER, physical_order INTEGER, shuffle_order INTEGER);

CREATE TABLE video_info (item_pid INTEGER NOT NULL, has_alternate_audio INTEGER, has_subtitles INTEGER, characteristics_valid INTEGER, has_closed_captions INTEGER, is_self_contained INTEGER, is_compressed INTEGER, is_anamorphic INTEGER, is_hd INTEGER, season_number INTEGER, audio_language INTEGER, audio_track_index INTEGER, audio_track_id INTEGER, subtitle_language INTEGER, subtitle_track_index INTEGER, subtitle_track_id INTEGER, series_name TEXT, sort_series_name TEXT, episode_id TEXT, episode_sort_id INTEGER, network_name TEXT, extended_content_rating TEXT, movie_info TEXT, PRIMARY KEY (item_pid));

My guess is that they used the:


structure as a means of avoiding filename clashes. iTunes basically manages various files and databases to keep track of where everything is. While its clear that there are alternatives they are not always perfect (I manually deleted a file from a my iPod and one of them was unable to correctly update the database. There has been some difficulty in the Open Source world with reverse engineering the details obviously and one of the solutions I've seen was adding/removing files using another program and then plugging it into iTunes to have it update its internal databases but you have to wonder about the logic of this as you're just adding another moving part to the already complex mix/interplay.) and have to be reverse engineered which can be time consuming and difficult as Apple continue to increase their use of anti-reverse engineering technologies (The more you dig the more you realise how drastically some organisation's thinking can veer off of what you believe to the most sensible/elegant option. During my sanitisation experiment a number of files kept on showing as being recoverable. My guess is that it has to do with the way in which files/directories are extracted and manipulated rather than remnant data though. You also obviously need to factor in design compromises and commercial considerations as well.).


It seems clear that the device itself is built off of industry standard software/hardware. Brilliantly integrated and packaged though. Underlying filesystem format is either HPFS or FAT32 depending on the operating system from which the device is setup from.

Tried using various wiping programs. However, it soon became clear that there  other issues at play here. Almost like there's another layer in between the operating system and the underlying filesystem. Not sure whether this is limited to my system (I have a Windows system that is dedicated to pure experimentation so I can't be entirely sure about it being true to other's experiences. I seemed to have no issues with interfacing with the underlying filesystem on Linux but that's not a 'standard environment'.) though.

AxCrypt - Shred and Delete
Shredding of ''????" failed,
A device attacked to the system is not functioning.

Eraser - Erase
Error - The file or directory is not a reparse point. (Exception from HRESULT: 0x80071126)

A file or directory can contain a reparse point, which is a collection of user-defined data. The format of this data is understood by the application which stores the data, and a file system filter, which you install to interpret the data and process the file. When an application sets a reparse point, it stores this data, plus a reparse tag, which uniquely identifies the data it is storing. When the file system opens a file with a reparse point, it attempts to find the file system filter associated with the data format identified by the reparse tag. If a file system filter is found, the filter processes the file as directed by the reparse data. If a file system filter is not found, the file open operation fails.

iPod Explorer - Simple Deletion
Obvious that one deletion of file is possible but it doesn't deal with updating the meta-data/database. It still appears in the menuing system but attempting to play results in nothing, not even an error.

Obviously, after deletion I tried various methods of file recovery to see just how effective some of the mechanisms I employed were. As with most standard FAT based filesystems if there were no other intervention 100% file recovery is almost always possible. You need to use a wiping program to truly defend your iPod or other mobile devices against attack from computer forensics programs. 

root@system:/media/sdc1# photorec /log /debug /d photorec
PhotoRec 6.11, Data Recovery Utility, April 2009
Christophe GRENIER

Disk /dev/sdd - 7889 MB / 7523 MiB (RO) - Apple iPod
     Partition                  Start        End    Size in sectors
 1 P FAT32                    0   1  3   127 204 49    1926015 [USER'S IPOD]
168 files saved in photorec directory.
Recovery aborted by the user.
mp3: 148 recovered
tx?: 10 recovered
sqlite: 4 recovered
txt: 3 recovered
mov: 2 recovered
gz: 1 recovered
[ Quit ]

root@system:/media/sdc1# vim /etc/scalpel/scalpel.conf
# MPEG Video
mpg     y       50000000        \x00\x00\x01\xba        \x00\x00\x01\xb9
mpg     y       50000000        \x00\x00\x01\xb3        \x00\x00\x01\xb7

root@system:/media/sdc1# scalpel -v /dev/sdd1 -o /media/sdc1/scalpel
/dev/sdd1:   9.8% |********|  740.0 MB  2:05:55 ETAOPENING /media/sdc1/scalpel/mpg-1-0/00003091.mpg
/dev/sdd1:  10.0% |*******|  750.0 MB  2:06:05 ETAOPENING /media/sdc1/scalpel/mpg-1-0/00003093.mpg
CLOSING /media/sdc1/scalpel/mpg-1-0/00003091.mpg
Kill signal detected. Cleaning up...
CLOSING /media/sdc1/scalpel/mpg-1-0/00003090.mpg
Kill signal detected. Cleaning up...
CLOSING /media/sdc1/scalpel/mpg-1-0/00003089.mpg
Kill signal detected. Cleaning up...
CLOSING /media/sdc1/scalpel/mpg-0-0/00000055.mpg
OPENING /media/sdc1/scalpel/mpg-1-0/00003092.mpg
CLOSING /media/sdc1/scalpel/mpg-1-0/00003092.mpg
/dev/sdd1:  10.1% |*********|  760.0 MB  2:04:56 ETACleaning up...
 Caught signal: Interrupt. Program is terminating early 

Erase Free Space (Eraser) option has reduced the significantly the chances of file recovery even though file integrity recovery indicators state (CopyTransDoctor) that 100% recovery is possible this is certainly not the case. My results indicate that while partial wiping is possible it requires specialised tools and/or knowledge (I've seen some mobile applications that are specifically designed for this purpose) and clearly if you have raw/jailbroken access to the file system you have many options/utilities available to you.

Not surprisingly given these issues, Apple and others have come up with their own wiping/encryption functionality. 

Simulated the following wiping (free space only. To run on the entire device just drop the digit.) algorithms,
- British HMG IS5 (3 passes)
- US DoD 5220.22-M (8-306./E)(3 passes)
by running the following:

dd if=/dev/zero of=/media/sde1/ipod.wipe
cat /dev/zero | tr '\0' '\1' | dd of=/media/sde1
dd if=/dev/urandom of=/media/sde1/ipod.wipe

Note that you will run into the 4GB filesystem limitation with FAT32 so just create a another file to get around this problem. Namely,

dd if=/dev/zero of=/media/sde1/ipod.wipe
dd if=/dev/zero of=/media/sde1/ipod.wipe1
dd if=/dev/zero of=/media/sde1/ipod.wipe2

It seemed to fairly obvious that a single wipe (British HMG IS5 (1 pass) or US DoD 5220.22-M (8-306./E)(1 pass) which basically amounts to a single pass of zeros) was enough to throw off the various programs that I was using to examine the device though (I was only using free and Open Source tools to simulate a worst case scenario.).

- scalpel
- photorec
- testdisk
- Recuva
- Glary Utilities
- diskinv

Not surprisingly, ports, and installations of Linux have been attempted. The main limitations seem to be the anti-reverse engineering technologies implemented by Apple though.

Given the fact that it basically is a USB storage device you can use a lot of standard utilities on the device such as DBAN and BCWipe.

Luckily recovery mode is there for you to be able to restore functionality most of the time (It's fairly easy to trigger. I obviously corrupted the filesystem a number of times through my experiments with dd and also attempting to reformat, use other programs, and operating systems on my device. Just plug it into a computer running iTunes and it'll do a complete reset of the device for you.).


- as usual thanks to all of the individuals and groups who purchase and use my goods and services

Quick Beef Stew Recipe, Random Stuff, and More

This is the latest in my series on quick, easy, and tasty meals:   http://dtbnguyen.blogspot.com/2017/11/chinese-style-congee-jook-recipe...