Расскажите о ZX Next

[AIS]

Только толку от этого дампа не много. Про плавающие биты Conan ведь не спроста писал.

Давайте неспеша подумаем об этой защите. То, что адреса перепутаны, М1 использован нестандартно и пр. - это защита от того, чтобы программу заново с нуля не переписали так просто.
Плавающие биты это защита от прямого копирования.
Но просто плавающие биты это не защита - их легко можно сделать в нужных битах.
Как можно плавающие биты использовать для реальной защиты? Способ только один - применять не просто плавающие биты, а записывать в эти биты как бы аналоговое значение. Тоесть считываем этот бит, к примеру 100 раз, получается, например из 100 считываний 30 раз считался "0" и 70 раз "1". Это можно сделать условием проверки подлинности. Если же считалось 90 раз "0" и 10 раз "1", или, скажем, 50 на 50, то можно считать , что проверка не прошла.
Но не всё так просто - процент считывания "0" и "1" зависит ещё и от температуры и напряжения питания. Поэтому такой ключ ненадежен.
Выход такой - записать несколько плавающих битов с разной степенью "прошитости" (прошитостью назовем отношение количества считанных "0" к количеству считанных "1" . При прошитости 100% всегда считывается "0", при прошитости 0% всегда считывается "1", плавающий бит считывается с каким то промежуточным %)
Так вот - записать несколько плавающих битов с разной степенью "прошитости" , скажем так:
бит 1 - 30%
бит 2 - 60%
бит 3 - 10%

Если поплывут внешние условия - температура и напряжение питания, то считываемая статистика изменится, к примеру, так:
бит 1 - 57%
бит 2 - 93%
бит 3 - 48%

Фишка в том, что дестабилизирующие факторы влияют на разные биты одновременно - и если опираться на абсолютные значения "прошитости" бита нельзя - этот параметр сильно плавает , но стабильным остается соотношение прошитости разных бит, тоесть из примера выше - бит 2 всегда будет более прошит, чем бит 1 , соответственно бит 1 всегда будет более прошит, чем бит 3.
А на проверке этих условий уже можно построить защиту.
Не спроста же защита срабатывает через 3 сек. - время нужно, чтобы собрать статистику.
Вывод - для того, чтобы правильно считать это ПЗУ -
по железу: подойдет любой программатор и считывать достаточно только при номинальном напряжении питания.
по софту: софт для программатора надо написать свой - чтобы он собирал статистику считанных плавающих бит в табличку типа вышеприведенной:
бит 1 - 30%
бит 2 - 60%
бит 3 - 10% и т.д.

Два дополнения: 1. Количество считываний для сбора верной статистики надо подобрать эксперементально, начать, скажем со 100 считываний и увеличивать пока процент не перестанет сильно изменятся.
2. Надо убедится, что считываемая ПЗУ реально работает в компе - даже хорошо зашитые ячейки со временем начинают плавать, а уж изначально плавающие тем более ненадежны.

Про запись в следующий раз.

[Advertiser]

[KokaF77]

AIS, Фокус в том, что в коде плывут не байты, а отдельные биты, которые и "коверкают" (портят команду). Про данные не скажу, что бы этот алгоритм работал, как я понял, вероятность считывания ПБ должна быть "1" - 50%, "0" - 50 %, т.е. ОДИНАКОВАЯ для массива. В противном случае мы выйдем из "коридора" и сработает защита.
1. Надо точно локализовать ПБ:
а). в коде,
б). в данных.
2. Надо точно понять алгоритм защиты, исходя из п. 1(а).
Думаю будут ещё пунктики, но для начала надо с этим разобраться.

---------- Post added at 23:18 ---------- Previous post was at 23:14 ----------

Два дополнения: 1. Количество считываний для сбора верной статистики надо подобрать эксперементально, начать, скажем со 100 считываний и увеличивать пока процент не перестанет сильно изменятся.

Здесь десятки тысяч считываний нужны.

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

Все известные на сегодняшний день ПЗУ прошитые в те годы - живы и работают. Об этом уже писали в этом трэде.

---------- Post added at 23:24 ---------- Previous post was at 23:18 ----------

А вообше вот http://zx.pk.ru/showpost.php?p=295541&postcount=176

[AIS]

Фокус в том, что в коде плывут не байты, а отдельные биты,

В моём сообщении нигде небыло слова "байт"" - везде я говорю только об отдельных битах.

как я понял, вероятность считывания ПБ должна быть "1" - 50%, "0" - 50 %

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

2. Надо точно понять алгоритм защиты, исходя из п. 1(а).

Для простого копирования не надо понимать алгоритмов - надо просто воспроизвести "аналоговые" значения плавающих битов.

---------- Post added at 23:38 ---------- Previous post was at 23:26 ----------

А вообше вот http://zx.pk.ru/showpost.php?p=295541&postcount=176

Темнит здесь товарищ Конан:"... цель проверки сосчитать кол-во и положение ПБ из массива N. Если их число большое или ПБ расположены далеко друг от друга в массиве N, то опять же срабатывает защита."

Получается просто нужно расположить плавающие биты как в эталонной ПЗУ и всё?
Тогда я получается придумал защиту собственной конструкции. И круче ,чем в ZX Next

[KokaF77]

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

Может я не совсем корректно выразился. Я говорил о массиве. Сумма вероятностей всех ПБ должна быть 1. Гауссово распределение о котором упоминал Conan.

Для простого копирования не надо понимать алгоритмов

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

[AIS]

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

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

[KokaF77]

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

по хорошему нужен не один

Может, всё же проще разобраться в 200-ах байтах кода?!

[AIS]

Ну это уже клуб по интересам - кому то интереснее разобраться в 200 байтах кода, кому то сломать защиту не глядя в код.
Но вы правы - я оригинала ПЗУ не имею, поэтому подтвердить свои догадки могу только разобравшись с кодом. Вряд ли кто-то имеющий оригинал будет писать софт для программатора по моему рецепту.

[CodeMaster]

Два дополнения: 1. Количество считываний для сбора верной статистики надо подобрать эксперементально, начать, скажем со 100 считываний и увеличивать пока процент не перестанет сильно изменятся.

Как я считывал свои наборы дампов. Первый раз я считывал тупо по 50 считываний подряд в два дня, в результате получил мало полезной инфы, т.к. в основном плавали байты целиком, а не биты, т.к. было много результатов типа x00 и xFF. Поэтому в следующий раз я делал по несколько считаваний в день, но так как в софте Keeper'а количество анализируемых дампов ограничено сотней, то я сохранял после считываний только те дампы где сравнение показывало различие не во всём байте (xC0, xFE и т.д.) Таким образом реальное количество считываний было около 1000 (Эти извраты конечно можно не делать если Keeper сделат нормальный вариант проги для анализа хотя бы до 10 000 считываний ;-) С одной стороны это нарушает чистоту эксперемента, но с другой стороны я эти биты проверял только по первому найденному байту с БП, в остальном дампе они попадали произвольно (что и показывает анализ, т.к. ИМХО там много случайных выстрелов, типа один ПБ на 1000 считаваний). Хотя с другой стороны я не понимаю как тогда работает код если VROM так нестабильно читается, говорить том, что эти биты относятся к защите ИМХО не приходится, так как тогда там половина кода получается плавает ;-)))

Практическая заметка: В процессе этих считываний замечено, что в определённые дни плавают опребелённые биты. Т.е. почему я считывал по 5 дампов за день? А суть в том, что при считывании большего количества ПБ плавали по одним и тем же адресам, но на другой день ситуация менялась. При этом говорить о значительном изменении температуры VROM или питающего напряжения не приходится, т.к. VROM перед считываниями всегда был холодный и стабилизатор Vcc в Willem'е хороший. Поэтому можно с большей уверенностью говорить о плавании бит в зависимости от фазы Луны :-)))

Вряд ли кто-то имеющий оригинал будет писать софт для программатора по моему рецепту.

А не надо иметь оригинал что-бы написАть софт, надо просто уметь писать этот самый софт ;-)

[_Ratibor_]

Хотя с другой стороны я не понимаю как тогда работает код если VROM так нестабильно читается, говорить том, что эти биты относятся к защите ИМХО не приходится, так как тогда там половина кода получается плавает ;-)))

Но в ZX Next VROM работает примерно в тех же (и даже более худших) условиях, но работатет. Поэтому создаётся такое ощущение, что подход к получению карты ПБ у нас в корне неверный, т.к. VROM должен был обеспечивать не только защиту, но и стабильную работу.

Мысли вслух:
Как правильно заметил CodeMaster - VROM должен был обеспечивать не только защиту, но и стабильную работу.
Начнем сначала - насколько я понял, если просто скопировать прошивку, то ZX Next нормально работает примерно первые три минуты. Значит основной нужный нам код или большая его часть без ПБ. Тогда если несколько раз считывать дамп с холодной ПЗУ и если там будут плавающие биты или даже байты, то это мишура и к основному коду не имеет никакого отношения. Иначе бы ZX Next VROM просто не работал бы нормально в течении первых трех минут. Хотя это может и не совсем так, некоторые биты могут плавать и в основном коде сразу же, но обэтом чуть позже.

Что же может происходить в эти первые три минуты:
1. Предположим что в основном коде нет ПБ и он(основной код) собирает статистику по всей ПЗУ о ПБ и когда соберет ее и убедится что чтото не так, то отрубается. Но.... это слишком явно с точки зрения раскрытия кода и слишком сложно в реализации с точки зрения аппаратной части(нужна стабильность в плавании постоянного количества ПБ, причем в разное время и в разных местах). Так что этот вариан отпадает.
2. По всей ПЗУ в виде мишуры записано куча плавающих битов и даже байтов(чтоб при взломе было трудно найти закономерность). При этом несколько реальных ПБ есть в основном коде.

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

Думаю немного не так, много незначащих, а те 10 они скорей всего не анализируются, а находятся в основном коде и выполняются. Как бы объяснить по доходчивей
Скажем есть задача - подвесить проц через три минуты.
Один из вариантов переполнить стек, так чтоб через три минуты он переполнился и проц фиг знает что начал выполнять.

Вот простой пример:

start:
call loop
jp start

loop:
nop
jp start

Стек переполнится.

А теперь представим что в байте где стоит nop и там есть плавающие биты и nop заменяется на ret. Это конечно утрировано, но идея думаю понятна.

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

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

Хороший пример тому в AVR - watchdog
Если вовремя не обнулить его, то проц резетится.
И нужно тупо в код в разные места натыкать несколько раз обнуление таймера и все.
Применимо к нашему случаю с ПБ получится - байты будут считываться либо nop, либо обнуление таймера. Итого обе инструкции не влияют на выполнение основного кода, а на нормальную работоспособность проца ох как даже влияют. А еще натыкать пару сотен ПБ в неиспользуемые места, то попробуй повычисляй тогда

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

И Conan думаю знает что нужно искать. Допускаю что он может и не помнить где именно они находятся, но точно знает что нужно искать и на что править
Впомним те годы (80-90) когда все это делалось.
Кто мог - тот создавал, а кто не мог - тот тупо копировал.
Причем даже и без всякой защиты частенько толком скопировать то без ошибок не могли
Так что городить чтото невероятное небыло смысла.
Как он правильно сказал, для того кто может, не составит труда написать программу по новой.
А кто не может - тот фик скопирует и простую защиту.
Защита была не от производителей Profi, АТМ, Scorpion и т.п.,
а от тех кто тупо пытался копировать.

Что первым делом будут делать ?
Правильно - пытаться считывать несметное количество раз ПЗУ и искать закономерность
Флаг им в руки, там больше пол ПЗУ с ПБ. Искать закономерность будут всю жизнь.
Через неделю им надоест и они другим займутся, т.к. как говорится время деньги.

Думаю расчет как раз и был на это.

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

Хотя думаю и понимаю его почему он не хочет просто так об этом рассказать.

[AIS]

...о плавании бит в зависимости от фазы Луны :-)))

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

KokaF77, был прав - лучше с кодом разбираться.