Может кто знает вытащить из exe-шника строчки?
На вроде того, как это делает PEId.
(First bytes->Strings)

PEiD не вытаскивает строчки - он сигнатурный поиск производит по своей базе и потом результат выдает.
тебе зачем строчки эти? есть какие-то программки мелкие - типа strings.exe или что-то вроде того...

edit: вот - Strings. там и принцип действия описан одной строкой... 

Это сообщение отредактировал(а) dumb - 6.12.2006, 20:23

Наверное ты сам толком над темой не работал!  

Копай сюда: %Delphi 7.0 folder%\Demos\ResXplor

Честно говоря я не совсем понял принцип работы strtings.exe   
Что касается просмотровщика ресурсов. В аттаче лежит файлик. Если его открыть просмотровщиком, то он ругнется. Дело в том, что я имею в виду не ресурсные строки. Кстати, PEId отлично показывает все строки из этого файла.

PS Переименуйте аттач в hello.rar

Присоединённый файл ( Кол-во скачиваний: 13 )
 HELLO.jpg 0,41 Kb

Алгоритм там простой: Ищется первый печатаемый символ, за ним проверяется второй, если он тоже печатаемый, то проверяется 3ий и т.д. Т.о. если набирается определённое кол-во идущих подряд печатаемых символов PEiD делает вывод о том, что это строка.

Вот-вот, я замутил прогу по аналогичному алгоритму. Правда ограничитель поставить не догадался. 
И все же алгоритм у ПЕЙда должен быть другой. Ведь если читать по-символьно, это будет ой как долго, а работу свою пейд выполняет быстро.

Какой? Не вижу тут других вариантов. Насчёт скорости, то тут всё дело в оптимизации, и алгоритме использования этого алгоритма(пардон)

Да какая там скорость? Прочитать заголовок и все, современные компьютеры позволяют это делать довольно быстро. 

Это сообщение отредактировал(а) Voyager - 9.12.2006, 02:11

Какой нафиг заголовок? 

Еще можно узнать по спец признакам. Если это делфийская строка то перед самой строкой 4 байта это ее размер, а заканчивается она нулем. Если паскалевская то 1 байт размер и скорее всего тоже заканчивается нулем, если сишный char то 100% заканчивается нулем. если юникод, то размер делфийской строки (в байтах) будет в 2 раза больше указанного числа.


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

Зачем эти дополнительные проверки нужны? Т.е. ты предлагаешь сначала находить последовательность печатаемых символов, потом проверять не равна ли их длина значению dword'а(кстати по-моему там word) перед ними и только потом выдавать строку? Но если учесть, что делфийская строка может на конце иметь не $0, а выдавать последовательность большого числа(>3) идущих подряд печатаемых символов по логике придётся в любом случае, то все эти признаки идут лесом, они просто ни к чему.



Я прекрасно понимаю что такое PE формат и его заголовки, я имел ввиду другое. И тут я могу столько опровержений твоим словам найти, что можно сделать вывод о твоей некомпетентности в этом вопросе.

 Подсчитайте вероятность случайного совпадения и вы поймете, что кроме полезных строк у вас будет еще куча ;%"@ вот такой фигни.


Че спорить почитаете делфийский хелп.



Это все дополнительный проверки чтоб исключить эффект случайности. Кроме того строки в стиле делфи ВСЕГДА имеют на конце ноль. Строки в стиле паскаль могут не иметь нуля НО у них размер строки указывается числом ВСЕГО в 1 БАЙТ, потому их можно отличить! Все остальные строки имеют на конце ноль. 



Пожалуйста, опровержения в студию, пока что это только голые слова.

Добавлено @ 15:05 


Добавлено @ 15:08 

единственный тип строк не кончающийся нулем это 


но тут уж ничего не поделать в памяти это выглядит как 
303132333343536373839303132333343536373839 т.е. чисто массив символов, но тем не менее в понимании делфи это тоже строка.

Эх, alexeis1, не хочется мне поддерживать этот спор, который, я чувствую, надолго затянется, но вы меня вынуждаете(Чё это мы на Вы?). 

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



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



Убедился, действительно 4 байта.



С этим тоже согласен, но всё-таки не с потолка я взял то, что не всегда там 0, может быть в старых версиях это условие было необязательым?





Что ты подразумеваешь под сегментами, я так понимаю секции?
1. Таблица импорта может находится как внутри отдельной секции, так и в любой другой, совместно с любыми данными. Поэтому ориентироваться, если уж решил обойти таблицу, нужно на таблицу директорий, а не секции.
2. Какое может быть пространство между секциями? Нет, один очень известный человек проделывал как-то трюк, когда RawOffset+RawSize i-ой секции не равен RawOffset секции i+1, но на практике ни один из припоминаемых мною компиляторов/упаковщиков/протекторов не делает так, т.е. секции в файле идут друг за дружкой. Может показаться, что там есть какой-то пустое пространство из-за того, что они выравнены на значение FileAlignment, но фактически между ними нет пространства, которое бы не проецировалось на память лоадером винды.
К тому же, если допустить такую ситуацию, то можно сделать вывод, что сделано это в целях защиты, а мы просто возьмём и проигнорируем эти строки.
3. А строки могут быть везде... В том числе и в оверлее, который мы, исходя из Ваших понятий, благополучно пропустим, т.к. записей об оверлее в таблице секций естественно нет.

Конечно, это же синонимы. 


А вот делфи совсем так не делает. Есть спец программа StrepReloc, которая уменьшает размер делфийского экзешника за счет сокращения пространства между секциями, причем довольно существенно, значит что-то там есть. Оверлеи наверняка тоже можно найти. Ведь есть программы типа AsPack, которые предлагают сжимать или не сжимать оверлеи, значит их можно таки найти. Да аналогично и таблица импорта экспорта, пусть она расположена внутри другой секции, это же повод для того чтобы ее не искать. Надо ради пробы написать такую программку которая ищет без разбора строки. Я уверен что она выдаст их такое количество, что мало не покажется.

По поводу отличия программы на делфи от С++. Тут вообще не должно быть сложностей. Секция кода в делфи завется "CODE" а в Microsoft С++ ".code" . Признаков на самом деле много. Стоит глянуть хотя бы в ресурсы.



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