выглядит многообещающе.
только мне думается там операции не арифметические а булевы, тогда красное на прошлой странице и с 01..FF выглядит вполне закономерным.
и возможно еще со сдвигами, с "прокруткой" суммы за 4 шага, от них и получаются эти "блоки"
попробуй такое:
00 00 00 00 00 00 00 00
00 00 00 FF 00 00 00 FF
или
00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 01 00 00 00 FE 00 00 00 FF
или что-то еще в таком репертуаре
(24.06.2016 19:30)SWAT писал(а): [ -> ]Мне кажется тут все в итоге окажется банально просто, он не проверял толком homebrew
Что мы вообще гадаем, может кто-то себе прошить его да проверить? У меня просто привода нету на дриме щас.
Вот его видео с запуском хомбрю, правда это прошлая версия его биоса.
слишком мало известно чтоб делать выводы какого типа там операции.
по результатам твоих тестов и модификации JC, можно лишь с уверенностью сказать что можно обменивать биты у байтов в той же позиции в 32бит блоке.
но вот такое:
11 11 11 11 22 22 22 22 33 33 33 33
11 11 11 10 22 22 22 22 33 33 33 34
11->10 - сброшен бит 0
33->34 - сброшены биты 0 и 1, установлен бит 2
ожидаемо уже не прокатывает
а проходит лишь что-то вроде
11 11 11 10 22 22 22 22 33 33 34 33 44 44 43 45
10 и 45 - обменяли бит 0, в 11 сбросили в 44 взвели
34 и 43 - обменяли биты 0 - 2
еще результаты тестов:
в одном из предыдущих я пробовал менять конечный адрес на 3fe и 3fd и получал негативный результат, но похоже сам адрес на сумму таки не влияет
в сегодняшних тестах я ставил его на long с нулями, и читал последним после вычитки всего блока - сумма бьется, в том числе с любым значением 2х младших бит регистра конечного адреса типа 40f 40e 40d, проверка проходит ОК
так что циклических сдвигов текущей суммы после вычитки и суммирования байт там нет
так же пробовал ставить конечный 401 - результат негативный (я предположил что в этом случае первые 2 байта могут не суммироваться, но нет, не тот случай)
но в общем и в целом всё выглядит будто оно действительно суммирует 32бит словами, думается в процессе вычитки сохраняет в регистрах/триггерах считанные с рома байты, и затем при вычитке 4го суммирует как одно целое.
а так же при достижении конечного адреса, что может объяснить некоторые непонятки с ним, типа почему не прокатило с 3fe и 3fd - не были считаны во внутренний регистр последние нули, и там остались ненулевые байты с предыдущего 32бит слова - сумма обломалась.
занимательная, но она предполагает что биты байтов используются в обычном виде, хотя на самом деле могут быть перемешаны хрен знает как.
если предположить что тут используется обычное сложение, я бы попытался определить "вес" битов.
допустим берем и где-то взводим два бита, типа
00000000 00000000 => 00000001 00000001
и затем методом тыка сбрасываем где-то по соседству по очереди каждый из 32бит
идеальный случай если рядом есть FFFFFFFF - последовательно пробуем FFFFFFFD FFFFFFFB FFFFFFF7 FFFFFFEF и так далее
таким образом можно найти бит равный по весу двум битам номер 0, если таковой вообще существует в этом алгоритме )
да вобщем-то не так и странно. мы наблюдали частные случай(и), которые прокатывали при текущей сумме на области цифирок 11 11 22 2 итп, а при другой сумме это уже перестало работать.
честно говоря, я не очень понимаю чего ты уперся в арифметические операции - сложения-вычитания, они крайне крайне редко используются в таких вещах.
бинарные операции типа XOR/OR/AND, сдвиги, перестановка (пермутация) битов --- "наше всё" в электронике. глянь к примеру алгоритм CRC - там нет ни сложений ни вычитаний, потому что относительно сложнее реализуются на логических элементах, т.е. в чипах.
скорее всего и тут тот же случай.
так что и с этой перестановкой бит, которая тут работает а там нет, может быть имеется нечто в духе (все цифры от фонаря):
current_sum ^= (current_sum & 0x0248000) << 7;
и лишь пока в сумме не взведены биты 0248000 мы можем развлекаться и менять битики, впихивать в поток нули, и т.п.
мне кажется там может использоваться всё что угодно, кроме арифметических операций, но это лишь имхо без пруфов.
тест описанный в посте #113 мог бы отчасти подтвердить или опровергнуть это.
если найдется бит равноценный 2х другого бита - знач есть вероятность арифметического сложения/вычитания в этом алгоритме, а если нет то скорее всего нет.
(21.06.2016 00:03)MetalliC писал(а): [ -> ]нельзя, если оно оказалось в состоянии номер 2 - всё, выйти с него можно только по сбросу. это мы еще пару лет назад выяснили, как и вобщем-то само наличие трех состояний и как они переключаются или не переключаются.
ну а то что я вчера нашел этот регистрик - финальный пруф
как ни странно ,но из состояния 2 в 0 дрим выходит.
кстати в a05f74e4 мы пишем не количество байт которые нужно прочитать, а адрес при чтении которого остановится проверка
(26.09.2016 06:50)megavolt85 писал(а): [ -> ]как ни странно ,но из состояния 2 в 0 дрим выходит.
на наоми тоже так, но в этом случае после чтения блока с правильной суммой он опять становится 2 а не 3.
(26.09.2016 06:50)megavolt85 писал(а): [ -> ]кстати в a05f74e4 мы пишем не количество байт которые нужно прочитать, а адрес при чтении которого остановится проверка
верно, это давно было известо да и по самим записываемым значениям видно