Pull to refresh
235
Anton Fedorov@datacompboy

Программист / сисадмин (Sr. SRE)

0,1
Rating
298
Subscribers
Send message

Эквивалент IDAшного "File=>Produce file=>Create dif file", где сохраняется результат редактирования образа в базе данных.

Гидра вообще, если я редактирую через memory -- подсвечивает синеньким что я менял. Если редактирую через ассемблер -- нет. В итоге надо помнить где что менял, либо экспортить весь бинарь и сравнивать потом. И то и то -- неудобственько.

Да, разумеется я заметил дырку (там вначале код, потом дыра под стандартную либу, потом дыра под конфигурацию и в конце немного параметров настройки прошивки)...

Кстати, может, я так же не заметил генерацию патч-файла, как в IDA есть? :) а то заниматься экспортом и диффингом немного устаёт.

Метрическая сила...!

Меня вот это смутило - отсутствие тут *.hex.

Да, если выбрать hex файл, тогда он даёт выбор:


Теперь смогу сэкономить 5 секунд в следующий раз :)

p.s.: пойду отправлю пулреквесть :)

Явное всегда лучше. По определению, если strncpy наступает на конец выданного буфера, она НЕ записывает туда ноль (я вежливый кролик, и промолчу про это поведение для str* функции). Да, можно полагаться на неявное обнуление структуры в данном конкретном случае в данном конкретном месте, но доп запись нуля никому хуже не сделает, а если там уже гарантирован ноль и компилятор может это доказать - вон он пусть и выкидывает эту строку (тем более, что для случая с sizeof он это сделать точно может).

ip->name[strlen(ip->name)] = '\0';

Выхода за границу массива здесь нет, но сама операция бессмысленна. '\0' записывается туда, где он и так уже находится. Строчку можно смело удалить.

Все же идея была сделать вот так:

ip->name[sizeof(ip->name)-1] = '\0';

и это стандартный паттерн использования в комбинации с strncpy

Где в гидре прогрузка HEXов? Может я что-то не нашел?

В API вижу вот это: https://ghidra.re/ghidra_docs/api/ghidra/app/util/opinion/IntelHexLoader.html
но в UI варианта такого не нашел.

А что будет если jmp на jmp? Например, jne на je?

Кажется, дошло! любой мув в ROMa1 грузит верхнюю половину (4бита), мув в ROMa2 грузит нижнюю половину адреса (4бита) или наобормот.

Соответственно, "самая быстрая чехарда" возможна только в варианте

  mov roma1, a0
  mov roma2, a0
  jmp
a0:
  mov roma2, a1
  jmp
a1:
  mov roma2, a2
  jmp
a2:
  jmp

Верно?

А случай

  mov roma1, a0
  mov roma2, a0
a0:
  jmp

не очень интересен, так как это бесконечный цикл палюбому.

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

Кроме инструкций перехода, где за 3 такта происходит переход и выполнение команды на которую перешли.

а если переход на другую команду перехода, это как работает?! O_O

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

Должен сказать, что на фоне статей с проверками на баги, эта статья не продаёт.

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

Интересный способ сказать, что там всегда всё через одно место...

Не, пусть мрут когда хотят. Абы N+1/N+2 сохранялись... (и да, обидно, что добавлять один Самый Супер Сильный в группу не смысла, он-то и есть тот самый +1)

Прочитал сперва как "значок для маскировки правительственных приложений".

Много думал.

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

Information

Rating
4,045-th
Location
Zürich, Zürich, Швейцария
Date of birth
Registered
Activity

Specialization

Specialist
Ведущий