Структура файла *.STO

[TEMENb 0]

Получалось ли у кого-нибудь расшифровать содержимое файла *.sto.

Чисто теоритически он должен хранить размеры полигона + одномерный массив структур (координаты размещения детали+ размеры детали+форма+набор прочих свойств детали).

Моя идея состоит в том, что имея эти данные, можно решить вопрос экспорта данных в другие приложения. Например, программы раскроя или, скажем, в экселевский документ, для автоматического заполнения какой детали какие кромки нужны.

В общем если у кого-то есть данные о структуре файла - поделитесь )

[100g 116]

Поднимали эту тему уже. Пока ответов нету, к сожалению.

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

[TEMENb 0]

А есть ссылки на эту тему?

Как вы просмотривали? блокнотом или пытались вытащить одно-двух-четырехбитное значение и пытались преобразовать его к типу символ, целое, дробное?

Пробовали просмотривать в процессе работы скажем при помощи ArtMoney?

Мне просто слабо верится что там шифрованные данные. (кроме последней версии. с 3д обьектами у меня опыта работы небыло)

Я б не спрашивал - сам бы попробовал все. но время..

Конечно, если изучение структуры ограничилось открыванием в блокноте - то толку мало. Прийдется тогда пробовать самому докапываться.

З.Ы.: блокнот разбивает файл по 4 бита и пытается представить их как символы (Если вы их скопируете (если конечно удастся скопировать.. при такой разбивке велика вероятность напороться, скажем, на ''), вставите в другой блокнот, сохраните и откроете в про100, то у вас буит маленький эрор ))). Изменив одно значение всредине получаем сдвиг всех бит текста - изменение ВСЕГО текста.

А представьте как удобно.

Создать в библиотеке обьект "кромка" - с фиксированной толщиной и высотой. И при создании новой детали - групировать на нее кромку. :good:

После, накатать приложение, которое разбирает такую вот деталь, находит в ней элементы с параметрами Xx16x1 и интерпритирует как кромку..

Собственно у меня сейчас висит задача в листе-заказе отметить стороны на деталях, на которые надо кромку поклеить.. мне ну тааак лень все 30 деталей перебирать :yes:

вообщем состоит он из четырех битных значений.

пустой полигон содержит 165 значений (честно незнаю для чего столько))

Как туда записываются виды материалов пока незнаю - до сих пор видел только числа. Если вся эта лабуда имеет стандартный размер (т.е даже если значения отсутствуют, то ячейки памяти всеравно выделяются), то вполне можно будет считать.

И еще интересно каким макаром выполняется групирование. Хотелось бы верить, что детали попросту присваивается индекс группы, но как тогда быть с новой группой, которая состоит из нескольких групп.. )

Вообщем вопрос структуры не настолько мутный, как казалось, но все еще открыт.

Кому интересно - могу скинуть програмку, выворачивающую файл *.sto мясом наружу - т.е. показывающий все сохраненные значения. И буду благодарен за выявленные закономерности...

[Wild Tiger 309]

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

[TEMENb 0]

Ну прямо скажем не тот это формат данных, что б их сжимать. цифярки да букаффки в малых колличествах. Сложно себе представить прокет в про100 более чем на 1000 деталей * с десяток свойств на каждую. а это весьма маленькие файлы получаются.

Он даже графику не хранит. только указание на диск, где находится графический файл с изображением материала.

[Argolana 0]

А зачем его расшифровывать -то?

[Igor_482 0]

Получалось ли у когонибудь расшифровать содержимое файла *.sto.

Чисто теоритически он должен хранить размеры полигона + одномерный массив структур (координаты размещения детали+ размеры детали+форма+набор прочих свойств детали).

Моя идея состоит в том, что имея эти данные, можно решить вопрос экспорта данных в другие приложения. Например программы раскроя или, скажем, в экселевский документ, для автоматического заполнения какой детали какие кромки нужны.

Вообщем если у когото есть данные о структуре файла - поделитесь )

Расшифровать не получалось - не силен в криптографии, но знаю как выдрать из файла .STO любые элементы и сохранить их в .MEB в исходном виде. Операция не хитрая - использовал еще в версии 1.26 (в которой отсутствовала функция добавления элемнтов в библиотеку), суть в следующем: выделял необходимый мне элемент или группу элементов в созданном проекте и копировал в буфер обмена, далле открывал программу WinHex и вставлял из буфера скопированный элемент в виде шестнадцатеричного кода и сохранял данные в файл с расширением .MEB. Ту же операцию можно проделать и в новых версиях (4.42 к примеру) что позволяет оставить код в открытом виде минуя его шифрование программой. Теперь кое что о самом шифрованном файле: знаю что перфые четыре байта - это сигнатура по которой программа определяет ее ли это дейсительно файл и после проверки дешифрует содержимое. Знаю, что поляки использовали стандартную библиотеку алгоритмов шифрования в Delphi (Delphi Encryption Compendium) при реализации этой функции в программе, но какой именно алгоритм использован не знаю. В принципе подозреваю, что можно определить какой алгоритм реализован т.к. можно получить исходный и зашифрованный файл используя вышеупомянутый метод и сравнить что и как в них меняется отночительно друг друга. Исходный и шифрованный файл имеют одинаковую длинну (если не считать сигнатуру в начале щифрованного файла из 4-х байт), а значит он не сжимается программой как предположил Wild Tiger. А на счет содержания исходного файла - все то о чем ты предпологал там действительно есть и видно будет после дешифровки невооруженным глазом, так что если тебе поможет эта информация - ВСЕ РЕАЛЬНО. В дополнение скажу, что для реализации дешифрования файлов можно попробовать (если кто разбирается в ассемблере) дизассемблировать код программы и выдернуть от туда цикл преобразования данных, правда на сколько это реально незнаю т.к. в ассемблере ноль. И немного о преимуществах исходного вида данных, например: у меня есть огромная библиотека элементов в создании которой как часто выясняется позднее находится масса ошибок, так вод для исправления их, имея исходный код можно, как я это к примеру делаю - написать скрипт все в той же программе WinHex и посредствам его испраить их скажем за минуту, а не за часа 3-4 если перебирать последние ручками по стредствам самой прошки и т.п. и в том же духе на усмотрение и смекалку пользователей прошки...

Изменено 17 июня, 2009 пользователем Igor_482