Изображения в каталоге запчастей ETKA
Скачать тоже можно. За деньги. Вопрос суммы.
Я расшифровал все изображения в ЕТКА - файлы в формате png и gif.
Если интересно - пишите в личку.
Особо там нету ничего тяжелого
1. выцыпать файл который расшифровал ETKA - т.е. получаем нормальный файл tiff или png.
2. Исходный (зашифрованный) файл из ETKA
3. т.е. получили нормальный фал рисунок ETKA и зашифрованный. Берм HEX - просмотрщик, Берем калькулятор - сравниваем - и догадываемся чем же они зашифрованы. ;)
Эти файлы мелочь. Идем дальше
---
Есть в ETKA новые рисунки - красивые они zgd-файлах (ну например 409260200.zgd). Походу это архивы. Кто смог сделать - подскажите направление. готов отблагодорить за вознагрождение.
Ага, печалька по ним (
Обратите внимание что размер распакованного архива (это когда вы пишите достаточно переименовать 787035400.zgd в 787035400.zgd.gz и дальше работать как с zip-архивом) отличается от размера распакованного ETKA (ETKA разархивирует их во временную папку windows (это архив gz))
Я думаю тут нужно просить чела, умеющего делать декоддинг (дессасемблирование)
Да я уже три дня гоняю ETKA под отладчиком! Но там столько кода, что сложно найти истину. Еще надстройка mfc42.dll от Microsoft постоянно под ногами путается, мешает исследованию. Всю работу с картинками выполняет LxidDcod.dll, LxidDib.dll. LxidDcod.dll выполняет предварительную расшифровку картинок. sgd не проходят расшифровку, т.е. они не зашифрованы (надо только распаковать zgd). Далее происходит преобразование любой картинки в DIB Bitmap в модуле LxidDib.dll (это необходимо для отображения картинки на экране под виндовс). И тут сильно все перемешано с mfc42.dll, их классами и файловыми потоками.
Возможно вы перехватили этот файл не в тот момент, раньше чем он будет полностью записан. Там же в начале идет рапаковка, файл записывается почти всегда кусками по 16кб, после чего он открывается в другом потоке ETKA, потом во всех потоках закрывается и удаляется.
Давно возился с ними, может и перепутал их.
1. я проверил свои наработки. У меня размеры распакованного фала ЕТКА отличаются от размеров распакованным zip-архиватором!!! Чуть позже еще раз проверю.
2. Если вы утверждаете что размеры совпадают то сравните побайтово, не наблюдается ли закономерность между файлами. Кроме того может сам зип архив перед распаковкой прогнать по XOR_с_ключем?
Скажите а при десассемблировании (при разборе тиф-рисунков), вы сразу увидили шифрацию? Не наблюдается ли подобные действия с sgd-файлами?
И сразу вопрос может dll можно каким нибудь образом использовать для распаковки?!
Явно просматривается конструкция такого вида:
if(ext=='PNG' || ext=='TIF'){
Расшифровать();
}
// Дальнейшая загрузка картинок (преобразование в DIB для вывода на экран)
Можно, но необходимо понять, какие параметры необходимо передать нужной функции.
В модуле LxidDcod.dll необходимо сперва вызвать DECODER_NewDecoderInterface() (без параметров) для инициализации модуля, по завершении работы вызвать DECODER_DeleteDecoderInterface(). Расшифровка и подготовка к выводу на экран всех картинок (в т.ч. tif и png) выполняется функцией DECODER_MakeDib(11 параметров).
Кроме того, в этом модуле есть функции, которые ETKA ни разу не вызывает: DECODER_MakeDibFromFile, DECODER_GetSpecialInfo, DECODER_GetFileInfo.
Смотри, только что поступил другим образом. Восстановил удаленные в ЕТКА - файлы.
И вот теперь опять утверждаю, что файлы .sgd отличаются даже по размеру с файлами unzip:.zgd
И по содержимому тоже - отличаются!!!
готов приобрести у вас методы распаковки zgd-файлов, естественно за вознаграждение
Можете подсказать доку откуда брать чтобы правильно наполнить
Потому что вначале были они (старые картинки) и только потом начали появляться цветные.
О чем вы спрашиваете? о том, какой формат у DIB файла? Необходимо записать в файл:
1. BITMAPFILEHEADER http://msdn.microsoft.com/en-us/library/aa930979.aspx
2. После него сразу идет BITMAPINFO http://msdn.microsoft.com/en-us/library/aa921550.aspx
3. И, собственно, сама картинка.
В принципе, какая разница, в каком формате сохранять? для использования в ВЕБ удобнее сохранить в png, но с ним мне еще надо разбираться. Я выбрал DIB, поскольку он настолько простой, что в нем за 30 минут можно полностью разобраться. Непосредственно данные изображения могут быть одинаковы в png, bmp, tif, dib и многих других форматах, с отличиями только в заголовочных данных. т.е. с таким же успехом можно сохранять и в png без какого-либо преобразования карты пикселей (но при использовании в коммерческих целях, а не для проверки своей программы, преобразовывать все таки придется ради многократного уменьшения веса картинки).
Это я понял. Но у самых новых машин все картинки дублируются: для каждого номера изображения есть tif и zgd файл, хотя можно было делать новые только zgd.
Если вы думаете, что сохранять в формат PNG сложно, могу посоветовать воспользоваться GDI+. Как я понял, вы вручную собрались кодировать файлы, но это не нужно. GDI+ поможет перевести файл из одного формата в другой, или даже из памяти сохранить в PNG.
Готов оплатить подсказки и решения
Формат SGD, насколько мне удалось узнать, используется в одной немецкой ГИС, и сам по себе достаточно навороченный. Изображения в каталоге ETKA используют небольшое подмножество всех предусмотренных функций формата, что делает возможным написание декодера.
Основой изображения служит растровый слой MRCI, поверх которого рисуются векторные элементы (используются для стрелок и надписей).
Способ хранения растровых данных в формате MRCI "плиточный": исходное изображение разбивается на плитки заданного размера, каждая плитка отдельно кодируется. Затем плитки последовательно (слева направо, сверху вниз) пишутся в файл. Плитки по правому и нижнему краям изображения могут иметь размер меньше номинального, если ширина или высота изображения не кратна размеру плитки.
плиток_по_вертикали = ceil(высота_изображения / высота_плитки)
всего_плиток = плиток_по_горизонтали * плиток_по_вертикали
Структура SGD файла
Адреса в SGD файле всегда кратны 4 байтам для удобства работы с ним через отображение памяти. Порядок байт в файле little-endian.
Первые 16 байт занимает заголовок файла:
-------- --- -------- --------
0x00 U32 Магическое значение 0x000a0090
0x04 U16 Номер версии 0x07db
0x06 U16 Номер ревизии 0x0406 или 0x0407
0x08 U32 Неизвестно 0x01020015
0x0c U32 Магическое значение 0x55555555
-------- --- -------- --------
0x4c U32 Количество директорий в SGD файле 3
0x50 U32 Тип директории 2 2
0x54 U32 Абсолютный адрес начала директории 2
0x58 U32 Тип директории 1 1
0x5c U32 Абсолютный адрес начала директории 1
0x60 U32 Тип директории 0 0
0x64 U32 Абсолютный адрес начала директории 0
0x68 U32 Неизвестно 0
0x6c U32 Размер SGD файла
-------- --- -------- --------
0x00 U16 Младшие 16 бит размера директории
0x02 U16 Тип директории 0x63
0x04 U32 Размер директории
0x08 U32 Неизвестно
0x0c U32 Число записей в директории
0x10 U32 Неизвестно
0x14 U32 Неизвестно
0x18 U32 Относительный адрес записи 0
0x1c U32 Относительный адрес записи 1
... ... ...
-------- --- -------- --------
0x00 U16 Размер записи
0x02 U16 Тип записи 0x1a, 0x2d, 0x37 и др.
0x04 U32 Номер записи
0x08 U32 Неизвестно
0x0c U32 Флаги отрисовки (подробнее об этом поле ниже)
0x10 U32 Неизвестно
0x14 U32 Неизвестно
0x18 U32 Неизвестно
-------- ------- --------
0x1a MRCIHEADER Растровый слой в формате MRCI
0x2d POLYLINE2D Ломаная линия
0x37 TEXTLINE2D Текстовая метка
-------- --- -------- --------
0x1c U32 Ширина изображения в пикселях
0x20 U32 Высота изображения в пикселях
... ... ...
0x6c U32 Размер пикселя в байтах 1
0x70 U32 Битовая глубина 8
0x74 U32 Относительный адрес палитры
0x78 U32 Номинальная ширина плитки в пикселях 256
0x7c U32 Номинальная высота плитки в пикселях 256
... ... ...
0x90 U32 Относительный адрес директории с адресами плиток
-------- --- -------- --------
0x00 U16 Размер структуры
0x02 U16 Тип структуры 0x04ef
0x04 U16 Размер пикселя в байтах 1
0x06 U16 Битовая глубина 8
0x08 U32 Количество цветов в палитре 256
Директория с адресами плиток:
-------- --- -------- --------
0x00 U16 Размер структуры
0x02 U16 Тип структуры 0x04ed
0x04 U32 Относительный адрес плитки 0
0x08 U32 Относительный адрес плитки 1
... ... ...
-------- --- -------- --------
0x00 U16 Размер структуры
0x02 U16 Тип структуры 0x04ee
0x08 U32 Метод сжатия 1 (zlib)
Структура записи POLYLINE2D (следует за стандартным заголовком записи):
-------- --- --------
0x1c U32 Неизвестно
0x20 U32 Неизвестно
0x24 U32 Количество вершин
0x28 F32 Координата "x" вершины 0
0x2c F32 Координата "y" вершины 0
0x30 F32 Координата "x" вершины 1
0x34 F32 Координата "y" вершины 1
... ... ...
-------- --- --------
0x1c U32 Неизвестно
0x20 U32 Неизвестно
0x24 F32 Координата "x" левого края надписи
0x28 F32 Координата "y" нижнего края надписи
0x2c F32 Неизвестно
0x30 F32 Ширина надписи
0x34 F32 Неизвестно
0x38 F32 Неизвестно
0x3c F32 Высота надписи
0x40 F32 Неизвестно
0x44 F32 Неизвестно
0x48 STR Текст надписи (заканчивается нулевым байтом)
- Проверяем заголовок файла. При необходимости распаковываем (если файл сжат gzip).
- Находим в директории с типом 0 адрес структуры MRCIHEADER.
- Разбираем MRCIHEADER, определяем размер изображения и количество плиток, выделяем под них память.
- Находим палитру по ее адресу и разбираем.
- Находим директорию с адресами плиток, распаковываем плитки в выделенную область памяти.
- Выделяем память под итоговое изображение, "мостим" его плитками.
- Еще раз проходим по директории с типом 0, рисуем поверх изображения с применением любой библиотеки векторной графики ломаные линии и текстовые метки. Важный момент: записи, у которых значение поля "Флаги отрисовки" равно нулю, нужно пропускать, иначе будет нарисовано много лишнего.
- Сохраняем результат в файл (BMP, PNG или любой другой).
Ну да, ну да
Можете пару программ назвать