Может кто знает вытащить из 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" . Признаков на самом деле много. Стоит глянуть хотя бы в ресурсы.



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

  Что называется сказано, сделано. Прикрепляю логи "выдеральщика" написанного по вашему алгоритму. 
Подопытной прогой стал сам выдеральщик 
размер лога 301кб, тогда как размер экзешника 359кб, учитывая форматирование текстового файла, в лог попало около 240кб из экзешника, что составляет более половины его размера. 
  Что после этого скажете о вероятности совпадения? Просмотрите логи. Много ли там полезного текста?
С таким же успехом можно было открыть его в блокноте и искать текст без всякой обработки. 

Проверялись 3 подряд идущих символа. Если они были допустимыми, то проверялся текст идущий за ними, все что больше 3х символов считалось строкой. Просмотр лога показал, что увеличение минимального числа символов до 4 или 5 ти много эффективности не добавит, но зато приведет к тому, что увеличится потеря полезного текста. Такой алгоритм явно требует дополнительной обработки и структурного подхода.

Присоединённый файл ( Кол-во скачиваний: 6 )
 log.txt 301,83 Kb

Ок, просто уточнил, дабы не расходиться в рассуждениях 



1. Я не знаю как работает ваша хвалёная программа, но могу с уверенностью сказать, если она и перестраивает таблицу секций, что даёт уменьшение размера программы, то происходит это за счёт отбрасывания нулей в конце секции, а эти нули и есть выравнивание по FileAlignment, которые само собой учтеные в таблице секций в поле PointerToRawSize.
2. Оверлеи найти легко, можно взять последнюю секцию, суммировав её смещение в файле и размер на диске можно получить указатель на оверлей или же можно взять ImageBase из заголовка и просуммировать его с SizeOfImage из того же опционального заголовка, получим виртуальный указатель на оверлей. Только я не понял к чему это? Вы сказали мы туда не лезем, ибо неправильно
3. Вообще совсем не учитывать таблицу импорта я бы не стал, лучше сделать это опциональной функцией алгоритма, впрочем, не об этом речь.



На практике много чего встретишь, Вы бы попробовали.




alexeis1, Вы не перестаёте меня поражать... что за отношение к делу? Вы готовы идти любыми путями или я произвожу впечатление глупово человека? 
Посмотрите внимательно в свой лог, 80% строк, если не больше, включают в себя непечатаемые символы, хотя может вы являетесь обладателем какой-нибудь расширенной клавиатуры и у Вас есть возможность набрать такое(пример из лога):

ѓД]_^[ГђSVWѓДм‹щ‰$Ќ

или может быть такое:

Ђы-tbЂы+t_Ђы$t_ЂыxtZЂыXtUЂы0u



Ну во-первых секции я могу обозвать как душей угодно, они вообще названия могут не иметь, лоадер винды на это не смотрит, во-вторых у нас, что свет клином сошёлся на С++ и Delphi? 
Я не буду описывать тут все тонкости техники определения компилятора, но скажу, что занимался этой проблемой довольно плотно и каждый день сталкиваюсь с этим на практике, я могу программу на делфи спрятать так, что определить то, что она на делфи сможет лишь опытный реверсер, да и то по косвеным признакам. Поэтому писать анализатор в данном случае нет никакого смысла. Попробуйте загнать программу весом 365 Кб в тот же PEiD он едва ли выдаст лог больше 20 Кб размером, при том, что он не учитывает компилятор.

Это сообщение отредактировал(а) W4FhLF - 10.12.2006, 10:35

  От того что я его не упомянул не значит, что там ненужно искать. Хорошо, что вы про него вспомнили.

 Это я к тому, что если нужно искать такие строки, то одного этого средства будет явно недостаточно.



Это все символы которые могут встречаться в тексте, другое дело, что вероятность их появления невысока! Часть из них являются символами из математики другие просто спец. символы. Некоторые являются русскими символами с ударением. Чем больше их убрать тем больше шансов потерять полезные строки. Вот, например, во второй строке из редких только Ђ - и то это греческая буква. Во первой есть символ ‰ - его можно убрать, можно еще убрать ударные символы, так как они достаточно редкие, хорошо, уберу еще самые редкие символы.



Это зависит от целей программки, если она направлена на взлом (что тут не обсуждается), то к ней одни требования, если она просто служит для изучения или поиска строк в своей программе или еще для чего, то тут совершенно другие требования. О назначении программы тут не было ни одного слова, потому пути реализации тоже могут отличаться.

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


Присоединённый файл ( Кол-во скачиваний: 3 )
 log.zip 89,51 Kb

Вот ключевая фраза  описывающая весь алгоритм. Программа удаляет релоки, которые исполняемому файлу фактически ни к чему, но некоторые компиляторы по стандарту всё равно суют их в файл, т.к. на системах ниже NT, если у файла нестандартный ImageBase(ниже 400000h), то без релоков он просто не запустится.



Вы как раз сказали, что нужно искать только в сегментах и то не во всех.



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



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


Это сообщение отредактировал(а) W4FhLF - 10.12.2006, 17:40

Это вы неверно интерпретировали мои слова. Я не вижу тут такой фразы. 

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

Это сообщение отредактировал(а) Voyager - 11.12.2006, 13:20

Вот, ответ именно на это вопрос я изначально и хотел услышать, но тут вмешался  alexeis1  

Можешь исходник выложить? И тогда можно тему закрывать   

Неужели такой вариант подходит?    Конечно выложу, но вечером.

Я его тут доработаю напильником.   

Все, спасибо. Тема закрыта