A Reconstructing Android User Behavior Approach Based On .

2y ago
61 Views
2 Downloads
471.52 KB
9 Pages
Last View : 4d ago
Last Download : 9m ago
Upload by : Grady Mosby
Transcription

2294JOURNAL OF COMPUTERS, VOL. 9, NO. 10, OCTOBER 2014A Reconstructing Android User BehaviorApproach Based on YAFFS2 and SQLiteMing Xu*College of Computer, Hangzhou Dianzi University, Hangzhou, ChinaEmail: mxu@hdu.edu.cnJun Yao, Yizhi Ren, Jian Xu, Haiping Zhang, Ning Zheng, Shiyue LingCollege of Computer, Hangzhou Dianzi University, Hangzhou, ChinaEmail: { renyz, jian.xu, zhanghp, nzheng }@hdu.edu.cnAbstract—Nowadays, a variety of Android user behaviorinformation is automatically stored in SQLite to indicatewhen and what user behavior took places. In this paper, anapproach to reconstruct Android user behavior fromYAFFS2 based on SQLite is proposed. Based on the storagemechanism of YAFFS2 file system and the file structures ofSQLite, all of the SQLite records can be recovered from theAndroid image, regardless of whether the SQLite file hasbeen deleted or not in YAFFS2, and the user behaviors areparsed from those recovered SQLite records; then anAndroid user behavior timeline is constructed forvisualizing based on the time stamp stored in it’s SQLiterecords. The evaluated experiment results show that theproposed method can reconstruct user behavior correctly,and can obtain more user behaviors than Encase to helpinvestigators to complete digital forensic.Index Terms—Digital forensics, Android, YAFFS2, SQLite,User behaviorI. INTRODUCTIONWith the growth in functionality and market share ofAndroid smart phone, increasing numbers of people usethem for day to day activities. In criminal cases, Androidsmart phones often contain relevant communicationinformation about the user, incriminating images, videosor documents transferred from PC. In this paper, wedefine the most common daily events those take place inAndroid as user behavior, such as sending or receiving anSMS or phone call, adding a contact, etc. And a largeamount of user behavior is stored in the SQLite database.In the paper, we only consider the user behavior thatstored in SQLite. Different Android phones havedifferent file systems based on their versions andmanufacturers. There are still many devices that arerunning a lower version than Gingerbread (Android 2.3)in use, the official file system of this kind of Androidsmart-phone is YAFFS2. Therefore, it is significant tohandle such devices that are using YAFFS2. A lot offorensic methods are developed to recover and analyzedata from Android smart phone. But those existingforensic investigation methods performed poorly incollecting data selectively and automatically for userbehavior, mainly reflecting in costing long time at thecollection of data and further prolonging the period of 2014 ACADEMY PUBLISHERdoi:10.4304/jcp.9.10.2294-2302analysis of data. Investigators need to select and analyzedata to reconstruct useful user behavior from largenumber of data. It seriously affects the investigator’swork. Besides, since the capacity of storage media getshigher and user behavior become more diversified, such aphenomenon become gradually worsen.This paper proposes a method to reconstruct Androiduser behavior based on YAFF2 and SQLite, and constructa user behavior timeline. Unlike the existing investigationmethods, the proposed method can reconstruct userbehavior correctly, based on events which consist of thebehaviors users had done at a specific time. Besides, wedeveloped a visualized tool to display user behavior,making the forensic investigation more convenient.This paper is structured as follows: Section2 introducessome related work; the forensic-friendly specifics ofSQLite and YAFFS2 are presented briefly in Section3; InSection4, we propose a method of reconstructing userbehavior from YAFFS2 and constructing the userbehavior timeline; Section5 implements an Androidsmart-phone forensics system and Section6 describes theevaluated experiment. The paper ends up with thediscussion of the future works and conclusions (Section7).II. RELATED WORKAlthough there are some previous researches wererecovering and analyzing user data from Android smartphone, they are still insufficient in recovering orvisualizing user data. This section will discuss theexisting researches about recovering and visualizing userdata from Android.A study conducted by Ming Xu [1] attempted torecover files, reconstruct file system and recover theirprevious history versions trace from YAFFS2 based onmetadata. For recovering all files based on metadata,even damaged files can be recovered. However, someinformation stored in the damaged file cannot to beobtained, and investigators need to select useful file fromlarge number of file.Another method to recover history records for SQLitedatabase was suggested by Beibei Wu [2]. While theobjective of deleted SQLite file recovery is on the line ofMing Xu’s work. In this paper, an algorithm based onrollback journal and metadata to recover deleted SQLite

JOURNAL OF COMPUTERS, VOL. 9, NO. 10, OCTOBER 2014file was proposed. However, the information stored in thedamaged SQLite database file still cannot to be obtained.A tool called ‘ADEL’ (Android Data Extractor Lite)was designed by Michael Spreitzenbarth [3]. It canautomatically dump predefined SQLite database filesfrom Android devices and extract the contents stored inthe dumped database. However, the tool can only obtainthe data contained in Android devices and it cannotrecover the deleted records of SQLite database files.Another tool called ‘DFRC USER BEHAVIOURANALYZER’ was developed by Namheun Son [4]. Itcollects events from computer and smart-phone toanalyze users’ behavior patterns. This tool does notprovide a method to recover data, it is used to analyze thedata that already recovered and it only supports iOS ofiPhone.Several commercial forensic tools have beendeveloped for mobile phones, including Oxygen ForensicSuite [5], EnCase [6] and MOBILedit! [7]. Additionally,hardware solutions for forensic analysis such as XRY [8]are available. The tool implemented by us in this paperdoesn’t provide all the functions of those existing tools.This paper aims to reconstruct user behavior correctlyfrom YAFFS2 and visualize its timeline for theconvenience of investigators to complete digital forensic.This paper depicts the specifics of storage mechanismof YAFFS2 and internal structure of SQLite on NANDflash, and proposes a method to reconstruct userbehaviors from YAFFS2. Meanwhile a timeline tool,which can reconstruct user behavior correctly andcompletely, is designed to visualize user behavior data forinvestigators.III. SPECIFICS OF YAFFS2 AND SQLITEA. YAFFS2For smart phones, hard disks are too large in size, toofragile and too high in power consumption to utilize inreality. In contrast, flash memory provides fast readaccess time and better kinetic shock resistance than harddisk. There are two fundamentally different types of flashmemory: NOR (Not-OR) and NAND (Not-AND), whereNOR is bit-addressable, and NAND is block addressable[9]. NOR memory can be used like RAM, with everysingle bits being addressed and applications can rundirectly from it. NOR is low density, offers slow writesand fast reads. NAND cannot address individual bit, andmust access blocks of memory through a controller(Myers, 2008) [10]. Nevertheless, NAND is low cost,high density and offers fast writes and slow reads [11].Android (version lower than 2.3) mobile phone’s internalmemory is a NAND flash chip using YAFFS2 file systemto manage data.NAND flash memory contains three logical structures:flash erasable zone, flash block and flash page. The flasherasable zone is the unit of managing bad block, becausethe NAND flash almost contains bad block. A flasherasable zone contains one or more flash blocks, and aflash block is comprised of 32, 64 or 128 flash pages. Theflash page is the mini-addressable unit in NAND. 2014 ACADEMY PUBLISHER2295A flash page contains two parts: usable area and spareor Out Of Band (OOB) area. The usable area stores theuser data while the OOB area stores NAND drive data. Ina flash page, the usable area and OOB area has a differentsize based on their manufacturers. For most Androiddevices, the usable area contains 2048 bytes while theOOB/spare area contains 64 bytes, where various tagsand metadata are stored in blocks.a. Block and chunk allocation of YAFFS2YAFFS2 use the chunk that has the same size with theusable area of a NAND flash page as the mini-allocationunit to store data. Usually the NAND drive using only aportion of the OOB area of a NAND flash page, the restportion of the OOB area stores YAFFS2’s meta-data.YAFFS2 allocates the block and chunk in sequence:anytime there is only one the allocating block that istermed the allocation block. After finding the block, itwill allocate chunks for the file sequentially from theallocation block. When the allocating block runs out ofchunks, if there are other block not in use, the block areused to become the allocation block sequentially.Otherwise, YAFFS2 will recycle the dirtiest blockaccording to garbage collection and make the recycledblock to become the allocation block.Because NAND flash only sustain a limited number ofwrites and erases, In order to increase service time ofNAND flash, YAFFS2 will not rewrite directly but writedata to a new chunk when data stored in a chunkmodified.b. File storage mechanism of YAFFS2In YAFFS2, all types of data (directory, regular datafile, hard link, soft link, etc.) are treated as objects. Eachobject is stored in the form that is composed of an Objectheader chunk and a plurality of Data chunks. Data chunkcontains data of a file, while Object header chunk is usedto store the meta-data of an object (the owner ofID, group ID, object size, object type, object name, etc.).YAFFS2 stores a file on the NAND flash memory likethis: when a new file needs to be stored, it will allocate aObject header chunk with a ObjectType and a specificobjectID which are stored in OOB area of the Objectheader chunk. Each file has different objectID. TheObject header chunk contains the file’s meta-data such asfile name, time stamps (access time/modified time/createtime), length of the file, etc. Data chunks following withThe Object header chunk are allocated to store file’s data.Each Data chunk can be organized by chunked andChunkType which are stored in OOB area of the Datachunk.When a file is modified, YAFFS2 will not rewritedirectly but write data to a new chunk. This nonoverwritten strategy is named “out-of-place-write”.YAFFS2 will allocate a new Object header chunk withnew information to indicate this operation and a pluralityof Data chunk to store the update data. So an Objectheader chunk with new information can be used toindicate an operation. Even though a file is deleted,YAFFS2 will never rewrite the Data chunk directly.

2296YAFFS2 stored the meta-data in OOB area of Objectheader chunk and Data chunk, such as objectID,ObjectType, chunkID, ChunkType, sequence number andbytenum, etc. ObjectID indicates which object a chunkbelongs to; ObjectType indicates that an object is a file ora directory (file: 0x10/directory: 0x30); chunkID tellswhere the chunk belongs within an object; ChunkType isused to illustrate that this chunk is a data chunk or objectheader chunk (Object header: 0x80/Data: 0x00);sequence number increases by 1 when a block is allocatedand every chunk in that block shares the same number, soall the allocated blocks can be organized in chronologicalorder by this special tag; bytenum shows the number ofbytes of valid data in a data chunk.B. Internal Structure of SQLiteThe SQLite database file tends to become fragmentedbecause of “out-of-place-write” strategy of YAFFS2.Thus, the most efficient method to obtain the SQLiterecords for reconstructing user behaviors is to search bythe records themselves and ignore all the databasestructure. To do this, knowledge of their internal structureis required.Essentially, SQLite database is stored in segments,called pages [12]. A SQLite database is composed ofmultiple B-trees, and every B-tree takes a full page atleast. One B-tree for each table and index, structured asB-trees for index, and B trees for table. Each table orindex in a SQLite database has a root page that definesthe location of its first page. The root pages for allindexes and tables are stored in the sqlite master table.The sqlite master table is a system table that containsinformation about all the table, view, index, and trigger inthe database. And the sqlite master table has a fixedstructure: sqlite master (type TEXT, name TEXT,tbl name TEXT, rootpage INTEGER, sql TEXT), thetype field is one of table, view, index, and trigger; thename and tbl name field is the table name for a table; therootpage field is the root page of the table; the sql fieldstores the SQL text related to how to create the table.Furthermore, the root and internal pages of B trees onlycontain only navigation information and the table data(database records) which are stored in leaf pages, asshown in Figure.1 (Owens, 2010, page 305). We canobtain the SQLite records according to the SQL text thatstored in the sqlite master table ignoring B tree structure.The SQLite record is stored in binary form using aspecialized record format that describes all the fields inthe record, it has the following sequential structure: therecord size, the id value, the header and the data segment(D1 to DN), as shown in Figure. 2. The record size onlyincludes the size of header and data segment. The headercomprises the header size (hsize) and an array of fieldtypes and sizes (F1 to FN), which describes each fieldstored in the data segment. The hsize and the array, aswell as the id, are represented as a variable-sized 64-bitinteger value. For this kind of value, SQLite uses acompression method based on Huffman coding [13].It is important to note that the record size, the id, andthe header size are stored using Huffman coding.However, fields’ sizes and data do not use the 2014 ACADEMY PUBLISHERJOURNAL OF COMPUTERS, VOL. 9, NO. 10, OCTOBER 2014compression method, the array of types and sizes in theheader uses one value to identify the field type and thesize. Table I lists the entry specifies data type and the sizeof its corresponding field value.Figure 1. B tree structure of SQLite databases (Owens, 2010, page305)Figure 2.Record structureType Value0N in 1.45678-11N 12 and evenN 13 and oddTABLE I.FIELD TYPE VALUESMeaningNULLSigned integerSigned integerSigned integerIEEE floatReserved for future useBLOBTEXTLength of Data0N688N/A(N-12)/2(N-13)/2C. User Behavior in AndroidThere are lots of events taking place in Android smartphone, but 5 kinds of user behaviors more important: Callhistory, SMS/MMS, Location info, Web Use History [14]and SNS (Social Networking Services) [15]. Currently,the application software usually uses SQLite to save theseuser behaviors information in Android. The saved filedirectory and stored table about 5 kinds of user behaviorsare described in Table II.It is possible to obtain the information that when andwith whom users had a phone call by analyzing callhistory. Contact information and call history informationare stored in contacts2.db on the user data partition. Inthe contacts2.db, the table calls contain detailedinformation of call history, such as call time, call durationand the number of incoming and outgoing calls. And thedetailed information of contacts is stored in the table data.For SMS/MMS, the information of when, about what andwith whom users talked, can be obtained as well. UnlikeCall History, it is possible to know the contents of theirconversation, so it can be used as very important data.The information of SMS/MMS is stored in mmssms.db onthe user data partition. The table sms store all data aboutSMS and the table pdu store the detailed information ofMMS. When an application within map information suchas Google map and Browser is used, the application will

JOURNAL OF COMPUTERS, VOL. 9, NO. 10, OCTOBER 20142297record data indicating the present location, which can beused to detect the user's location. The locationinformation is stored in multiple SQLite database files onthe user data partition. The cachedPositions.db containsthe location information which is stored in the browser,and the search history.db contains the locationinformation which was ever searched in the Google map.Browser is a good source to find out sites and searchwords that users have visited and used, and the Android’sdefault browser stores the browser data in browser.db onthe user data partition. The table bookmark contains bothbookmarks and browser histories in versions 2.x of theAndroid platform, and the table searches contain thedefault browser’s search histories. People use SNSservices like Skype, Facebook, Twitter and Sina-Weiboon their smart-phone, and those services includemeaningful data, such as sending text messages and freefor-charge calls. Apparently, it is inevitable to analyzeSNS data. These applications also store important userdata stored in SQLite database. We have not thoroughlyinspected these applications' mechanism of storing data.device is the following: Put the device in developer mode and connect thedevice with a computer; Add "NANDdump" command using AndroidDebug Bridge (ADB); View the MTD partitions using command "adbshell cat"; Acquiring the image using "NANDdump".In this work, "NANDdump" instruction is used toacquire the complete data partition image of androidphone. The 1.18 version of BusyBox [18] contain thecommand of "NANDdump". In order to support"NANDdump" command for the device, the ADB tool[19] can be used to install BusyBox on the systempartition, and this process only affects the systempartition [20].As a result, the integrity of data partition, which is theresearch object in most forensic task, can be retained bitby-bit. A bit-by-bit image allows an investigator toconduct analysis on the entirety of the data, such asdeleted data, which is a great role in any investigation.IV. THE PROPOSED METHODB. Pre-processingThe pre-processing is such a process that obtains eachchunk’s meta-data that stored in OOB area in theallocation order on chip. From the perspective of thestorage mechanism of YAFFS2, each block’s sequencenumber of a flash memory are allocated in ascendingorder, and each chunk have the same sequence number ina block. Therefore, we scan the image in the reverse orderof sequence number in our approach. Each chunk’sobjectID, objectType, chunkID, and chunkType can beobtained in our approach according to the OOB tagsobtaining algorithm as pseudo-code show in Algorithm 1.The pre-processing work is completed as follows.Firstly, the sequence number for each block and thecorresponding physical block offset is stored in an arrayof structures bsn[], during scanning each logical block insequence (lines 1-3). Secondly, all the blocks stored inbsn[] are sorted by sequence number from the largest tothe smallest (line 4). Finally, these sorted blocks arescanned from the one with the largest sequence number tothe one with the smallest, and within a block, its chunksare scanned from the last one to the first. During thisprocess, each chunk’s objectID, objectType, chunkID andchunkType are stored into an array of structures pbk[]separately (lines 5-9). Each chunks physical address canbe calculated as below:In this section, we propose a method to obtain usefulinformation in SQLite database file from YAFFS2 andreconstruct user behaviors timeline. The Figure.3 is theframework of the proposed algorithm.Figure 3. The process framework of the proposed method.A. Acquiring ImageBefore starting to analyze internal file system ofandroid phone, it’s needed to obtain the image file of datapartition firstly. There are two main ways to get an imagefrom Android devices—physical and logical. Physicalmethod obtain image that carried out by JTAG [16] andlogical method carried out by using "DD" or"NANDdump" instruction after the android devices haveacquired rooting right.In this paper, we only consider the logical method toobtain the image file of data partition. To carry outlogical imaging, android devices must be rootedbeforehand. "SuperOneClick" [17] was used in this work.Once the devices have acquired rooting right, the mostforensically-sound method of acquiring data from theUser’s dataCall historyContact dataSMSMMSBrowser dataLocation infoSNS Application 2014 ACADEMY PUBLISHERTABLE II.USER DATA STORED IN SQLITESaved file /com.google.android.apps.maps/databases/da destination /search history.db/data/data/com.android. Application Name /databases/SQLite tablecallsdatasmspduBookmark searchesdestination historyhistory

2298JOURNAL OF COMPUTERS, VOL. 9, NO. 10, OCTOBER 2014(1)(2)chunkAddress blockOffset chunkOffset(3)Where i means the location of the chunk which isready to be stored into pbk[], NUM is the number ofchunks in one block, blockOffset is the chunk i’s blocknumber, chunkOffset is the chunk i’s relative offsetnumber in the block, and chunkAddress is the physicaladdress of chunk i.Since the whole chip is scanned reversely inchronological order, we don’t need to consider the spatialsequence.blockOffset bsn[i / NUM ]chunkOffset NUM (i % NUM )ALGORITHM IOOB TAGS OBTAININGALGORITHMAlgorithm 1:OOB Tags Obtaining AlgorithmInput:the imageOutput:the array of structures pbk[]01 for each block in image do /*scan the entire image in order*/02 read sequence number and physical number stored in the array ofstructures bsn[];03 end for04 sort by sequence number from the largest to the smallest for the arrayof structures bsn[];05 for each block in bsn[] do06 for each chunk in block from the last one to the first do07calculate chunk’s physical address by formula (1 3);08read objectID, objectType, chunkID, and chunkType stored in thearray of structures pbk[];09 endfor10 endfor11 return pbk[]C. Recovering SQLite Database Records andReconstructing User BehaviorMost of user behavior data in Android mobile phoneare stored in SQLite database file. In order to reconstructuser behavior, it is necessary to recover SQLite databaserecords about user behavior, and then analyze the lowlevel SQL events corresponding to each user behavior.Two simplified algorithm in pseudo-code are shownbelow. We recognize SQLite database file’s page in thereverse order of sequence number scanning on chipaccording to recovering SQLite database recordsalgorithm as pseudo-code show in Algorithm 2, and weparse records from each page of SQLite according toparsing SQLite database records algorithm as pseudocode show in Algorithm 3.ALGORITHM IIRECOVERING SQLITE DATABASE RECORD ALGORITHMAlgorithm 2: Recovering SQLite Database Records AlgorithmInput:the image;the array of structures pbk[] that stored each chunk’s objectID,objectType, chunkID and chunkType;SqliteName {si si is the ith sqlite database file’s name that you wantto obtain records from it, such as contacts2.db, mmssms.db and so on};Output:Records {ri ri is the ith record we obtained in the sqlitefile}01 i 0;02 while i pbk.length-1 do/*scan the entire image reversely in chronological order*/;03if (pbk[i].chunkType 0x80) and (pbk[i].objectType 0x10) then/*recognize an file’s object header chunk*/04if (the filename SqliteName) then/*Read the filename in object header chunk and determined the sqlitedatabase file*/05Parse the SQLite file’s sqlite master table;/*obtain the SQL text that describes how to create the table and store 2014 ACADEMY PUBLISHERit*/06Extract information such as time stamps, objectID and storethem;07for each chunk k from pbk[i 1] to pbk[pbk.length -1] do08if (k.objectID pbk[i].objectID) then09if (k.chunkType 0x80) and (k.objectType 0x10)then10break;11calculate chunk k’s physical address by formula(4 6);12tempRecords{ti ti is the ith record obtained fromchunk k} Algorithm III (k, SQL text);/*parse record from chunk based on Algorithm 3*/13if k ParsedChunk {pi pi is the ith chunkID ofthe ith chunk has been parsed}; then14if tempRecords Records then15add time stamps obtained from theprevious object header chunk to the record ti Records;16end if17end if18Records Records tempRecords;19ParsedChunk ParsedChunk k.chunkID;20end if21end for22end if23 end if24 i ;25 end while26 return RecordsALGORITHM IIIPARSING SQLITE DATABASE RECORDS ALGORITHMAlgorithm 3: Parsing SQLite Database Records AlgorithmInput : the chunk k of the image and the SQL text obtained fromsqlite master tableOutput:tempRecords {ti ti is the ith record obtained from chunk k}01 read the first 1024 bytes from chunk store in page[];/*SQlite page size is 1024,chunk’s size is 2048*/02 if (page[0] 0x0D) then /* recognize the B tree page*/;03 i 0 and calculate the total records of the file by formula (4);04 while i total records do /*traverses every record in the page */;05calculate the record offset of the i record by formula (5);06for each field,according to SQL text do;07read its content and content’s size store them;08end for;09if content’s size of each field match with Table I then;10tempRecords tempRecords record i;11end if12i ;13end while14 end if15 read the another 1024 byte from chunk store in array of structurespage[];16 redo step 2 to step 14;17 return tempRecordsTo parse the Android image, the pre-processing workis completed as Algorithm 2 and all the chunks arescanned reversely in spatial (lines 1-2). An object headerchunk is recognized by chunkType (chunkType 0x80) inOOB (line 3). The information, such as type,parent objectID, filename, time stamps, objectID and filelength, is extracted from object header chunk. YAFFS2uses type in object headers to distinguish a directory froma normal file.The relationship between a directory and its files isholded by that all the parent objectID of its included filesare equal to the directory’s ObjectID. In order to obtainthe record that related with user behavior, these SQLitedatabase file name need to be known in advance (line 4).These SQLite database files can be recognized by theirmagic number “53 51 4c 69 74 65 20 66 6f 72 6d 61 7420 33 00”. This magic number byte sequence corresponds

JOURNAL OF COMPUTERS, VOL. 9, NO. 10, OCTOBER 2014to the UTF-8 string "SQLite format 3" including the nullterminator character at the end. When a database file isidentified, the table’s SQL text that contains the recordrelated with user behavior can be obtained according tothe fixed format of sqlite master table (line 5).After the SQL text is obtained, the information aboutthe table that contains records about user behavior can beobtained, such as each field’s type and its name. Asmentioned above, YAFFS2 appends an object header todata chunks when some operations (create, modify andappend, etc.) have been done. This means that the chunksbetween the two object headers, stored the updated data,and the time stamps can be used to show when theoperation happened can be obtained from the objectheader chunk (line 6). Not until the next object headerchunk appear, it is necessary to traverse all these chunksthat follow with the object header chunk to obtain allrecord related to operation. The follow chunk have thesame ObjectID with the object header chunk (lines 7-10),each chunk’s physical address can be calculatedaccording to equations 1, 2 and 3 (line 11).When the location of the chunk has been obtained, thework that parsing SQLite database records from thechunk completed as Algorithm 3. The chunk size is 2048bytes, while the SQLite page size default is 1024 bytes.Therefore, when the physical address of chunk isdetermined, we store the following a SQLite page sizebytes in page [] (line 1). The table’s records only store inthe SQLite database file’s B tree, and the B tree page’sfirst byte is 0x0D. If page is a B tree page (lines 2-5),records can be obtained from the page. The total recordnumber can be calculated as below:total records page[3]* 256 page[4](4)In order to obtain each record from the page, the ithrecord offset address from page header can be calculatedas below:record offset page[8 2(i 1)]* 256 page[9 2(i 1)] (5)Then, according to the SQL text, record’s entire field’scontent and size can be obtained (lines 6-8). If eachfield’s size matches with its type, then we stored therecord in a set tempRecords (lines 9-11). For example if afield’s type is TEXT, its size must be an odd numbergreater than 13. Because a SQLite database file hardlycontains two tables with the same SQL text, tempRecordscontain records related to user behavior. When all recordsare obtained from the page, another 1024 bytes in thechunk will be processed in the same way as the first 1024bytes (lines 15-16).After obtaining records from the chunk, we needcontinue follow the steps of Algorithm 2. It is necessaryto check out whether the chunk has been parsed (line 13).If the chunk has been parsed, then it is necessary to checkout whether the chunk contains the deleted record. If thetempRecords contains some records that have not beenobtained, it indicates that there is a delete operation tookplace between the previous object header chunk and theobject header chunk. And because of all the chunks arescanned reversely order of sequence number, the previousobject header chunk contain the time stamps of the deleteoperation taking place. So the time stamps need to be 2014 ACADEMY PUBLISHER2299appended to the record as its DELETE time and store therecord (lines 14-17). If the chunk hadn’t been parsed, allof these records obtained from the chunk will be storeddirectly (lines 18-19). When all chunks in the image havebeen parsed, the recovery work is completed.After all recoverable SQLite records in the databasefile are recovered, user behavior need to be parsed fromthese SQLite record

Android (version lower than 2.3) mobile phone’s internal memory is a NAND flash chip using YAFFS2 file system to manage data. NAND flash memory contains three logical structures: flash erasable zone, flash block and flash page. The flash erasable zone is the unit of managing bad block, because the NAND flash

Related Documents:

Android Studio IDE Android SDK tool Latest Android API Platform - Android 6.0 (Marshmallow) Latest Android API emulator system image - Android 6.0 Android Studio is multi-platform Windows, MAC, Linux Advanced GUI preview panel See what your app looks like in different devices Development environment Android Studio 9

Dial91 Android Edition User Guide 1 About Dial91 Android Edition Dial91 Android Edition is a SIP- based phone for an Android phone. With Dial91 Android Edition (Dial91), you can use the Wi-Fi internet connection on your Android phone to make and receive calls without using your mobile

ADT (Android Development Tool) bundle or ! Eclipse ADT plug-in Android SDK or ! Android studio ! Download earlier SDK versions using SDK manager if needed . Android Virtual Device (AVD) ! Android emulator allows . Android App Essentials ! Layout ! View objects: UI widgets such as buttons, text box etc. .

Android Development Tools ADT A plug-in for Eclipse (see Eclipse) to develop Android applications. Android Operating system for smartphones. Android Market The Android distribution service of mobile applications. Android Lifecycle A model Android uses to handle the lifecycle of an activity in applications.

ANDROID QUICK START GUIDE WELCOME TO ANDROID 1 1 Welcome to Android About Android 5.0, Lollipop Android 5.0, Lollipop is the latest version of Android, the oper-ating system that powers not just phones and tablets, but also wearables, TVs, and even cars. Android 5.0 features a bold and bright new design, 3D graphics

Navigate to https://developer.android.com/studio/index.html and download Android Studio for your appropriate OS. The Android SDK should be included with Android Studio. Make sure you do not choose an Android Studio installation that excludes the Android SDK. Standard download option for Windows OS (above). Alternative

2010 - May: Android 2.2 / Froyo 2010 - Dec: Android 2.3 / Gingerbread 2011 - Jan : Android 3.0 / Honeycomb - Tablet-optimized 2011 - May: Android 3.1 - USB host support 2011 - Nov: Android 4.0 / Ice-Cream Sandwich - merge Gingerbread and Honeycomb 2012 - Jun: Android 4.1 / Jelly Bean - Platform Optimization

An Android Studio SQLite Database Tutorial Previous Table of Contents Next An Android Studio TableLayout and TableRow Tutorial Understanding Android Content Providers in Android Studio eBookFrenzy.com Purchase the fully updated Android 6 Edition of this Android Studio Development Essentials publication in eBook ( 9.99) or Print ( 38.99) format