-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Хинты для пар аргументов buf и len #86
Comments
В коментарии приглашается @CourteousSleet.... |
Поддерживаю запрос |
Согласен, это будет полезная фича! |
Я тут заметил, что похоже FUTAG умеет определять, какие должны быть аргументы?
В нашем случае функция принимает str_salt - buf и sz_saltlen - len. И как я проверил в дебаге, они всегда соответствовали друг другу, что понятно, раз они используют dyn_cstring_size[1]. Но в документации я не видел описание такого функционала. Если это всегда работает безотказно, то это очень удобно. |
По анализу (ну, который я провел) в большинстве случаев, buf и len идут по
парам, и сначала идет char*, const char *, ... , потом будет size_t, int,
... Futag зафиксирует эти случаи и передает строку и ее длину.
Вт, 24 окт. 2023 г. в 10:00, Ian ***@***.***>:
… Я тут заметил, что похоже FUTAG умеет определять, какие должны быть
аргументы?
//GEN_CSTRING1
char * rstr_salt = (char *) malloc((dyn_cstring_size[1] + 1)* sizeof(char));
memset(rstr_salt, 0, dyn_cstring_size[1] + 1);
memcpy(rstr_salt, futag_pos, dyn_cstring_size[1]);
futag_pos += dyn_cstring_size[1];
const char * str_salt = rstr_salt;
//GEN_SIZE
int sz_saltlen = (int) dyn_cstring_size[1];
В нашем случае функция принимает str_salt - buf и sz_saltlen - len. И как
я проверил в дебаге, они всегда соответствовали друг другу, что понятно,
раз они используют dyn_cstring_size[1]. Но в документации я не видел
описание такого функционала. Если это всегда работает безотказно, то это
очень удобно.
—
Reply to this email directly, view it on GitHub
<#86 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADA7KV7HHGKWLAFBQ2FO53LYA5RPTAVCNFSM6AAAAAA6LZCK6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWGYZTMNJUHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Ага... Вот оно как... Наверное это не плохой метод. А это отражено в документации? Если нет, то надо бы отразить, а то мы всю голову себе сломали... И отдельный вопрос, а что будет если эта эвристика ложно сработает? У нас есть шанс об этом узнать? |
Знаем только после генерации. Поэтому хинт - хорошее предложение. Кстати, при аварийному завершению всегда надо проверить по какой причине. Futag умеет автоматический выгрузить крэш в GDB и генерирует трассу, записывает значения и т.д. |
А какой метод это делает? |
Тут с моей точки зрения нужно явное указание пар Функция A аргументы a1 и a2 -- пара буфер-длинна. аргументы a3 и a4 -- независимые, и их автоматическое объединение в пару надо отключить... Раз есть автоматика находящая пары, значит должна быть возможность отключать ее для конкретных случаев, когда она не уместна... |
К стати, для той функции из за которой все началось по результатам переполнение оказалось совершенно по другой причине: она предполагала результирующий буфер фиксированной длинны, и падала когда передавали указатель указывающий на что-то более короткое... Это наверное тоже в тему хинтов... Чтобы не цель выключать, а генерацию поправить... |
Ребята, я вернулся на родину, пока не могу активно заниматься Futag-ом. Попробуйте все функции, параметры Futag-а и если будет возможность, опишите пожалуйста конкретно что надо делать. Спасибо! |
Конкретно: принимать футагом перед генерацией целей некоторый hint-файл в текстовом формате (json? yaml?), который бы менял поведение futag'а при автоопределении стратегии создания оберток для аргументов. В хинт файле указывается имя файла исходных текстов, имя функции, а дальше для каждого аргумента (или пары аргументов )можно было бы указать следующее:
Возможно в будущем появятся какие-то еще кейсы. Это пока то на что мы наткнулись и что в процессе стало очевидно... |
Начали прогонять FUTAG на большом объеме целей и сразу споткнулись на функциях в которые передаются парой буфер и его размер. Для кода на C это штатное явление.
Автоматически выявить в аргументах пару буфер и его длинну явно будет затруднительно. А вот глазами это обычно сделать не сложно.
Чтобы раз и навсегда для таких функций исключить false-positive связанный с переполнением буфера, есть идея перед генерацией целей сообщать футагу файл с хинтами, подсказывающего ему для каждой фунцуии какие из аргументов являются парой buf и len. И тогда бы футаг мог бы устанавливать len в соотвествии с фактическим размером буфера и таким образом избегать излишний ложных срабатываний.
The text was updated successfully, but these errors were encountered: