[вброс] hex-редакторы

> hte

Хм, а вот этот в принципе ничего. Только зачем-то выделяет неизвестные символы в ASCII-виде красными знаками вопроса, мешает.

В каком-то хекс-редакторе вендовом офигенная штука была:

Открываешь бинарь, выделяешь кусок, и «скопировать как код на С», вставляешь в код массив бинарный. пользовался нескоько раз , очень удобно, когда нужно данные бинарные в код зашить. В линуксе такое есть где? Это я привожу пример фичи для программистов, а не крякеров

man xxd

Арчеводы не умеют пользоваться гуглом?

sudo pacman -Sy vim; man xxd

Ну если честно я и не пытался гуглом пользоватся. Просто выполнил предложенное действие :) А вим признаюсь так и не осилил

man pacman

PACMAN(6)                                                            PACMAN(6)

NAME
       pacman - the game of pacman

SYNOPSIS
       pacman [grey]

DESCRIPTION
       Pacman is an old action game.

Ок, ты победил :3

>hexl-mode же

Плюсую же!

> В линуксе такое есть где?

В линуксе такое не нужно. В линуксе есть более адекватные средства.

Это я привожу пример фичи для программистов

И как мне такой фичей «для программистов» воспользоваться автоматически из makefile-а?

hexdump или еще что то умеет конвертить бинарь в текст и обратно. Но зачем оно мне однажды понадобилось уже и не помню.

> http://hte.sourceforge.net/

Все что нужно есть.

Как он в сравнении с biew/beye?

1 hex-редактор нужен
2 hexcurse вполне годный

самым Ъ hex-редактором был и остается hiew. умеет дизассемблизировать, если код «простой».

Попробуй открыть файл > 2 Гб. Там из-за каких-то ограничений в KIO редактор просто сегфолтится.

http://en.wikipedia.org/wiki/Comparison_of_hex_editors

Разрешите потроллить человека?

Почему в линуксе, известном как «ось для программистов», до сих пор нет ни одного нормального hex-редактора

Потому что программистам, т.е. разработчикам, крайне редко нужен хекс-редактор.

ни одного нормального hex-редактора

Вот с этого места поподробнее: что имеется в виду под словом «нормальный»? Меня лично Ghex устраивает с головой

Неужели нормальный hex-редактор никому не нужен, раз его до сих пор не написали?

Хекс-редактор - достаточно простая вещь. Написать его сможет любой студент за полчаса на коленках. По-моему, пояснение «не нужен» действительно верное.

Подгружает весь файл в память? Нет уж, не надо.

Отлаживать загрузку/сохранение бинарных дампов нужно на мелких размерах. Тот же Ghex весьма резво открывает файлы до 20 Mб.

> Вот с этого места поподробнее: что имеется в виду под словом «нормальный»?

Не знаю, что ТС имел ввиду, но мне нормальный hex редактор видится следующим образом:
* Консольный.
* Умеет грузить файлы кусками. Т.е. чтобы можно было открыть в нём раздел диска, например.
* Умеет поиск и закладки.
* Может проинтерпретировать данные под курсором разным способом: как word, dword, float и т.п. и показать, чему равно значение.
* Чтобы можно было на неком си-подобном языке описать структуру данных и применить её к данным под курсором, чтобы он наглядно показал результат. Т.е показал, что поле word A равно такому-то значению, а поле char B[8] — такому-то.
* Имеет возможность в меню или на хоткеи повесить вызов команд, в которые будет передаваться через stdin помеченный кусок данных. И засасывать с stdout результат.

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

* Консольный.

Vim, например, консольный

* Умеет поиск и закладки.

Ну это имеет чуть ли не каждый хекс-редактор

* Может проинтерпретировать данные под курсором разным способом: как word, dword, float и т.п. и показать, чему равно значение.

Ghex, например, умеет. Не знаю, как остальные

* Чтобы можно было на неком си-подобном языке описать структуру данных и применить её к данным под курсором, чтобы он наглядно показал результат. Т.е показал, что поле word A равно такому-то значению, а поле char B[8] — такому-то.

Ну это уже инструмент «волшебная палочка» или «хочу все зашибись»... Откуда редактору знать, как тот или иной компилятор представляет себе эту структуру?

* Умеет грузить файлы кусками. Т.е. чтобы можно было открыть в нём раздел диска, например.

Это действительно мало кому нужно. Но в случае чего берется Qt/GTK/ncurses и пишется минут за 40...

Последний пункт я так и не понял...

> Откуда редактору знать, как тот или иной компилятор представляет себе эту структуру?

Так он и не должен знать, я ему её вручную опишу структуру на DSL. Речь не о компиляторе Си, а его встроенном интерпретаторе который бы понимал что-то типа «struct {char id[8]; dword bla; dword blabla;}»

Последний пункт я так и не понял...

Да чтоб тупо можно было выделить кусок данных в редакторе и прогнать через пайп-конвейер.

который бы понимал что-то типа «struct {char id[8]; dword bla; dword blabla;}»

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

struct{
   int a;
   char b[3];
   float c;
   long long d[13];
   unsigned char e[7];
   double f[5];
   char g[250]
   some_struct h[9];
}

будет лежать в одному Богу известном порядке.

Да чтоб тупо можно было выделить кусок данных в редакторе и прогнать через пайп-конвейер.

Вот блин... зачем оно надо и где такое реализовано?

> И как он будет понимать, в каком порядке идут эти данные в структуре и какое выравнивание используется.

Прямо в типе и указывать:

int4 be align 8 bla; // знаковое целое, занимающее 4 байта, big-endian, выравнивается на адрес, кратный 8-ми.

Чтобы каждый раз такие простыни не писать, можно делать алиасы под нужные типы данных. Например:

typedef int4 le align 0 dword;

Это на самом деле тривиальная задача: простейший парсер + ответная часть в интерфейсе редактора, отображающая в соответствии с этим описанием произвольный кусок данных как «структуру».

Можно даже сразу указывать, в каком формате отображать значения поля:

dword «08X» blabla; // отображать как 16-ричное число с выравниванием нулями до ширины 8 знаков.

а вот что-то типа

Вы немножко путаете причину и следствие. Когда проводишь анализ данных, сначала выясняешь смещения и размеры полей (или читаешь их в спецификации, если это жестко фиксированный формат — например, структуры данных ФС). А потом описываешь этот формат структуры на псевдокоде/DSL hex-редактора/ассемблере и т.п. Поэтому это совершенно не проблема.

> Вот блин... зачем оно надо и где такое реализовано?

Например, чтобы выборочно забить данные нулями по маске. Или как более удобная замена функциям «скопировать в файл»/«вставить из файла». да мало ли для чего. Просто я считаю, любой редактор без возможности скриптом обработать данные — не редактор, а недоразумение. В том числе и hex.

и где такое реализовано

Понятия не имею. Я hex-редакторами не пользовался 100 лет. А когда пользовался, такая фича не имела большого смысла — под DOS много в конвеере не наобработаешь.