• Journal of the Korea Institute of Information Security & Cryptology
• /
• v.23 no.5
• /
• pp.947-955
• /
• 2013

Most of the enterprise information is stored in the database. Therefore, in order to investigate the company's criminal behavior, forensic analysis is important for the database and delete record is a need to develop recovery techniques. This paper is explained structure of the oracle database tablespace file and analyzed system tables that stored table information. Further, we suggests a method of recovery for deleted record in oracle tablespace.

• KSII Transactions on Internet and Information Systems (TIIS)
• /
• v.11 no.3
• /
• pp.1557-1569
• /
• 2017

In recent times, the Internet of Things (IoT) has rapidly emerged as one of the most influential information and communication technologies (ICT). The various constituents of the IoT together offer novel technological opportunities by facilitating the so-called "hyper-connected world." The fundamental tasks that need to be performed to provide such a function involve the transceiving, storing, and analyzing of digital data. However, it is challenging to handle voluminous data with IoT devices because such devices generally lack sufficient computational capability. In this study, we examine the IoT from the perspective of security and digital forensics. SQLite is a light-weight database management system (DBMS) used in many IoT applications that stores private information. This information can be used in digital forensics as evidence. However, it is difficult to obtain critical evidence from IoT devices because the digital data stored in these devices is frequently deleted or updated. To address this issue, we propose Schema Pattern-based Recovery (SPaRe), an SQLite recovery scheme that leverages the pattern of a database schema. In particular, SPaRe exhaustively explores an SQLite database file and identifies all schematic patterns of a database record. We implemented SPaRe on an iPhone 6 running iOS 7 in order to test its performance. The results confirmed that SPaRe recovers an SQLite record at a high recovery rate.

• Journal of the Korea Institute of Information Security & Cryptology
• /
• v.26 no.1
• /
• pp.125-134
• /
• 2016

MySQL database is currently used by many users and It has gained a big market share in the database market. Even though MyISAM storage engine was used as a default storage engine before, but records recovery method does not existed. Deleted records have a high possibility for important evidence and it is almost impossible to determine that investigators manually examine large amounts of database directly. This paper suggests the universal recovery method for deleted records and presents the experimental results.

• KIPS Transactions on Computer and Communication Systems
• /
• v.6 no.12
• /
• pp.487-496
• /
• 2017

In MySQL InnoDB, there are two ways of storing data. One is to create a separate tablespace for each table and store it separately. Another is to store all table and index information in a single system tablespace. You can use this information to recover deleted data from the record. However, in most of the current database forensic studies, the former is actively researched and its structure is analyzed, whereas the latter is not enough to be used for forensics. Both approaches must be analyzed in terms of database forensics because their storage structures are different from each other. In this paper, we propose a method for recovering deleted records in a method of storing records in IBDATA file, which is a single system tablespace. First, we analyze the IBDATA file to reveal its structure. And introduce delete record recovery algorithm which extended to an unallocated page area which was not considered in the past. In addition, we show that the recovery rate is improved up to 68% compared with the existing method through verification using real data by implementing the algorithm as a tool.

• KIPS Transactions on Computer and Communication Systems
• /
• v.6 no.2
• /
• pp.59-66
• /
• 2017

MySQL database is the second place in the market share of the current database. Especially InnoDB storage engine has been used in the default storage engine from the version of MySQL5.5. And many companies are using the MySQL database with InnoDB storage engine. Study on the structural features and the log of the InnoDB storage engine in the field of digital forensics has been steadily underway, but for how to restore on a record-by-record basis for the deleted data, has not been studied. In the process of digital forensic investigation, database administrators damaged evidence for the purpose of destruction of evidence. For this reason, it is important in the process of forensic investigation to recover deleted record in database. In this paper, We proposed the method of recovering deleted data on a record-by-record in database by analyzing the structure of MySQL InnoDB storage engine. And we prove this method by tools. This method can be prevented by database anti forensic, and used to recover deleted data when incident which is related with MySQL InnoDB database is occurred.

• Journal of the Korea Society of Computer and Information
• /
• v.6 no.2
• /
• pp.27-33
• /
• 2001

In this thesis, we present a simple and efficient recovery method, called ARIES/SR(ARIES/Selective Redo) which is based on ARIES(Algorithm for Recovery and Isolation Exploiting Semantics) ARIES performs redo for all updates done by either nonloser transaction or loser transaction, and thus significant overhead appears during restart after a system failure. To reduce this overhead, we propose ARIES/SR recovery algorithm. In this algorithm, to reduce the redo operations, redo is performed, using log record for updates done by only nonloser transaction. Also selective undo is performed. using log record for update done by only loser transaction for reducing recovery operation.

• Journal of the Korea Institute of Information Security & Cryptology
• /
• v.25 no.5
• /
• pp.1143-1151
• /
• 2015

Extensible Storage Engine (ESE) database is a database developed by Microsoft. This database is used in web browser like Internet Explorer, Spartan and in Windows system with Windows Search, System Resource Usage Monitor. Previous ESE database viewer can display an incorrect result and can't read the file depending on collected environment and status of files. And the deleted record recovery tool is limited to some program and cannot recover all tables. This paper suggests the universal recovery method for deleted records and presents the experimental results through development of tool.

• Journal of the Korea Institute of Information Security & Cryptology
• /
• v.21 no.3
• /
• pp.143-154
• /
• 2011

SQLite is a small sized database engine largely used in embedded devices and local application software. The availability of portable devices, such as smartphones, has been extended over the recent years and has contributed to growing adaptation of SQLite. This implies a high likelihood of digital evidences acquired during forensic investigations to include SQLite database files. Where intentional deletion of sensitive data can be made by a suspect, forensic investigators need to recover deleted records in SQLite at the best possible. This study analyzes data management rules used by SQLite and the structure of deleted data in the system, and in turn suggests a recovery Tool of deleted data. Further, the study examines major SQLite suited software as it validates feasible possibility of deleted data recovery.

• Proceedings of the IEEK Conference
• /
• 2002.07a
• /
• pp.429-432
• /
• 2002

The existing recovery technique using the logging technique in the client/sewer database system only administers the log as a whole in a server. This contains the logging record transmission cost on the transaction that is executed in each client potentially and increases network traffic. In this paper, the logging technique for redo-only log is suggested, which removes the redundant before-image and supports the client-based logging to eliminate the transmission cost of the logging record. Also, in case of a client crash, redo recovery through a backward client analysis log is performed in a self-recovering way. In case of a server crash, the after-image of the pages which needs recovery through simultaneous backward analysis log is only transmitted and redo recovery is done through the received after-image and backward analysis log. Also, we select the comparing model to estimate the performance about the proposed recovery technique. And we analyzed the redo and recovery time about the change of the number of client and the rate of updating operation.

• Journal of KIISE:Databases
• /
• v.28 no.3
• /
• pp.494-511
• /
• 2001

In the environment that database management systems manage disk spaces for storing databases directly, this paper proposes a correct and efficient scheme of performing pending actions for the removal of database files. As for performing pending actions, upon performing recovery, the recovery process must identify unperformed pending actions of not-yet-terminated transactions and then perform those actions completely. Making the recovery process identify those actions through the analysis of log records in the log file is the basic idea of this paper. This scheme, as an extension of the execution of transactions, fuzzy checkpoint, and recovery of ARIES, uses the following methods: First, to identify not-yet-terminated transactions during recovery, transactions perform pending actions after writing 'pa_start'log records that signify both the commit of transactions and the start of executing pending actions, and then write 'eng'log records. Second, to restore pending-actions-lists of not-yet-terminated transactions during recovery, each transaction records its pending-actions-list in 'pa_start'log record and the checkpoint process records pending-actions-lists of transactions that are decided to be committed in 'end_chkpt'log record. Third, to identify the next pending action to perform during recovery, whenever a page is updated during the execution of pending actions, transactions record the information that identifies the next pending action to perform in the log record that has the redo information against the page.