mra.dbs

Раскрывает свои тайны

Прошло уже больше полгода, а желания садиться и доделывать начатое у меня так и не появилось :) Поэтому я опишу все что мне удалось узнать о формате этого файла.

Открываем в редакторе WinHex файл mra.dbs и ищем там unicode строку mrahistory__


Опытным путем было установлено, что перед строкой обязательно 4 байта 00 00 00 00 и строка должна заканчиваться 75 00 ('u' в юникоде)

Поднявшись выше на 0x16C байт мы видим два четырех байтовых ID:
1 ID - первого сообщения в отправленных
2 ID - последненго сообщения принятого

ID указывает нам на начало двусвязного списка

Берем ID отправленных в данном случае это 0x5E040000 и ищем его в dbs

тут мы видим что 2 id = 0x00000000 это значит что отправленных сообщений больше нет.
Если бы 2 id был бы числом (тут точно сказать не могу но число должно быть не больше 0xFFFF0000) - то он указывал бы нам на следующее исходящее сообщение.

В принятых сообщениях все наоборот

2 ID в последующей цепочке соответствует первому, а заканчивается она если 1 ID = 0x00000000

Формат сообщения такой:
Фиолетовым цветом выделены 8 байт даты в FILETIME формате (Time functions)
Далее идут строки в unicude с завершающим нулем (0x0000): ник, сообщение,
4 байта длинна и unicode строка RTF (Rich Text Format).

Если смотреть смещения от начала ника получается так:

-0x34	1 ID
-0x30	2 ID
-0x28	FILETIME

Формирование цепочки сообщений
Я сразу приведу реальный пример, чтобы было сразу понятно

XXX@mail.ru 0x15DC : 0x057A
[0x15E0 : 0x0000] Люблю metal... (02.11.2010 03:30):
че не спишь?
[0x15E1 : 0x15DC] Настоящий Индеец (02.11.2010 03:30):
кофе налил, за код сел
[0x15E2 : 0x15E0] Люблю metal... (02.11.2010 03:31):
ясно смотри че намутил
http://c0dedgarik.blogspot.com/2010/11/ascii-art.html
[0x15E3 : 0x15E1] Настоящий Индеец (02.11.2010 03:32):
круть
[0x15E9 : 0x15E2] Настоящий Индеец (02.11.2010 03:32):
как определял интенсивность символов?
[0x15EA : 0x15E3] Люблю metal... (02.11.2010 03:33):
никак размер шрифта указываешь и все
[0x15EB : 0x15E9] Настоящий Индеец (02.11.2010 03:33):
а, у тебя 0 и 1
[0x15EC : 0x15EA] Люблю metal... (02.11.2010 03:33):
там код ниже )
[0x15ED : 0x15EB] Настоящий Индеец (02.11.2010 03:33):
я думал там разные символь
[0x057A : 0x15EC] Люблю metal... (02.11.2010 03:34):
не по хакерски
чувак показал дефейс одного турецкого кхакира
и там на черном фоне флаг
аще я опа круть... ведь такое не сложно замутить
[0x0000 : 0x15ED] Люблю metal... (02.11.2010 04:06):
пыщь пыщь

Как видно первый ID указывает нам на отправленные сообщения, второй на принятые.
алгоритм таков:
следующее отправленное сообщение = 1_ID + 1
если мы не находим этот получившийся ID в списке ПЕРВЫХ ID-ов, то
следующее отправленное сообщение = 2_ID - 1 и искать этот ID надо в списке ВТОРЫХ ID-ов

Сейчас я разрабатываю новую версию читалки, но столкнулся с проблемой поиска сообщений. Я основывался поиском по сигнатуре RTF, но как оказалось RTF есть не везде, а 4 байта далеко не уникальное число, которое часто встречается в файле :(