Обьявление джихада формату .SID :)

[Parasite]

Вверху в постах, красными буквами. Существующий же фирменный DSDK дает функционал только на декодинг (читай - рид/онли). Кодер - за деньги (причем невменяемые).

Если в сети не встречатся бесплатных кодеров, значит:
1. Либо формат не так хорош (что врядли, если верить Вашим отзывам, а я верю).
2. Либо есть бесплатные или ломаные аналоги формата с тем или иным успехом его заменяющие (что тоже вряд ли, если учесть стоимость сида).
3. Либо формат нетривиальный, кругом обпотентованый и держится в глухой тайне, за разглашение коей инсайдерам грозит немалый срок (За это говорят характеристики формата, его явно промышленная, а не пользовательская, специализация, отсутствие ломаных кодеров в сети).

В данном случае - третье. И, в этом случае, само предположение о немалых сроках в виду "разглашения формата" довольно странно - лично я пока еще не принимал никаких соглашений и обязательств, а также никому не давал никаких подписок о неразглашении. Сид-файлов (готовых) в интернете полно в открытом доступе, накачать себе кучу - займет совершенно немного времени. Никто и ничто не мешает догадываться - а что же там внутри, собссно? Если догадка ВДРУГ окажется верной - то за что давать срок? За то что межушный ганглий выпячен несколько более чем у среднестатистического большинства? Нет такой статьи, уверяю Вас.

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

Я более чем верю - ибо Вы в данном треде более чем правы.

Внутри наверняка реализована некая контейнерная сегментация со сквозной индексацией. Но дальше этого интуитивного понимания продвинуться нереально.

У меня уже есть некоторые наработки за некоторое предыдущее время, и определенные предположения в данном направлении. По их проверке и подтверждению - я их могу публиковать в данную ветку (если это вообще кому-нибудь нужно, кроме меня). Глядишь, усилиями коллективного разума мозаика и соберется в нечто определенное...

Дешевле по трудозатратам на анализ будет, пожалуй, заработать денег на другом поприще и купить кодек=).Это равносильно тому, чтобы написать архиватор располагая лишь архивами. Там полно очень сложной математики. Очень сложной.

И все бы было правильно, если бы Вы не упустили единственный, но очень важный в данном случае пункт: данный эталонный "архиватор" у меня есть, и требуется лишь написать его функциональный аналог на базе существующего. Ничего не мешает ковырять и играться с имеющимся рабочим "архиватором" сколь угодно долго (включая разложение его на атом...т.е. на байты), строя фришные предположения, пробуя их в работе и сверяясь с результатами на технологическом выходе коммерческого "эталона".

Так что если если я не переубедил Вас в нереальности поставленных целей, то поверьте, хотябы, что это не совсем тот форум=).

Ну что Вы все "поверьте" да "поверьте", право слово...как в церкви. А ведь Вы даже еще не пробовали пощщупать данный формат "изнутри"...

Просто я знаю достаточно случаев, когда одни уверяли в безусловной стойкости формата (как правило это были те, кто продавал продукты в данном формате и имел на этом поприще вполне понятный меркантильный интерес) - а "единственный залетевший неверующий дятел"© разрушал цивилизацию, причем иногда без каких-либо особых усилий. Пару раз в жизни этим дятлом довелось побыть и мне (в основном в темах про реверс-инжиниринг DRM аудиоконтента), так что чем черт не шутит.....Я не могу дать гарантий про успешность затеи (особенно при работе в одиночку), но имхо попробовать как минимум стОит.
Что же касается "не тот форум" - ну, во-первых на данном форуме данной темой нагружена всего лишь единственная не самая большая и не самая оффтопная и мертвая ветка из всех имеющихся, а во-вторых - в случае удачи результат можно будет прикрутить к САСу (что я и предлагал в первом посте, собссно).

[svp]

И, в этом случае, само предположение о немалых сроках в виду "разглашения формата" довольно странно - лично я пока еще не принимал никаких соглашений и обязательств, а также никому не давал никаких подписок о неразглашении. Сид-файлов (готовых) в интернете полно в открытом доступе, накачать себе кучу - займет совершенно немного времени. Никто и ничто не мешает догадываться - а что же там внутри, собссно? Если догадка ВДРУГ окажется верной - то за что давать срок? За то что межушный ганглий выпячен несколько более чем у среднестатистического большинства? Нет такой статьи, уверяю Вас.

Ну что Вы в самом деле-то? Речь шла об инсайдерах знакомых с форматом. Прошу Вас, читайте внимательнее. Если эта информация ещё не просочилась через них, значит с юридической стороны там всё более чем надёжно.

И все бы было правильно, если бы Вы не упустили единственный, но очень важный в данном случае пункт: данный эталонный "архиватор" у меня есть, и требуется лишь написать его функциональный аналог на базе существующего. Ничего не мешает ковырять и играться с имеющимся рабочим "архиватором" сколь угодно долго (включая разложение его на атом...т.е. на байты), строя фришные предположения, пробуя их в работе и сверяясь с результатами на технологическом выходе коммерческого "эталона".

Это мало что меняет. Не бывает надёжной защиты. Любая защита ПО строится таким образом, чтобы её взлом по затратам человеко-часов обошелся дороже стоимости лицензии помноженной на хотябы некоторый процент спроса. Почему это так понять не трудно. Даже с учётом специфики (в плане пиратства) нашего Российского рынка, всего лишь небольшой процент готовы мириться с мытарствами, связанными с использованием ломаной продукции (Имеются, конечно, виду не столь широко распространённые продукты, как ОС, архиваторы. офис и проч.). Так вот на этот процент помножаются трудозатраты на единоразовый лом продукта и получается некоторая цена. Стоит её перекрыть в несколько крат и время от времени выпускать обновления с чуть видоизменённой защитой и всё. От взлома вы защищены. Дешевле защита -- нужно чаще обновляться; дороже защита -- можно подождать первых признаков лома.
Заявленные цены и отсутствие лома в инете говорят о том, что защита ломается очень трудно.
Я не такой оптимист, чтобы предполагать, что всё там зарыто на пол штыка лопаты. Вы - ради бога. Я не настаиваю. Сломаете -- замечательно=). А я реалист.
Кстати, без обид, но то как вы настаивали на изменении одного пикселя и анализе бинаря jpeg'а на предмет "что изменилось" всё же указывает, что в данном вопросе я ориентируюсь чуть получше Вас. И скепсис мой в вопросе лома сида оправдан.
Но я Вас ни в коем случае не отговариваю. Лишь предупреждаю.

А ведь Вы даже еще не пробовали пощщупать данный формат "изнутри"...

Я представляю себе куда более простые по реализации и алгоритмам запаковки форматы. Представляю не снаружи, а изнутри,к ак программист со стажем. И понимаю насколько трудоёмко решать такие вопросы. Одно дело разбираться в незакрытом простом формате, принципы которого известны другое дело в закрытом сложном. Полной поддержки сделать не получится хотябы из-за количества вариантов исключительных факторов. Поясню на примере того же тифа:
-- в слоях возможно сжатие несколькими алгоритмами, возможен интерлейсинг, есть какие-то разные варанты этого интерлейсинга, Тьма нюансов. Разбираться с таким форматом без документации сродни труду Левши. Уверен здесь на форуме таких гениев нету=) Опять же это мой личный скепсис. Или даже, с Вашего позволения, реалистичный взгляд на вероятность счастливого исхода Вашего мероприятия.

[Parasite]

Ну что Вы в самом деле-то? Речь шла об инсайдерах знакомых с форматом. Прошу Вас, читайте внимательнее. Если эта информация ещё не просочилась через них, значит с юридической стороны там всё более чем надёжно.

Скажите - Вы знакомы с принципом "неуловимого Джо™"? Он крайне хорошо распространяется на серьезные программы (цена которой львиной своей долей определяется из важности решаемых программой задач, а совсем не из стойкости ко взлому). Примеры? Их есть у нас. Извольте в личку, чтобы не захламлять тему.
В общем и целом - скажите, насколько будет востребован (в процентах по отношению к общему числу пользователей ПК в мире) ломанный энкодер СИДа? Особенно на том фоне, что это таки промышленный стандарт - и вменяемые (т.е. не российские по определению) организации его и так лицензируют хотя бы для ограждения себя любимых от возможных трений юр.лица с законом? Я Вас уверяю, что 99.9999[9]% обычных пользователей ПК вообще слабо себе представляют, что это такое. В организациях же где ЗНАЮТ и ИСПОЛЬЗУЮТ этот формат - там сидят люди, довольно далекие от взломов вообще, и как правило материально заинтересованные именно в легенде о стойкости формата, на котором они и делают деньги... То же самое могу сказать и про формат .pff (о котором в интернете ВООБЩЕ практически ничего нет, не говоря уж об общеизвестных ломалках и тулзах для работы с ним - но формат-то сам есть, формат сам по себе довольно неплохой и много "легче" сида, и лично я с ним работаю почти ежедневно), итд итп...

Это и есть иллюстрации вышеупомянутого принципа.

Кстати, без обид, но то как вы настаивали на изменении одного пикселя и анализе бинаря jpeg'а на предмет "что изменилось" всё же указывает, что в данном вопросе я ориентируюсь чуть получше Вас.

Например (без привязки к данной теме, а сугубо на базе темы о жпеге)?
Вы желаете сказать, что на основе двух разных по бинарному содержанию валидных жпегов я не смогу узнать - какой конкретно участок изображения был изменен? Три раза ха-ха. Распаковать оба жпега в слои и выделить разницу в маску сможет даже Action в Фотошопе. Или я как-то не так понял Вашу предыдущую сентенцию?

Возвращаясь к нашим баранам - распаковщик сида публично доступен (в том числе и в СДК и в сторонних сорцах), повторяю. Могу прислать, если желаете (80Мб). Запаковщик - тоже доступен (но уже не публично). Дело за алгоритмом работы запаковщика - который, в отличие от алгоритма запаковки жпега - закрыт, но открытый РАСпаковщик таки работает со стандартными файлами и стандарной структурой в оных.
Дело за малым: "реверснуть" алгоритм распаковки и пройти от устья к истокам - от стандартного файла к исходному изображению. Особо прошу заметить, что сид позволяет в том числе и лосслесс-сжатие - то есть алгоритм как минимум в данном режиме не использует в принципе нетрассируемых хэшей, а вполне себе полностью обратно-реверсируем, теоретически.

Я представляю себе куда более простые по реализации и алгоритмам запаковки форматы. Представляю не снаружи, а изнутри,к ак программист со стажем. И понимаю насколько трудоёмко решать такие вопросы. Одно дело разбираться в незакрытом простом формате, принципы которого известны другое дело в закрытом сложном. Полной поддержки сделать не получится хотябы из-за количества вариантов исключительных факторов. Поясню на примере того же тифа: -- в слоях возможно сжатие несколькими алгоритмами, возможен интерлейсинг, есть какие-то разные варанты этого интерлейсинга, Тьма нюансов.

...однако все они конечны по числу действий, и каждое отдельно взятое действие обратно-трассируемо в конечный алгоритм (причем Ваша версия алгоритма не обязательно должна в точности совпадать с оригинальной - она должна лишь брать на выходе то же самое что и оригинал, и выдавать на выходе именно нужное последующим частям алгоритма. На промежутке же своей работы Ваш алгоритм может быть либо лучше, либо хуже оригинального - разработчики тоже люди, склонные к ошибкам. Особенно разработчики закрытых форматов, которых мало кто проверяет на чистоту кода по определению). Да, это всё потребует какого-то времени - именно тут Вы правы.

Позвольте резюмировать одной фразой: если есть замок - то к нему ОБЯЗАТЕЛЬНО где-то существует и ключ (хотя бы и в виде отмычки) ©

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

[svp]

Не считаю эту дискуссию оффтопом, ибо, как Вы изволили выразиться, отрицательный результат -- тоже результат. Я выдвигаю гипотезу, что данный формиат нецелесообразно по экономическим причинам ломать с того конца, с которого предлагаете Вы. А продолжаете придерживаться такой позиции Вы, повторюсь, именно из-за чуть менее (ИМХО) глубокого понимания вопроса, чем то, коим располагаю я.
Прошу прочитать весь мой пост, а потом уже писать какие бы то ни было возражения.
Задача имеет решение, но на него потребуется заведомо неопределённое время. Возможности сделать оценку этого времени пока не представляется. Возможности сделать оценку способов сделать оценку тоже не представлялось (иначе уже было бы поломано, либо в сети засветились бы бурные попытки).
Я Вам докажу, что существует ОЧЕНЬ ПРОСТАЯ возможность защитить формат так, что написать енкодер анализируя примеры будет практически невозможно. Хотя бы потому, что решения придётся искать методом перебора.
Доказательства будут ниже.

Кстати, без обид, но то как вы настаивали на изменении одного пикселя и анализе бинаря jpeg'а на предмет "что изменилось" всё же указывает, что в данном вопросе я ориентируюсь чуть получше Вас.

Например (без привязки к данной теме, а сугубо на базе темы о жпеге)?
Вы желаете сказать, что на основе двух разных по бинарному содержанию валидных жпегов я не смогу узнать - какой конкретно участок изображения был изменен? Три раза ха-ха. Распаковать оба жпега в слои и выделить разницу в маску сможет даже Action в Фотошопе. Или я как-то не так понял Вашу предыдущую сентенцию?

Нет, Вы просто забыли в чем тогда была суть разговора. А сейчас речь идёт как раз о разборе формата по примерам. И как раз в этом ключе следует приведённый пример воспринимать.

Возвращаясь к нашим баранам - распаковщик сида публично доступен (в том числе и в СДК и в сторонних сорцах), повторяю. Запаковщик - тоже доступен (но уже не публично). Дело за алгоритмом работы запаковщика - который, в отличие от алгоритма запаковки жпега - закрыт, но открытый РАСпаковщик таки работает со стандартными файлами и стандарной структурой в оных.
Дело за малым: "реверснуть" алгоритм распаковки и пройти от устья к истокам - от стандартного файла к исходному изображению.

Выше я обещал объяснить как очень просто можно железно защитить формат с закрытым енкодером.
Вам знаком принцип асимметричного шифрования? К примеру возьмём алгоритм RSA: http://ru.wikipedia.org/wiki/RSA
Вкратце: асимметричные алгоритмы шифрования шифруют поток одним ключем, а расшифровывают другим. Один их этих ключей можно считать закрытым, а другой открытым. Таким образом, зашифровав некоторый файл закрытым ключем, можно смело выкладывать открытый ключ вместе с файлом во всеобщий доступ. Расшифровать его сможет каждый, но подделать (зашифровать какой-то другой файл) без закрытого ключа практически невозможно. По крайней мере сейчас есть криптостойкие алгоритмы, решение для которых ещё не найдено (в том числе тот самый RSA). Не стоит и говорить о том, что не нам и не здесь решать эту глобальную криптоаналитическую проблему.
Однако что стоит разработчикам сида шифровать в своём закрытом энкодере весь файл или его отдельные участки таким или аналогичным способом? Даже если из открытых исходников декодера станет ясно, что стандартных алгоритмоав шифрования там не использовалось (закрытый алгоритм для нас хуже открытого -- никогда не знаешь его истинной сложности), то анализ декодера НИЧЕГО не даст для решения проблемы шифрования, ибо закрытый ключ, да ещё и неизвестного нам алгоритма нам просто напросто не подобрать за время жизни вселенной, а пригласить мировое сообщество математиков для войны с проприетарным форматом мы не можем.
Это лишь пример. Весьма разумный шаг, который следовало бы осуществить разработчикам сида. Думаю они так и поступили.

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

В свете всего выше сказанного это ничего не меняет, если речь идёт об астрономическом времени. А насчет "не использует в принципе нетрассируемых хэшей" я не понял. Откуда такая информация? Есть ссылки? Интересно.

...однако все они конечны по числу действий, и каждое отдельно взятое действие обратно-трассируемо в конечный алгоритм (причем Ваша версия алгоритма не обязательно должна в точности совпадать с оригинальной - она должна лишь брать на выходе то же самое что и оригинал, и выдавать на выходе именно нужное последующим частям алгоритма.

С RSA та же история, но от этого не легче, хотя тут и алгоритм шифровки и алгоритма расшифровки доподлинно известен. Однако RSA повсеместно используется для цифровой подписи.

Да, это всё потребует какого-то времени - именно тут Вы правы.

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

Позвольте резюмировать одной фразой: если есть замок - то к нему ОБЯЗАТЕЛЬНО где-то существует и ключ (хотя бы и в виде отмычки) ©

Именно так. И не факт, что отмычка или ключ раздобыть будет проще, чем отпилить или снести замок кувалдой. Как правило даже напротив, ГОРАЗДО проще силовые методы, например, лом енкодера. Правда официально такой метод не поиспользуешь.

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

Я ещё раз повторюсь, что искренне не считаю своё мнение оффтопом в этом вопросе. Это мнение относительно мозгового штурма. Отрицательный результат -- тоже результат.
Кстати, пока никто, кроме нас, ещё не вступал в дискуссию, и каких бы то ни было конструктивных предложений не было.

[Parasite]

<...многое пожрал злобный cut...>

Вам знаком принцип асимметричного шифрования? К примеру возьмём алгоритм RSA:

Разумеется. Я знал, что Вы постараетесь свести к шифрованию парой ключей.

Смею Вас разачаровать - Ваш подход неприменим в данном треде хотя бы потому, что в данном случае нет никакого секретного ключа, нет никакого механизма генерации\сохранения\приватного хранилища секретных ключей, как нет никакого стороннего удаленного "центра сертификации" с оными, как нет никакого механизма проверки валидности отдельно взятого сида...
Если же таковой ключ и есть в составе энкодера - то его "секретность" очень условна, ибо энкодер полностью работоспособен в локальной версии, при работе не обращается ни к каким сторонним хранилищам и не требует для энкодинга никаких внешних данных кроме собственно файла. Если ключ и существует - то он жестко вшит в код программы, откуда при должном стремлении и умении его можно и выделить. Но я не склоняюсь к такому варианту событий - уж очень абсурдна сама идея подобной "защиты": закрывать все секретные двери одной парой ключей, причем оные ключи класть в разные карманы первого же попавшегося прохожего в надежде, что он "не заметит". Это равносильно программе сертификации и проверки ц.подписи приложений, идущей в комплекте с локальным генератором оных сертификатов.

Единственная возможная зацепка - в том, что энкодер привязывается к тому или иному ID локалхоста при работе, кой и берет в виде секретного ключа - а открытый ключ шьет в сам файл. Я завтра проверю это предположение, закодировав одинаковую картинку с одинаковыми настройками но на разных машинах. Если машиннозависимая шифрация имеет место быть - файлы будут кардинально различаться. Опять же, а) вероятность сего довольно низка (ибо обращение пользовательского приложения к железу элементарно трейсится - Иду и СофтАйс еще никто не отменял) б) смысла в подобном шифровании нет в любом случае, так как оба ключа в любом случае на стороне пользователя и не исключают манипулирования, в том числе и заведомо преднамеренного.

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

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

Именно так. И не факт, что отмычка или ключ раздобыть будет проще, чем отпилить или снести замок кувалдой. Как правило даже напротив, ГОРАЗДО проще силовые методы, например, лом енкодера. Правда официально такой метод не поиспользуешь.

В том-то и дело. От самой возможности кодирования в закрытый формат - он не станет вдруг открытым. Закодировать в данный формат я могу Вам что угодно и прямо сейчас, но дальше-то что? К САСу допустим это уже никак не прикрутить...

Кстати, пока никто, кроме нас, ещё не вступал в дискуссию, и каких бы то ни было конструктивных предложений не было.

Совершенно верно.
Это, опять же, в тему про "неуловимого Джо". Всем это всё ментальное напряжение просто НЕ НУЖНО - они просто пойдут и скачают очередной SAS. Это-то как раз и не новость...
PS: а создайте рядом тему "Взлом активации Висты СП1 - 100% РАБОЧИЙ!!!", дайте ее проиндексировать поисковику - и вскоре увидите разницу......

[svp]

Вам знаком принцип асимметричного шифрования? К примеру возьмём алгоритм RSA:

Разумеется. Я знал, что Вы постараетесь свести к шифрованию парой ключей.

Я не стараюсь свести алгоритм енкодера к алгоритму шифрования, я хотел лишь намекнуть, что у сидовского алгоритма сжатия могут быть такие же или похожие свойства. Если стандартный алгоритм шифрования легко обнаружить по сигнатурам или модели поведения, и обнаружив уже конкретно искать ключи, то нестандартный (пусть даже не такой криптостойкий в плане подделки сжатых данных) алгоритм сжатия со свойствами асимметричного шифрования обнаружить или доказать что он таков не представляется возможным. Ключ в этом случае может быть не явным набором байт, а заключаться в самом алгоритма, в его математике в виде каких-то специфических констант и прочего. Выходит чистым анализом сид-файлов и без подробного анализа енкодера в работе тут продвинуться немыслимо. Ну к примеру (а я уверен, что угадал): Вы сжимаете тестовый файл, потом чуть исправляете тестовый файл и сжимаете снова. Сжатые файлы довольно сильно отличаются и ЯВНО не в одном байте, а в килобайтах. Что это даст? Анализ же проприетарного алгоритма -- это уже нарушение закона, как и использование любых выводов этого анализа.

Смею Вас разачаровать - Ваш подход неприменим в данном треде хотя бы потому, что в данном случае нет никакого секретного ключа, нет никакого механизма генерации\сохранения\приватного хранилища секретных ключей, как нет никакого стороннего удаленного "центра сертификации" с оными, как нет никакого механизма проверки валидности отдельно взятого сида...

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

Если же таковой ключ и есть в составе энкодера - то его "секретность" очень условна, ибо энкодер полностью работоспособен в локальной версии, при работе не обращается ни к каким сторонним хранилищам и не требует для энкодинга никаких внешних данных кроме собственно файла. Если ключ и существует - то он жестко вшит в код программы, откуда при должном стремлении и умении его можно и выделить.

Вы полагаете енкодер сида не был защищён от трассировки и в нём не применялась обфускация? Или вы полагаете, что алгоритм сжатия, в коне концов, настолько прост, что действия, обладающие свойствами асимметричного кодирования (пусть даже с фиксированным, но распределённым по алгоритму) можно прозрачно отследить? Это несколько наивно. Нет, я не настаиваю, я, лишь, предполагаю, взвешиваю и оцениваю свои шансы.

Но я не склоняюсь к такому варианту событий - уж очень абсурдна сама идея подобной "защиты": закрывать все секретные двери одной парой ключей, причем оные ключи класть в разные карманы первого же попавшегося прохожего в надежде, что он "не заметит".

Если ключей целая связка (N), а нужных K и их нужно вставить в замок в определённом порядке, то задача уже не кажется такой уж абсурдной. Особенно когда этот прохожий вынужден выполнять длительный танец с бубном совершенно не представляя какие конкретно действия за что отвечают в этом запутанном обряде. А на деле же прохожий-то и не пытается понять. Он слуга, причём весьма неразговорчивый. А хозяин слеп и не может поспеть за слугой. Короче надоели эти косые аналогии. Вы поняли, что я хотел сказать.

Единственная возможная зацепка - в том, что энкодер привязывается к тому или иному ID локалхоста при работе, кой и берет в виде секретного ключа - а открытый ключ шьет в сам файл. Я завтра проверю это предположение, закодировав одинаковую картинку с одинаковыми настройками но на разных машинах. Если машиннозависимая шифрация имеет место быть - файлы будут кардинально различаться.

О. Уже какое-то продвижение к намеченной цели. А-то я уж подумал, что Вы просто очередной мечтатель. Хотя мнение моё не изменилось, и я по-прежнему считаю, что затея не выгорит.

Опять же, а) вероятность сего довольно низка (ибо обращение пользовательского приложения к железу элементарно трейсится - Иду и СофтАйс еще никто не отменял) б) смысла в подобном шифровании нет в любом случае, так как оба ключа в любом случае на стороне пользователя и не исключают манипулирования, в том числе и заведомо преднамеренного.

Софтайс не отменяли, но софтайс -- это инструмент. которым нужно работать. Работа -- это сила помноженная на время. Работа эквивалентна энергии, потраченной на неё, а энергия стоит денег. С одной стороны у нас надежда на "Неуловимого Джо", а с другой весьма существенная вероятность соблюдения правила "СложностьЗащиты >= СтоимостьЛицензии / (КолВоЗаинтересованных * КоэффициентДружбыНарода)", и есть ещё куча нюансов. Мы, конечно, с Вами оба ошибаемся. Вы придерживаетесь оптимистичных оценок, а я пессимистичных. Но кто бы из нас ни был больше прав, всё равно предстоит туева хуча работы. А меня недостанет альтуизма её делать. Готов лишь давать праздные советы=).
Как то:

1. А Вы бы кратенько описали для ленивых "взломщиков" характеристики формата, касающиеся сложности кго понимания: какие метода сжатия поддерживает, какой из них самый попроще, какие настройки контейнерной структуры формата имеются и вообще какие есть настройки и т.д.
2. Посравнивайте бин-компарером одинаковые файлы сжатые в сид разными методами сжатия на предмет остаётся ли контейнерная структура неизменной.
3. Поищите в сиде, сжатом с использованием стандартных методов сжатия фрагменты, эквивалентные фрагментов файлов сжатых теми же методами в другие форматы.

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

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

Нет! Конечно он не будет открываться сторонними приложениями. Это ж будет другой формат. Просто похожий изобрести легче, чем ковыряться в чёрном ящике уже существующего. Отсюда напрашивается вопрос. на кой ляд столько дурной работы, если можно легче изобрести новый открытый формат и попытаться его распространить?=)

[Parasite]

<...многое пожрал злобный cut...>

...Софтайс не отменяли, но софтайс -- это инструмент. которым нужно работать. Работа -- это сила помноженная на время. Работа эквивалентна энергии, потраченной на неё...
А меня недостанет альтуизма её делать. Готов лишь давать праздные советы=)

Ваши праздные советы в данной ветке были всеми заинтересованными прочитаны и учтены, спасибо.
Впредь попрошу быть ближе к телу, как говорил Мопассон© (ничего личного - просто воды в теме уже крайне много, а толку чуть).

1. А Вы бы кратенько описали для ленивых "взломщиков" характеристики формата, касающиеся сложности кго понимания: какие метода сжатия поддерживает, какой из них самый попроще, какие настройки контейнерной структуры формата имеются и вообще какие есть настройки и т.д.

Чуть позже. Опять же, ничего личного - у меня просто не настолько много свободного времени на это всё, ибо не это всё меня кормит. Всё будет со временем. Надеюсь.
Хотя с другой стороны - создается ощущение, что на данном форуме сабж нужен ТОЛЬКО мне, а у всех остальных нет никаких проблем эффективно хранить большие изображения вообще и карты - в частности. Если это нужно только мне - то не вижу практического смысла выкладывать это всё сюда и апеллировать к Коллективному Разуму за свободным сокетом...

2. Посравнивайте бин-компарером одинаковые файлы сжатые в сид разными методами сжатия на предмет остаётся ли контейнерная структура неизменной.
3. Поищите в сиде, сжатом с использованием стандартных методов сжатия фрагменты, эквивалентные фрагментов файлов сжатых теми же методами в другие форматы.

(ехидно) - И что бы я без Вас делал, а...
Все это было сделано лет несколько назад, данные наработаны и подвижки (гораздо более указанных Вами выше) есть. Нет только времени на все это, включая систематизацию, обработку и выкладывание сюда. Со временем, надеюсь, будет появляться. Вопрос вовсе не стоит ребром по типу "жизненно необходимо сломать именно к этому Новому Году".

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

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

Нет! Конечно он не будет открываться сторонними приложениями.

Он либо будет открываться сторонними приложениями - либо его (в свете темы про сид) не будет вообще, по ненужности этого нового несовместимого формата лично мне. В сабже обсуждается либо сид как таковой (он же самописный аналог, не имеющий проблем с совместимостью со сторонними приложениями), либо ничего.

[svp]

создается ощущение, что на данном форуме сабж нужен ТОЛЬКО мне, а у всех остальных нет никаких проблем эффективно хранить большие изображения вообще и карты - в частности.

Наверно у большинства единственным источником картографических данных являются тайловые серверы а-ля гугл. Очевидно, что целесообразнее и эффективнее хранить несклеенные тайлы карт с этих сервисов, ибо склеть их никогда не поздно. К тому же можно скопировать тайлы только нужного участка и мобильно переправить их на другой компьютер.
Ну и ряд других удобств, которые даёт Планета.

[Parasite]

Единственная возможная зацепка - в том, что энкодер привязывается к тому или иному ID локалхоста при работе, кой и берет в виде секретного ключа - а открытый ключ шьет в сам файл. Я завтра проверю это предположение, закодировав одинаковую картинку с одинаковыми настройками но на разных машинах. Если машиннозависимая шифрация имеет место быть - файлы будут кардинально различаться. Опять же, а) вероятность сего довольно низка (ибо обращение пользовательского приложения к железу элементарно трейсится - Иду и СофтАйс еще никто не отменял) б) смысла в подобном шифровании нет в любом случае, так как оба ключа в любом случае на стороне пользователя и не исключают манипулирования, в том числе и заведомо преднамеренного.

Докладаю: проверка произведена.
Файлы сид, полученные на разных машинах из одинакового исходника и с одинаковыми настройками - полностью побайтно совпадают в теле файла, небольшая разница имеет место быть лишь в самом хвосте файла в метаданных (дата\время создания, локальный путь для сохранения итд).
Метаданные в сиде текстовые, и видны банальным ноутпадом. Сам же контейнер полностью одинаков в обоих файлах, включая его заголовок.

[Parasite]

создается ощущение, что на данном форуме сабж нужен ТОЛЬКО мне, а у всех остальных нет никаких проблем эффективно хранить большие изображения вообще и карты - в частности.

Наверно у большинства единственным источником картографических данных являются тайловые серверы а-ля гугл.

Скорость доступа и мобильность такого метода оставляют желать лучшего, к сожалению. То же могу сказать и про долговременность доступа. Никто не даст железной гарантии того, что гугль будет работать через день\месяц\год.

Очевидно, что целесообразнее и эффективнее хранить несклеенные тайлы карт с этих сервисов, ибо склеть их никогда не поздно. К тому же можно скопировать тайлы только нужного участка и мобильно переправить их на другой компьютер.

Поправьте меня кто-нибудь, но кажется именно на этом форуме несколько ранее многословно обсуждалась проблема локального хранения тонн тайлового гуглекэша?