Нахождение строк в файле...

P.S. Расскажу более подробно о задаче чтобы было понятно для чего это нужно: у пользователя есть программа, в которой он не заботясь о конфиденциальности своих данных использовал строковые константы в открытом виде. Задача сводится к тому, чтобы пользователю показать все строки, найденные в его файле, чтобы он выбрал нужные и софтина автоматически их зашифровала (ну ессно все референсы изменяются на декрипт этой строки куда-нить в динамически выделяемую память).
Сейчас задача решается добавлением специального маркера в код ДО и ПОСЛЕ референса на строку и софтина при загрузке файла дизасмит код между этими маркерами (также ищутся все референсы на эту строку по всем кодовым секциям программы).
Вот хотелось бы избавится от маркеров кода - чтобы программа могла все делать в автоматическом режиме без какого-либо вмешательства разработчика в код своей программы.

 

Clerk

Да я все понимаю, что указатель на строку можно замаскировать как угодно при желании, но обычно компиляторы такого не делают да и задача не предусматривает такие сложные варианты.
P.S. Извратную передачу строковых констант в функцию/API я видел только в PowerBasic:

Код (Text):

1. CALL @1
2. DB 'My message',0
3. @1:
4. ...
5. CALL MessageBoxA

Остальные компилеры (слава Богу) таким Г не занимаются )

 

Flint_ta

Похоже на то. Но разбирать прогу по косточкам не хотелось бы - т.к. это задача превращается в то, что автор IDA уже один раз делал )

 

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

 

Clerk

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

Ну вот как раз такой подход я и описал в #21 (где места кода отмечены маркерами). В идеале хочется получить максимально универсальное решение, но без полного дизасма похоже никак не обойтись.

 

dermatolog

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

 

Clerk

У нас обсуждение уходит в оффтоп - поэтому позволю себе ответить в последний раз на это сообщение )
Не совсем понятно что понимается "инструкцией загрузки эффективного адреса"
Если это LEA REG,[XXXX], то для неё тоже нужно делать релок на второй аргумент. А несколько команд типа
CALL @1
@1:
ADD DWORD PTR [ESP], DELTA
+POP R/M
Все равно будут проигрывать по быстродействию обычному PUSH XXXX/ LEA REG,[XXXX]+релок на старте.

P.S. Если уж очень хочется делать базонезависимый код, тогда уж лучше делать как PowerBasic:
CALL @1
DB 'bla-bla-bla'
@1:
+ POP R/M по вкусу.

 

P.S. В добавок к предыдущему посту - в x64 LEA умеет "работать" без релока, и второй аргумент описывает смещение относительно следующего за командой адреса - что в итоге дает базонезависимый код без всяких хлопот. Но для х32 без релока для "быстрого" LEA не обойтись )

 

dermatolog
Lea Reg32,[Reg32(DeltaOffset) + RVA]
DeltaOffset вычисляется единожды и хранится в регистре.

 

Clerk

Да никто так не делает при оптимизации - это неэффективно.

 

dermatolog

Глянь ещё дельфи и штатные макросы фасма )

 

Y_Mur

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

 

Писал я такую штуку... Программе задается набор символов, которые могут встречаться в строке, например английские с переносами, табом и т.д.; русские; +немецкие и т.д. Если строка содержит что-то лишнее - то строкой не считается. Задается минимальное количество символов в строке, строка заканчивается нулевым байтом. Ищем по всему файлу строку, удовлетворяющую условию, что она содержит только символы, перечисленные выше и заканчивается нулём, получаем адрес строки, ищем адрес по коду, если не нашли - то записываем строку в отладочный текстовый файл (вдруг чего пропустили, опционально); если нашли - то проверяем по дизасму, является ли данная команда чем-то, что может манипулировать строкой (mov eax, xxxxxxxx, push xxxxxxxx, mov [eax+edx], xxxxxxxx, mov [ecx+1234], xxxxxxxx и т.д.). Если является, то записываем в конечный текстовый файл в виде адрес/разделитель/строка и ищем следующую строку. Можно перед записью в конечный файл проверить строку по блэклисту, чтобы не писать сообщения компилятора и т.д. типа:
Too many IDAT's found
MNG features are not allowed in a PNG datastream
Unable to write international text
Valid palette required for paletted images
No IDATs written into file
png_write_info was never called before png_write_row.
zlib error
Unknown filter heuristic method
png_do_rgb_to_gray found nongray pixel
NULL row buffer for row %ld, pass %d
1.2.12
IDAT
IEND
DSERR_NOAGGREGATION
DSERR_BUFFERLOST
DSERR_OTHERAPPHASPRIO
DSERR_UNINITIALIZED
DSERR_NOINTERFACE
DSERR_ACCESSDENIED

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

 

Если собираешься писать под Windows - изучай WinAPI