Перейти к публикации

Модифицированная прошивка для глитчеров


Alibaba
 Поделиться

Рекомендованные сообщения

HSTL линия к которой подключается стоне при глюке имеет частоту 25 мгц. Хорошо что эта частота синхронизирована с процем, но она гораздо меньше частоты процессора. Требуется большая аналоговая задержка, что они и сделали с помощью проволочного резистора (индуктивности) и конденсаторов. 

В каком месте в стоуне проволочный резистор?

Ссылка на комментарий
Поделиться на других сайтах

Есть много путей для улучшения:

3. Изменить код загрузчика CB_A. На постаут выдавать дополнительные импульсы 

За посты вроде ж 1BL отвечает) и там всего лишь меняется восьмибитный код состояния проца. Может и можно дополнительный инкремент подсунуть, но тогда собьются все остальные последующие посткоды) они будут на единицу больше.

Проще заюзать post_out0, он чаще обновляется. Но и вероятность ложного срабатывания повысится. А на новых коронах к нему и вовсе не подобраться

Ссылка на комментарий
Поделиться на других сайтах

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

Ссылка на комментарий
Поделиться на других сайтах

@jove, так сказать, анализ) Ведь не в один день пришля мысля) Сначала просто научились снимать NAND с икбокса. Потом пытались кастомный нанд заливать и запускать. Смотрели, что, так сказать, "мешает" запуску это кастомного нанда и пытались обойти эту защиту. Потом маки залатали дыру. И опять по новой всё. Как-то так :serious:

Ссылка на комментарий
Поделиться на других сайтах

@alex706, и как же это случайно, мне интересно?) Типа: "А давайте мы поставим платку такую особую и посмотрим, что произойдёт с консолью?")

Ссылка на комментарий
Поделиться на других сайтах

Ага или подсказал кто. Полагаю микрософтам было выгодно отмести часть  клиентов, закрыв глаза на уязвимости. С учетом что хбох оригинал провалился из за дороговизны и херовости в целом, по сравнению с пс2. Вспомните сколько было ревизий пс2 (на нее до сих пор игры пилят и продают), и сколько на хбох оригинал (проект труп с рождения).  Вспомните как быстро заломали хбох 360, и сколько прошло времени пока заломали пс3.  Я не верю, что разнозненная группка красноглазых фанатов  инженеров и системных программистов, раскалывают как орехи защиту на которую было в свое время потрачено 10тыщ человекочасов.

Изменено пользователем jove
Ссылка на комментарий
Поделиться на других сайтах

alex706, и как же это случайно, мне интересно?) Типа: "А давайте мы поставим платку такую особую и посмотрим, что произойдёт с консолью?")

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

Ссылка на комментарий
Поделиться на других сайтах

Поясню почему я считаю, что проц выключается в момент подачи Z на RST. Если бы CPU_RST отвечал только за перезагрузку, то длительность импульса не влияла бы совсем! Проц поймал перепад уровня - оп, перезагрузился. И ему уже плевать, на длительность. Но нет, народ все равно подбирает импульсы. 

 

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

 

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

Приятно услышать хоть один отзыв положительный. А то как выложил, скачали и тишина. Если что не понятно растолкую.

Ссылка на комментарий
Поделиться на других сайтах

@Alibaba, а есть смысл тестить уже и на так хорошо запускающейся короне?

Ссылка на комментарий
Поделиться на других сайтах

@Alibaba, я про то, что вы пишете, что помогает бороться с проблемными консолями. Просто я ставлю x369run'ы и меня старт ну очень радует, но они заканчиваются, и в запасе только лайты до кучи. Вот и думаю, начать ставить с вашей прошивкой)

Ссылка на комментарий
Поделиться на других сайтах

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

Ссылка на комментарий
Поделиться на других сайтах

Спасибо за прошивки! Потестил под корону - хороший инструмент!

Чем они различаются между собой для юзера?

Ссылка на комментарий
Поделиться на других сайтах

Чем они различаются между собой для юзера?

Различный момент подачи ресета и длительности импульса, что отражено в названии 21866_3 - момент подачи 21866 такт длительность импульса 3 такта. Я при своем монтаже использовал в основном 21866_3, редко 21865_3.

Ссылка на комментарий
Поделиться на других сайтах

Вчера пробовал прошивки, но корона была проблемная, на всех прошивках плохо стартовала. Так и отдал на 2_2 от TX.

Ссылка на комментарий
Поделиться на других сайтах

HSTL линия к которой подключается стоне при глюке имеет частоту 25 мгц. Хорошо что эта частота синхронизирована с процем, но она гораздо меньше частоты процессора. Требуется большая аналоговая задержка, что они и сделали с помощью проволочного резистора (индуктивности) и конденсаторов. 

 

я смотрел осциллографом - там 100 мгц а не 25 ,  скриншот имеется

Ссылка на комментарий
Поделиться на других сайтах

100 мгц в нормальных условиях, а при понижении скорости проца,  во время глюка? 100 / 4 = 25 или я не прав? 

Ссылка на комментарий
Поделиться на других сайтах

я смотрел осциллографом - там 100 мгц а не 25 ,  скриншот имеется

Кстати можно на скриншот взглянуть? Интересует амплитуда этого сигнала. 

Ссылка на комментарий
Поделиться на других сайтах

Спасибо за прошивки!
Отлично показала себя 21865_3.
30с 6с 20с.
218656_3 показала себя плохо,из 3х попыток до 2х минут-1старт.
Отлично! В корпусе два рада до 20с,больше не тестировал.

Изменено пользователем Evgenfromstav
Ссылка на комментарий
Поделиться на других сайтах

Вчера пробовал прошивки, но корона была проблемная, на всех прошивках плохо стартовала. Так и отдал на 2_2 от TX.

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

После включения приставки и подачи ресета дебаг быстро мигает несколько раз, это идут начальные посты, а потом выключается, это начался пост B8 (скорость процессора сбрасывается, вентилятор начинает свистеть). Следующий пост идет BA. В него как раз и бьет ресет. Светодиод загорается. Если он коротко мигнул значит ресет подан слишком рано, надо немного удлинить провод ресета или применить прошивку с большим числом. Если дебаг загорелся и горит до перезагрузки консоли, значит ресет подан слишком поздно, надо укоротить провод ресета или попробовать прошивку с меньшими числами. На короне глитчер не  синхронизирован с консолью и ресет постоянно бьёт вокруг нужного места. Нормальная настройка получается когда дебаг на посте BA то длительно горит, то коротко (он гуляет вокруг нужного места). Если он постоянно горит длительно значит ресет слишком поздний, если коротко слишком ранний. Когда консоль стартанула дебаг начинает мигать сразу после поста BA идут следующие посты.

Ссылка на комментарий
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас
 Поделиться

  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.
×
×
  • Создать...