Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Ferramentas/GitHubGitHub/rurixis/msrkit
Escalada de PrivilégiosExploraçãoEngenharia ReversaShellcodePós-ExploraçãoRed TeamingDesenvolvimento de PayloadsExploração de Binários
GitHubrurixis/msrkit

MSRKit

Um conceito de usar uma cadeia ROP combinada com uma primitiva WRMSR para chamar funções do kernel e mapear drivers não assinados através de BYOVD (AmdTools64.sys)

Ver Repositório
9135há 2 diasAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

MSRKit

Uma ferramenta para chamar funções do kernel e mapear drivers através de uma cadeia ROP por meio de uma primitiva wrmsr em um driver vulnerável (AmdTools64.sys).

Como funciona

  1. Carrega AmdTools64.sys via NtLoadDriver (recorre ao PnP devnode + interface de dispositivo baseada em GUID se o symlink não estiver disponível)
  2. Lê IA32_LSTAR através do IOCTL de leitura de MSR do driver (0xFFF02804)
  3. Escaneia ntoskrnl.exe em busca de gadgets ROP (pop rcx; ret, mov cr4, rcx; ret, wbinvd; ret, etc.)
  4. Sobrescreve IA32_LSTAR com o gadget de entrada, limpa AC em FMASK e emite syscall
  5. A cadeia ROP limpa os bits SMEP/SMAP em CR4, despacha a função alvo na pilha do kernel, restaura CR4 e LSTAR, retorna ao modo usuário via sysretq

O mapeamento de driver segue o mesmo caminho: aloca pool do kernel via ExAllocatePoolWithTag, copia a imagem PE preparada (relocações aplicadas, imports resolvidos, security cookie corrigido) e chama o ponto de entrada mapeado.

Uso

CLI

root@kitploit:~
msrkit <driver.sys> call    <ExportName> [args...]
msrkit <driver.sys> call_at <address>    [args...]
msrkit <driver.sys> map     <unsigned.sys> [entry args...]
msrkit <driver.sys> unmap   <address>
  • call -- resolve e chama uma exportação nomeada de ntoskrnl. Os argumentos são interpretados como inteiros (hexadecimal com prefixo 0x). Imprime o valor de retorno.
  • call_at -- chama um endereço virtual arbitrário do kernel.
  • map -- mapeia um driver não assinado no pool não paginado e chama seu ponto de entrada (ExAllocatePoolWithTag). Imprime o endereço base mapeado.
  • unmap -- libera um driver previamente mapeado no endereço base fornecido.

Biblioteca

root@kitploit:~
#include "msrkit.h"

#pragma comment(lib, "msrkit.lib")

int main()
{
	MSRK::INIT(L"AmdTools64.sys");

	void* mptr = MSRK::CALL("ExAllocatePool2", 0x40ULL, 0x1000, 'Ruri');
	std::cout << "Memory allocate: " << mptr << std::endl;

	auto mptr23 = MSRK::MAP("driver.sys", 123, 456);
	std::cout << "Driver mapped: " << std::hex << (uintptr_t)mptr23 << "\n";

	// raw call
	std::vector<uint64_t>args = { 0x40ULL, 1024, 'Tagz' };
	void* mptr24 = MSRK::M_FUNCTION::CALL("ExAllocatePool2", args.data(), args.size());
	std::cout << "raw memory alloc : " << mptr24 << std::endl;

	std::vector<uint64_t>args2 = { 123, 456 };
	auto mptr25 = MSRK::M_DRIVERMAP::MAP( "driver.sys", args2.data(), args2.size() );

	MSRK::UNMAP(mptr23);	
	MSRK::CLEANUP();
}

Opcionalmente, passe um handle de driver existente para pular o carregamento:

root@kitploit:~
MSRK::INIT("AmdTools64.sys", existing_handle);

Compilação

Requer Visual Studio com MSVC (v143+) e MASM (ml64.exe).

root@kitploit:~
cmake -B build -G "Visual Studio 17 2022" -A x64
cmake --build build --config Release

Saída: build/Release/msrkit.exe (CLI) e msrkit.lib (biblioteca estática).

CFG está desabilitado (/guard:cf-). Stack cookies (/GS) estão habilitados.

Recursos

  • Suporte completo para todas as builds do Windows 10 e 11
  • Compatível com KPTI
  • Sem suporte a HVCI (HVCI deve estar desabilitado)
  • Suporte a drivers PnP / Non PnP

Limitações

  • Execução apenas em núcleo único -- a thread é fixada na CPU 0 durante chamadas ao kernel
  • Sequestros de LSTAR concorrentes de processos separados causarão BSOD (um chamador por vez)
  • Stubs de syscall Zw/Nt não podem ser chamados a partir do contexto LSTAR (reentra em KiSystemService)
Baixar ferramenta