ioncodes

Vagrant.configure("2") do |config|
  config.vm.guest = :windows		# tell Vagrant this is a Windows-based guest
  config.vm.communicator = "winrm"	# use winrm for management instead of ssh
  config.vm.provider 'vmware_workstation' do |p|
    p.linked_clone = false
  end
  config.vm.provider :vmware_desktop do |p|
    p.vmx["ethernet0.pcislotnumber"] = "160"
  end

aaaddress1

// memBruteforce.cpp by aaaddress1@chroot.org
// brute search loaded moudules in memory
// rewrite from https://www.exploit-db.com/exploits/45293
#include <Windows.h>
#include <iostream>
#pragma warning(disable:4996)

bool isMemExist(size_t addr) {
    int retv;
    __asm {

jackullrich

#include <Windows.h>

LONG SingleStepEncryptDecrypt(EXCEPTION_POINTERS* ExceptionInfo);
typedef VOID(__stdcall* Shellcode)();

LPBYTE ShellcodeBuffer;
ULONG_PTR PreviousOffset;
ULONG_PTR CurrentOffset;
ULONGLONG InstructionCount;
DWORD dwOld;

ricardo2197

0ctf babystack with return-to dl-resolve

In this write-up I will discuss how I managed to solve the challenge "babystack" from 0ctf with a technique called return to dl-resolve. I did not know this kind of return-to attack before the contest. In the following sections a detailed explanation of the entire exploit will be presented.

1. Binary analysis

I downloaded the provided binary babystack and quickly fired up binaryninja alongside with gdb to analyze it. I quickly realized a buffer overflow vulnerability is present within sub_804843b. My first approach was to solve this challenge using a return-to-libc attack by leaking the base address of the library and call system in order to get a shell.
This technique is contingent on:

1. Leaking libc base address
2. Knowing the version of libc to get the offset of system.

However, the version of libc on the remote server was unknown and the ELF did not provide any function that can be us