Цель этой библиотеки - усложнить анализ как статического, так и динамического (отладчика).
Библиотека нацелена на среды Linux.
В настоящее время он основан на трюке с анти-анализом ptrace и предоставляет следующие основные функции:
Прямой вызов SYSCALL, не полагаясь на LIBC (это делает механизм обхода LD_PRELOAD неэффективным);
Системный вызов запутывания, который делает статическую обратную инженерию более сложной (эта функция в настоящее время поддерживается только в x86_64 );
Множественные призывы к Syscall ptrace . Каждый вызов ptrace должен вернуть ожидаемое значение (то есть 0 при первом вызове и -1 после этого) и способствует вычислению значения « offset », которое в конце цепочки вызовов ptrace должно соответствовать ожидаемому значению (см. Здесь). Если Ptrace возвращает неожиданное значение или значение « offset » не соответствует, процесс прекращается;
«Ptrace» называется вложенными петлями. Петли развернуты, и количество итераций рандомизировано при каждой компиляции. Более того, также значение « offset » приводится на каждую итерацию;
Сгенерированный код может быть еще больше запутан, позволяя obfuscate функцию, которая опирается на ящик Голдберга;
Чтобы использовать ящик, добавьте его в свои зависимости:
[dependencies]
debugoff = { version = "0.2.1, features = ["obfuscate"] }
Для включения также системного вызова запутывания, используйте функцию syscallobf (это экспериментальная функция и влияет только на бинарные карты, нацеленные на архитектуру x86_64 ):
[dependencies]
debugoff = { version = "0.2.1, features = ["obfuscate", "syscallobf"] }
Учитывая, что библиотека генерирует случайный код в каждой компиляции, обязательно перестроните все каждый раз. Что -то вроде этого:
cargo clean
cargo build --release
Символы снятия из сборки релизов также является хорошей идеей:
[profile.release]
debug = false
strip = "symbols"
panic = "abort"
В приведенном ниже примере debugoff используется только тогда, когда целевая ОС является Linux, и только для выпуска сборки (таким образом, когда код составлен в режиме отладки, он может быть отлаживается без необходимости обойти debugoff ).
// Include only for Linux and when building in release mode
# [ cfg ( target_os = "linux" ) ]
# [ cfg ( not ( debug_assertions ) ) ]
use debugoff ;
use std :: time :: SystemTime ;
fn main ( ) {
// Call only for Linux and when building in release mode
# [ cfg ( target_os = "linux" ) ]
# [ cfg ( not ( debug_assertions ) ) ]
debugoff :: multi_ptraceme_or_die ( ) ;
println ! (
"Time: {}" ,
SystemTime :: now ( )
. duration_since ( SystemTime :: UNIX_EPOCH )
. unwrap ( )
. as_millis ( )
) ;
// Call only for Linux and when building in release mode
# [ cfg ( target_os = "linux" ) ]
# [ cfg ( not ( debug_assertions ) ) ]
debugoff :: multi_ptraceme_or_die ( ) ;
println ! ( "Example complete!" ) ;
}См. Другие примеры в каталоге примеров, которые могут быть построены с:
cargo build --release --features obfuscate,syscallobf --examples Если мы создадим следующий код (который не использует DebugOff ) в режиме выпуска:
use std :: time :: SystemTime ;
fn main ( ) {
println ! (
"Time: {}" ,
SystemTime :: now ( )
. duration_since ( SystemTime :: UNIX_EPOCH )
. unwrap ( )
. as_millis ( )
) ;
println ! ( "Example complete!" ) ;
} Это соответствующий график функции main функции:
Полем
Если мы создадим один и тот же код, используя DebugOff с функцией obfuscate :
# [ cfg ( target_os = "linux" ) ]
# [ cfg ( not ( debug_assertions ) ) ]
use debugoff ;
use std :: time :: SystemTime ;
fn main ( ) {
# [ cfg ( target_os = "linux" ) ]
# [ cfg ( not ( debug_assertions ) ) ]
debugoff :: multi_ptraceme_or_die ( ) ;
println ! (
"Time: {}" ,
SystemTime :: now ( )
. duration_since ( SystemTime :: UNIX_EPOCH )
. unwrap ( )
. as_millis ( )
) ;
# [ cfg ( target_os = "linux" ) ]
# [ cfg ( not ( debug_assertions ) ) ]
debugoff :: multi_ptraceme_or_die ( ) ;
println ! ( "Example complete!" ) ;
} Это запутанный график функции main функции:
Полем
В этом конкретном примере весь код, сгенерированный от DebugOff был вставлен в main функции. Это не гарантируется, что всегда будет иметь место, потому что на функции, наносящие на функции, могут влиять многие факторы, такие как местоположения, где называется DebugOff , и версия Toolchain, используемая для построения проекта. В других случаях график, полученный в результате, может быть проще, чем тот, который сообщается в примере, но, в любом случае, более сложный, чем тот, который генерируется при DebugOff не используется.
Лицензировано под:
obfuscate ;obfuscate не включена; x86_64 );