inflex/undark

SQLite3 data extraction / undelete

Undark - SQLite3 database data recovery tool

Features

TODO

Installation

1. Clone the project

   $ git clone https://github.com/inflex/undark.git

2. Build it!

   $ make

Usage

Discussion

IRC Freenode: message inflex

undark's Issues

free(): invalid next size (normal)

Hi, not sure if this project is still being developed (I hope so though!) but I found a bug while reading my sqlite db.
./undark -i my_database.db --no-blobs gives out a few hundred lines of output and then this

free(): invalid next size (normal)
[1]    53420 abort (core dumped)  ./undark -i my_database.db --no-blobs

I dont know a ton about c, but this does seem to be outputting some real data and a lot of data that is garbled. I dont know if this is it reading blobs despite the --no-blobs arg, or if this is expected output. This is a very large sqlite database though (230GB) so maybe this error I am seeing is simply the program running out of memory.

who has more effective way to recover sqlite data?

Wrong character encoding

Hi

Great stuff! But what I've found out, that it works wrong with non-english characters in database. It makes dots out of any for example cyryllic letters:
79,NULL,"[phone]","...... ..........","...... ..........",384,384,"........","
Is there any possibility to fix this? Or to point to it which encoding to use? Thanks.

Incorrect integer decoding (24, 48, 64 bit)

As a minimal example, create the following database:

CREATE TABLE 'simpletable' (
	'name' TEXT,
	'8bitnumber' INTEGER,
	'16bitnumber' INTEGER,
	'24bitnumber' INTEGER,
	'32bitnumber' INTEGER,
	'48bitnumber' INTEGER,
	'64bitnumber' INTEGER
);

INSERT INTO 'simpletable' 
	('name', '8bitnumber', '16bitnumber', '24bitnumber', '32bitnumber', '48bitnumber', '64bitnumber')
	VALUES
	('undark', 117, 322, 110590, 181075936, 20015998341138, 81985529216486895),
	('undark', 15, 242, 45054, 13303776, 2882343476, 320255973501901);

Expected result:

2,"undark",15,242,45054,13303776,2882343476,320255973501901
1,"undark",117,322,110590,181075936,20015998341138,81985529216486895

Output of undark -i (version 0.6):

2,"undark",x15,242,11533898,13303776,0,0
1,"undark",x117,322,28311114,181075936,301989888,16777216

Output of undark -i (version 0.7.1):

2,"undark",x15,242,11533824,13303776,0,0
1,"undark",x117,322,28311040,181075936,301989888,16777216

First Observation:
– 8-bit integer: correct (but with "x")
– 16-bit integer: correct
– 24-bit integer: wrong
– 32-bit integer: correct
– 48-bit integer: wrong
– 64-bit integer: wrong

Second Observation:
Undark’s result for 48- and 64-bit is simply wrong in the first row and 0 in the second row.
Where’s the differece between row 1 and row 2?

Hexdump of rowid 1 (already splitted correctly):
|| 26 || 01 || 08 | 19 | 01 | 02 | 03 | 04 | 05 | 06 || 75 6e 64 61 72 6b | 75 | 01 42 | 01 af fe | 0a ca ff e0 | 12 34 56 78 90 12 | 01 23 45 67 89 ab cd ef ||

Hexdump of rowid 2 (already splitted correctly):
|| 26 || 02 || 08 | 19 | 01 | 02 | 03 | 04 | 05 | 06 || 75 6e 64 61 72 6b | 0f | 00 f2 | 00 af fe | 00 ca ff e0 | 00 00 ab cd 12 34 | 00 01 23 45 67 89 ab cd ||

As we can see, rowid 2’s integer start with nullbytes. Maybe that’s an explanation why 0 is the result of 48- and 64-bit in the second row?

Third Observation:
This third issue has already been fixed in version 0.7.1 and affects only v0.6.
The result of 24-bit integers is not reproducible. Using v0.6 the result of the 24-bit integer changes every time (e.g. of rowid 2): 11533920, 11533825, 11534016, 11533897, …
The first four digits are stable, the last four are changing.