Skip to content
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

Add support for setting YR_MODULE_IMPORT::module_data #88

Open
wbenny opened this issue Sep 17, 2022 · 3 comments
Open

Add support for setting YR_MODULE_IMPORT::module_data #88

wbenny opened this issue Sep 17, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@wbenny
Copy link

wbenny commented Sep 17, 2022

CallbackMsg::ImportModule should be extended to access YR_MODULE_IMPORT data, namely module_name and module_data(_size).

Some modules accept additional module data, e.g. cuckoo module accepts json, which enables extended yara scanning.

This functionality is already exposed in python bindings (https://github.com/VirusTotal/yara-python/blob/master/yara-python.c#L618) and it would be lovely to have this functionality in this awesome rust crate :)

@wbenny
Copy link
Author

wbenny commented Sep 17, 2022

I managed to make it sort of work with these changes:

//
// add to the top of internals/scan.rs
//

#[derive(Debug)]
pub struct Module<'r> {
    inner: *mut yara_sys::YR_MODULE_IMPORT,
    _marker: std::marker::PhantomData<&'r ()>,
}

impl<'r> Module<'r> {
    pub fn get_name(&self) -> &'r str {
        let inner = unsafe { &mut *self.inner };
        unsafe { CStr::from_ptr(inner.module_name) }
            .to_str()
            .unwrap()
    }

    pub fn set_data(&mut self, data: &'r [u8]) {
        let inner = unsafe { &mut *self.inner };
        inner.module_data = data.as_ptr() as *mut c_void;
        inner.module_data_size = data.len() as u64;
    }
}

//
// update in CallbackMsg::from_yara
//
...
            yara_sys::CALLBACK_MSG_IMPORT_MODULE => {
                let _module = unsafe { &mut *(message_data as *mut yara_sys::YR_MODULE_IMPORT) };

                ImportModule(Module {
                    inner: _module,
                    _marker: std::marker::PhantomData
                })
            }
...

//
// ... and then, in main():
//
...
    let data = std::fs::read("data/yara/cuckoo.json").unwrap();

    let callback = |message: CallbackMsg| {
        match message {
            CallbackMsg::ImportModule(mut module) => {
                println!("module: '{}'", module.get_name());
                module.set_data(&data);
            }
            CallbackMsg::RuleMatching(rule) => {
                println!("match: '{}'", rule.identifier);
            },
            _ => (),
        }
        CallbackReturn::Continue
    };

    rules
        .scan_file_callback("data/yara/binary", 5, callback)
        .expect("Should have scanned");
...

The code above works.
However, I must have messed up lifetimes somewhere, because the following also compiles:

    let callback = |message: CallbackMsg| {
        match message {
            CallbackMsg::ImportModule(mut module) => {
                println!("module: '{}'", module.get_name());

                // !!!!!!!! this compiles fine, but of course crashes in runtime
                let data = std::fs::read("data/yara/cuckoo.json").unwrap();
                module.set_data(&data);
            }
            CallbackMsg::RuleMatching(rule) => {
                println!("match: '{}'", rule.identifier);
            },
            _ => (),
        }
        CallbackReturn::Continue
    };

Unfortunatelly, my rust-fu isn't yet advanced enough to comprehend what exactly is wrong with the lifetimes and how to fix them.

@ikrivosheev
Copy link
Contributor

@wbenny hello! I thought about this, but bytes convert to struct in Rust is unsafe. And this was the problem why I didn't implement this...
Maybe we can create a lazy transmute API...

@ikrivosheev
Copy link
Contributor

And the second problem is to send a type to which transmute bytes...

@Hugal31 Hugal31 added the enhancement New feature or request label Sep 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants