cseagle / sk3wldbg Goto Github PK

When putting breakpoint on main and debugging with the plugins:

found input file C:\Users\mofo\Downloads\putty.exe
reading file of 531368 bytes
loadPE32
map_mem_zero(0x401000, 0x45d000, 0x5)
Copying bytes 0x1000:0x5d000 into block
map_mem_zero(0x45d000, 0x47b000, 0x1)
Copying bytes 0x5d000:0x7b000 into block
map_mem_zero(0x47b000, 0x481000, 0x3)
Copying bytes 0x7b000:0x7d000 into block
map_mem_zero(0x481000, 0x484000, 0x1)
Copying bytes 0x7d000:0x80000 into block
map_mem_zero(0x30000, 0x130000, 0x3)
401000: process Unicorn Process has started (pid=30135)
region 0: 0x401000-0x45cffe (5)
Breakpoint hit at: 0x448d2d
region 0: 0x401000-0x45cffe (5)
region 1: 0x45d000-0x47affe (4)
region 1: 0x45d000-0x47affe (4)
region 2: 0x47b000-0x480ffe (6)
region 2: 0x47b000-0x480ffe (6)
region 3: 0x481000-0x483ffe (4)
region 3: 0x481000-0x483ffe (4)
region 4: 0x30000-0x12fffe (6)
region 4: 0x30000-0x12fffe (6)
uni_stopped_at_debug_event called
region 0: 0x401000-0x45cffe (5)
region 0: 0x401000-0x45cffe (5)
region 1: 0x45d000-0x47affe (4)
region 1: 0x45d000-0x47affe (4)
region 2: 0x47b000-0x480ffe (6)
region 2: 0x47b000-0x480ffe (6)
region 3: 0x481000-0x483ffe (4)
region 3: 0x481000-0x483ffe (4)
region 4: 0x30000-0x12fffe (6)
region 4: 0x30000-0x12fffe (6)

start Failed on uc_emu_start(0x448d2d) with error returned 14: Fetch from non-executable memory (UC_ERR_FETCH_PROT)
401000: process Unicorn Process has started (pid=29444)
7A1B8: The instruction at 0x7a1b8 attempted to fetch from NX memory -> 0007A1B8 (exc.code b, tid 10778)
start Failed on uc_emu_start(0x7a1b8) with error returned 14: Fetch from non-executable memory (UC_ERR_FETCH_PROT)

Does it means that memory is not mapped in the debugging sessions ?
Thanks

It seems that the plugin is not mapping memory correctly for some reason.

I'm using IDA 8.2 and the plugin bombs on the following instruction when I start from cursor

ROM:0004B2DA LDR             R6, [R3,#(off_13D584 - 0x13D578)] ; START_3_DATA1

I would assume that ROM would be mapped automatically but it doesn't look so.

I start with these segments in IDA

ROM	0000000000000000	000000000013FFFF	R	W	X	.	.	byte	00	stack	CODE	32	00	00
RAM	0000000000140000	00000000FFFFFFFF	R	W	X	.	.	byte	01	public		32	00	01

and I end up with

ROM	0000000000000000	000000000013FFFF	R	W	X	.	.	byte	00	stack	CODE	32	00	00
debug003	000000000013FFFF	0000000000140000	R	W	X	D	.	byte	00	public	CODE	32	01	01
RAM	0000000000140000	00000000FFFFFFFF	R	W	X	.	.	byte	01	public		32	00	01

The IDA output shows

reading file of 1307757 bytes
map_mem_zero(0xffefe000, 0xffffe000, 0x7)
Allocated at 0xffefe000 in map_mem_zero
map_mem_zero(0x0, 0x13ffff, 0x7)
Allocated at 0x0 in map_mem_zero
map_mem_zero(0x140000, 0xffffffff, 0x7)
Failed to allocate at 0x140000 in map_mem_zero
PC was set previously to 0x4b2da
0: process flyctrl.img.FCFW.f4000000 has started (pid=20822)
segm_added mapping, 0x13ffff:0x140000
segm_added already mapped
13FFFF: created segment debug001, end: 140000
4B2DA: The instruction at 0x4b2da attempted to execute from unmapped memory -> 0004B2DA (exc.code b, tid 29644)
13FFFF: deleted segment debug001, end: 140000
segm_added mapping, 0x13ffff:0x140000
segm_added already mapped
13FFFF: created segment debug002, end: 140000
13FFFF: deleted segment debug002, end: 140000
segm_added mapping, 0x13ffff:0x140000
segm_added already mapped
13FFFF: created segment debug003, end: 140000

Hi,

Would be nice to port it to radare2.

Greetings

Hello,

Trying to make it work under arch linux with latest 6.9 ida without luck.
Using the pre-built binary and puting libunicorn.so.1 in /usr/lib, also trying to put libida.so/libida64.so to /usr/lib, then ldconfig.
log:

-> $ sudo ldd libunicorn.so.1
linux-gate.so.1 (0xf77c8000)
libglib-2.0.so.0 => /usr/lib32/libglib-2.0.so.0 (0xf6dcf000)
libm.so.6 => /usr/lib32/libm.so.6 (0xf6d7a000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf6bc5000)
libpcre.so.1 => /usr/lib32/libpcre.so.1 (0xf6b50000)
libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf6b32000)
/usr/lib/ld-linux.so.2 (0x565e5000)

-> $ ldd sk3wldbg.plx64
linux-gate.so.1 (0xf7730000)
libida64.so => /usr/lib/libida64.so (0xf73e3000)
libunicorn.so.1 => /usr/lib/libunicorn.so.1 (0xf6b40000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf69c9000)
libm.so.6 => /usr/lib32/libm.so.6 (0xf6974000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf6959000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf67a4000)
libdl.so.2 => /usr/lib32/libdl.so.2 (0xf679f000)
librt.so.1 => /usr/lib32/librt.so.1 (0xf6796000)
libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf6779000)
libglib-2.0.so.0 => /usr/lib32/libglib-2.0.so.0 (0xf6650000)
/usr/lib/ld-linux.so.2 (0x56620000)
libpcre.so.1 => /usr/lib32/libpcre.so.1 (0xf65db000)

Is there any message when the plugin successfuly loaded in IDA ? I can't see any debugger called sk3wldbg on an arm binary.

What can I do to debug it ?
Thanks

This is not really a bug report - but as I did not find any forum dedicated to sk3wldbg, and I could not find out your direct E-mail address, I'm leaving this here (and yes, a discussion forum about sk3wldbg would be great :-). Let me start that I love sk3wldbg (and Unicorn in generic)!

My problem is how to allocate memory in a debug session? If a program at some point allocates memory via syscall, I need to emulate it. But in order to call mem_map from Unicorn (in Python), I'd need the relevant Uc object exposed. I assume this is not the case, or is it?

I tried an alternative path by creating a new segment in the idb (before starting the debugger), and filling it with zeroes, plus making it writable. In theory, it should be possible to return blob addresses from this scratch section to alloc calls. Indeed I can see the memory in the debugger, but trying to write into it manually gives a "Failed on uc_mem_write() with error returned 7: Invalid memory write (UC_ERR_WRITE_UNMAPPED)" error, so I guess the new section was not mapped into the unicorn part. Is there a way to create sections so they are mapped?

I finally tried to return an address from the start of the binary itself (marked as writable), and now I can manually write into this from debugger (via edit popup, or F2), but code that tries to write into it create a "405142: The instruction at 0x400080 attempted to write to write protected memory -> 0000000000400080 (exc.code b, tid 23227)" (note there is a small bug in the error message too, the code is at address 405142, not 400080 - this is the accessed memory).

Thanks again for the excellent plugin! Andy

mem_mgr.cpp:25:10: fatal error: 'ida.hpp' file not found
#include <ida.hpp>

Hi,

Got an error when trying to use the dbg plugin under windows.
I put the unicorn1.dll in IDA directory and put both .plw, .p64 in the plugins directory.
Grabbed libglib-2.0-0.dll, libintl-8.dll, libgcc_s_dw2-1.dll, from Qemu and put them in the IDA directory as well. When running Ida I get: LoadLibrary(C:\Program files\ida\plugins\sk3wldbg_user.plw) error: The specified module could not be found.

What is wrong in my installation ?
Latest ida of course.

I'm trying to emulate x86 32 bit real-mode code that reads from the GS segment. I patched the the initialization in sk3wldbg.cpp to init GDT and set the GS segment register similar to the unicorn example :

uint64_t sk3wldbg::initGsSegment(void) {
	uc_err err;
	int r_gs = 0x83;
	const uint64_t gdt_address = 0x800000;
	const uint64_t gs_address = 0x7efdd000;
	uint32_t stack_addr = 0x5a000;
	struct SegmentDescriptor *gdt = (struct SegmentDescriptor*)calloc(31, sizeof(struct SegmentDescriptor));
	gdtr.base = gdt_address;
	gdtr.limit = 31 * sizeof(struct SegmentDescriptor) - 1;
	init_descriptor(&gdt[16], 0x7efdd000, 0xfff, 0);  //one page data segment simulate gs
	err = uc_reg_write(uc, UC_X86_REG_GDTR, &gdtr);	
	err = uc_mem_write(uc, gdt_address, gdt, 31 * sizeof(struct SegmentDescriptor));
	err = uc_mem_map(uc, gs_address, 0x1000, UC_PROT_WRITE | UC_PROT_READ);
	err = uc_mem_write(uc, gs_address, &stack_addr, sizeof(stack_addr));
	err = uc_reg_write(uc, UC_X86_REG_GS, &r_gs);
	return 0;
}

and call it in unit_start_process:

...
int idaapi uni_start_process(...

+     uc->initGsSegment();
      //need other ways to set PC, from start, user specified
      uc->set_pc(init_pc);
...

However I encounter the strange behaviour that even though call/ret still works, the stack view just displays zeros. Same with the Hex view.

If I decomment

-     err = uc_reg_write(uc, UC_X86_REG_GS, &r_gs);
+    //err = uc_reg_write(uc, UC_X86_REG_GS, &r_gs);

Then the stack/hex view works again. Below is a picture of the stack view after a call.

When err = uc_reg_write(uc, UC_X86_REG_GS, &r_gs); is enabled:

When //err = uc_reg_write(uc, UC_X86_REG_GS, &r_gs); is diabled:

Any hits howto fix it?

Warning

1009C67C8: The instruction at 0x1009c67c8 attempted to execute from unmapped memory -> 00000001009C67C8 (exc.code b, tid 1537)

OK

Hey there,
Building sk3wldbg on Visual Studio (Community) 2015 fails (both 32 and 64bit)

Error:
1>sk3wldbg.cpp(1378): error C2440: "=": "int (__stdcall *)(pid_t,int,int)" kann nicht in "int (__stdcall *)(pid_t,int)" konvertiert werden

Plus the following warnings
1>D:\idaplus\idasdk68\include\typeinf.hpp(2606): warning C4267: "return": Konvertierung von "size_t" nach "type_t", Datenverlust möglich 1>D:\idaplus\idasdk68\include\typeinf.hpp(2639): warning C4267: "return": Konvertierung von "size_t" nach "uchar", Datenverlust möglich 1>D:\idaplus\idasdk68\include\typeinf.hpp(2829): warning C4267: "return": Konvertierung von "size_t" nach "cm_t", Datenverlust möglich 1>D:\idaplus\idasdk68\include\typeinf.hpp(2891): warning C4267: "return": Konvertierung von "size_t" nach "type_t", Datenverlust möglich 1> sk3wldbg.cpp(1378): note: Diese Konvertierung erfordert einen reinterpret_cast-Operator oder eine Typumwandlung im C- oder Funktionsformat

I'm not enough into this API to submit a fix...

Undefined symbols for architecture i386:
"mem_mgr::set_mmap_region(unsigned long long, unsigned long long)", referenced from:
sk3wldbg::init_memmgr(unsigned long long, unsigned long long) in sk3wldbg-9f0ced.o
"mem_mgr::mmap(unsigned long long, unsigned int, unsigned int)", referenced from:
sk3wldbg::map_mem_zero(unsigned long long, unsigned long long, unsigned int) in sk3wldbg-9f0ced.o
"mem_mgr::mem_mgr(uc_struct*, unsigned long long, unsigned long long)", referenced from:
sk3wldbg::init_memmgr(unsigned long long, unsigned long long) in sk3wldbg-9f0ced.o
"mem_mgr::~mem_mgr()", referenced from:
sk3wldbg::~sk3wldbg() in sk3wldbg-9f0ced.o
ld: symbol(s) not found for architecture i386

Chris,

Good morning. How are you?

Almost certainly, it is my mistake because I haven't had enough time for debugging it.

Anyway, it follows a little information:

1. Windows 7 x86
2. IDA Pro 6.95
3. I've compiled the plugin by using Visual Studio 2015.
4. The tested file some executables.

The problem: soon the debugging process starts (using Ske3wDbg, step-by-step instruction), several exceptions (I've tried to pass them back to application) are risen and the debugger is detached.

I've tested the plugin using several malwares (including an educational one). Finally, few evidences (related to the educational malware -- the most simple executable that I could find) follow attached:

1. Screenshot
2. My compiled plugin version (and its associated PDB file)
3. The idb database of the executable.
4. The executable (educational program).

Last lines of Output Window are:

found input file C:\Users\AB\Pictures\educational_malware.exe
reading file of 1536 bytes
loadPE32
map_mem_zero(0x401000, 0x402000, 0x7)
Allocated at 0x401000 in map_mem_zero
Copying bytes 0x200:0x400 into block
map_mem_zero(0x402000, 0x403000, 0x3)
Allocated at 0x402000 in map_mem_zero
Copying bytes 0x400:0x600 into block
map_mem_zero(0x30000, 0x130000, 0x7)
Allocated at 0x30000 in map_mem_zero
401000: process Unicorn Process has started (pid=22703)
20AC: The instruction at 0x20ac attempted to execute from unmapped memory -> 000020AC (exc.code b, tid 9130)
20AC: The instruction at 0x20ac attempted to execute from unmapped memory -> 000020AC (exc.code b, tid 9130)
Debugger: detached from process

Unfortunately, the same issue has happen while using its pre-compiled version. Therefore, I must have commited a trivial mistake.

Please, I am sorry for bothering you with it.

Have an amazing day, Chris.

Alexandre.

Evidences.zip

tried to build 32bit sk3wldbg for ida 68 in vs 2017 ( windows 10).
but failed.

1>------ Build started: Project: sk3wldbg, Configuration: Release Win32 ------
1>loader.cpp
1>mem_mgr.cpp
1>sk3wldbg.cpp
1>C:\idasdk68\include\typeinf.hpp(2606): warning C4267: 'return': conversion from 'size_t' to 'type_t', possible loss of data
1>C:\idasdk68\include\typeinf.hpp(2639): warning C4267: 'return': conversion from 'size_t' to 'uchar', possible loss of data
1>C:\idasdk68\include\typeinf.hpp(2829): warning C4267: 'return': conversion from 'size_t' to 'cm_t', possible loss of data
1>C:\idasdk68\include\typeinf.hpp(2891): warning C4267: 'return': conversion from 'size_t' to 'type_t', possible loss of data
1>sk3wldbg.cpp(1406): error C2039: 'is_be': is not a member of 'idainfo'
1>C:\idasdk68\include\ida.hpp(104): note: see declaration of 'idainfo'
1>sk3wldbg_arm.cpp
1>sk3wldbg_m68k.cpp
1>sk3wldbg_mips.cpp
1>sk3wldbg_plugin.cpp
1>C:\idasdk68\include\typeinf.hpp(2606): warning C4267: 'return': conversion from 'size_t' to 'type_t', possible loss of data
1>C:\idasdk68\include\typeinf.hpp(2639): warning C4267: 'return': conversion from 'size_t' to 'uchar', possible loss of data
1>C:\idasdk68\include\typeinf.hpp(2829): warning C4267: 'return': conversion from 'size_t' to 'cm_t', possible loss of data
1>C:\idasdk68\include\typeinf.hpp(2891): warning C4267: 'return': conversion from 'size_t' to 'type_t', possible loss of data
1>sk3wldbg_ppc.cpp
1>sk3wldbg_sparc.cpp
1>sk3wldbg_x86.cpp
1>Generating Code...
1>Done building project "sk3wldbg.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I was getting a few strange messages about segfaults on my dmesg, and decided to investigate.
It seems that when I use IDA with the sk3wldbg plugin (I'm using the pre-built binaries), it crashes on exit. So far it resulted in one database being corrupted.

Unfortunately the gdb stack trace doesn't help, as there are few symbols, but it's definitely something to do with a QT object deletion.

Thread 1 "idaq" received signal SIGSEGV, Segmentation fault.
0x08a9dab7 in ?? ()
(gdb) bt
#0 0x08a9dab7 in ?? ()
#1 0x08a9db49 in ?? ()
#2 0x08a0e246 in ?? ()
#3 0xdf261967 in QT::QHashData::free_helper(void ()(QT::QHashData::Node)) () from /ida/6.95/libQt5Core.so.5
#4 0x08a9d77a in ?? ()
#5 0xded8b79b in ?? () from /lib/i386-linux-gnu/libc.so.6
#6 0xded8b801 in exit () from /lib/i386-linux-gnu/libc.so.6
#7 0xded75282 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#8 0x089f2bcd in ?? ()

       0x0    0xb0000    0xb0000        0x0 
 0x8998000  0x8db6000   0x41e000        0x0 /ida/6.95/idaq
 0x8db6000  0x8dc9000    0x13000   0x41d000 /ida/6.95/idaq
 0x8dc9000  0x8dde000    0x15000   0x430000 /ida/6.95/idaq

As you can see from the stack trace and mappings, the crash comes from inside IDA.

Any idea what this might be?

It's definitely something to do with sk3wldbg, as it only happens when the plugin is loaded, and it happens both on idaq and idaq64.

I try to use the sk3wldbg plugin with IDA Pro 7.2 I could not get it to compile properly with 7.3 and the IDA SDK 7.3

I built the 64bit versions both of the unicorn engine and sk3wldbg and installed it at the proper place in the IDA installation directory.

The code I want to emulate is a small part of a Windows Kernel driver subroutine.
Basically it the code "mov"s some constants into stackspace and then performs some kind of calculation over these values in a loop.
I place the cursor on the first of these instructions and run the debugger and choose "Start from here".

IDA gives me the following errors:

found input file D:\driver.fffffa8001b0e000.sys
reading file of 28672 bytes
loadPE64
map_mem_zero(000000013FB90000, 000000013FB90400, 0x3)
Allocated at 000000013FB90000 in map_mem_zero
Copying bytes 0x0:0x400 into block
map_mem_zero(000000013FB91000, 000000013FB92000, 0x5)
Allocated at 000000013FB91000 in map_mem_zero
Copying bytes 0x1000:0x2000 into block
map_mem_zero(000000013FB92000, 000000013FB93000, 0x1)
Allocated at 000000013FB92000 in map_mem_zero
Copying bytes 0x2000:0x3000 into block
map_mem_zero(000000013FB93000, 000000013FB94000, 0x3)
Allocated at 000000013FB93000 in map_mem_zero
Copying bytes 0x3000:0x4000 into block
map_mem_zero(000000013FB94000, 000000013FB95000, 0x1)
Allocated at 000000013FB94000 in map_mem_zero
Copying bytes 0x4000:0x5000 into block
map_mem_zero(000000013FB95000, 000000013FB96000, 0x5)
Allocated at 000000013FB95000 in map_mem_zero
Copying bytes 0x5000:0x6000 into block
map_mem_zero(000000013FB96000, 000000013FB97000, 0x1)
Allocated at 000000013FB96000 in map_mem_zero
Copying bytes 0x6000:0x7000 into block
map_mem_zero(0000000000030000, 0000000000130000, 0x7)
Allocated at 0000000000030000 in map_mem_zero
map_mem_zero(000000013FB98000, 000000013FC98000, 0x3)
Allocated at 000000013FB98000 in map_mem_zero
PC was not set previously, going with screen EA13FB91000: process driver.fffffa8001b0e000.sys has started (pid=33476)
PDBSRC: loading symbols for 'driver.fffffa8001b0e000.sys'...
PDB: using PDBIDA provider
FFFFF80002690000: The instruction at FFFFF80002690000 attempted to execute from unmapped memory -> FFFFF80002690000 (exc.code b, tid 22773)

Whats wrong? Do I need to prepare something before I can start debugging the code?

The same error occurs when I choose to start from the entrypoint.

IDA 7.1 changed the API of debugging module. Please port to 7.1 if you have free time.
https://www.hex-rays.com/products/ida/7.1/debugger_api71_porting_guide.shtml

I let my license expire for IDA at 7.1 -- never downloaded the SDK because I thought that was a free download, but it turns out that it isn't and now I'm locked out from downloading it.

Is there any possibility that someone can create some pre-compiled releases? I'm running MacOS Catalina (10.15).

the "no-thread" branch of Unicorn was merged into the "master" branch, and got deleted. please update your README, thanks.

I'm using the precompiled binaries w/ IDA 6.9.1 on Linux.
After successfully loading & selecting skw3eldbg as the active debugger, whenever I attempt to launch the debugger IDA crashes with the following failed assertion:

ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to objects owned by a different thread. Current thread e71004b8. Receiver 'DebuggerSelected' (of type 'IdaMenu') was created in thread 91ae2c8", file kernel/qcoreapplication.cpp, line 519

There's no indication to what the problem might by in $IDALOG.

Can sk3wldbg emulate syscall of arm firmware ? I want debug arm firmware with sk3wldbg. Firmware is dynamic linking software.

I'm having trouble debugging a 16bit DOS EXE

I can get the debugger to launch and get to a entrypoint, but then as I step through each instruction, the debug view switches to lines prefixed with debug001:XXX and then subsequent steps are stuck within debug001 lines until the debug session ends. I also get this interesting warning on start-up.