{
	"id": "bad38380-5746-4797-9831-ca2447f802dc",
	"created_at": "2026-04-06T00:06:40.35058Z",
	"updated_at": "2026-04-10T03:21:41.837611Z",
	"deleted_at": null,
	"sha1_hash": "1ffadd0abcd85fd9ad46117c761d3b4b21eb8ba8",
	"title": "Debugging Injected Code with IDA Pro",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 544042,
	"plain_text": "Debugging Injected Code with IDA Pro\r\nBy ~ by malwareninja on September 27, 2011.\r\nPublished: 2011-09-27 · Archived: 2026-04-05 17:04:19 UTC\r\nHello all!  Today I wanted to talk about how you go about debugging/analyzing injected code.  In today’s malware\r\nenvironment a lot of malicious code doesn’t sit resident in memory in the context of it’s own process.  Back in the\r\nday you could look at task manager and recognize some weird executable that didn’t belong.  Those days are\r\nmostly over.  The new(er) malware classes will typically inject malicious code and hook dll’s in legitimate looking\r\nprocesses (explorer.exe, winlogon.exe, svchost.exe, etc.) to evade detection.  This makes analyzing malware\r\ntrickier as you need a wider skill set than opening up a bad binary in IDA.  I’m going to shed some light on that\r\nprocess when you run into this type of malware.\r\nFirst off we need to find some malware that uses code injection.  Code injection is usually done through the\r\nWriteProcessMemory API call through Windows.  I’ve provided a sample here which just happens to be the\r\nshylock malware that was posted recently at Contagio.   Download to follow along (the password is infected). \r\nThis executable injects code into the explorer.exe process of the target machine (xp sp3 os running on virtualbox). \r\nThis is what we will be working with if you want to follow along.  Now I haven’t done a complete in depth-analysis on this yet (it’s coming) but I suspect there isn’t any VM breakout that will totally hose your host OS.  If\r\nthere is well sorry bout that! 😛 You need to also make sure your vm is accessible from your host machine.  I used\r\n‘Host-Only Networking‘ and made sure the guest was accessible from my host box.\r\nSo once you have your vm up (and it has an IP you can reach from your host box).  You’ll need to copy over to the\r\nshare a file that exists in your IDA Pro file to enable remote debugging. The file is “win32_remote.exe”.  This is a\r\nserver that allows IDA to connect up to a port on a remote server debugging to debug across the world or across\r\nmemory in the sense of a VM.  Now one caveat with this program is that it only allows one debugging session per\r\nserver (depending on version,  newer versions of IDA support multiple debugging sessions over the same port). \r\nSo if you want to debug 2 programs at the same time (which we will be doing) you need two instances of this\r\nrunning on different ports.  You specify the port with the -p flag and there is NO SPACES after the -p switch so if\r\nyou want to set it up on port 1000 you’d run “win32_remote -p1000” from the command line.  Tiga also has\r\nposted a video tutorial about remote debugging with IDA.  His entire tutorial series is very good.\r\nOpen up a IDA Pro and Run -\u003e Remote Win32 Debugger\r\nhttps://malwarereversing.wordpress.com/2011/09/27/debugging-injected-code-with-ida-pro/\r\nPage 1 of 5\n\nMake sure your connection/paths are correct.\r\nClick ok and  you’ll break at the entry point of the module\r\nhttps://malwarereversing.wordpress.com/2011/09/27/debugging-injected-code-with-ida-pro/\r\nPage 2 of 5\n\nNow we’re going to set a breakpoint at WriteProcessMemory() (In IDA that equates to\r\nkernel32_WriteProcessMemory.  From here on out it will be referred to as WriteProcessMemory)\r\nHit f9 to go and it breaks on WriteProcessMemory() (How did I know how to break here?  I reversed the program\r\nroughly to get a feel for the program from the beginning up until this point.)\r\nNow the code injection routine is a separate link here.  shows why we want to break on WriteProcessMemory(). \r\nThere are a few basic methods on how to inject code into a process that is not yours  on Windows.  Here is a good\r\nbreakdown describing those methods.  Most of the tactics revolve around WriteProcessMemory system call.  This\r\nparticular piece of malware uses the third type of injection mentioned in the code project article.  Before this\r\nspecific function was reached the malware took a snapshot of the system state and iterated through the processes\r\nuntil it found explorer.exe then called this function.  So the short version of the disassembly is that it opens the\r\ntarget process,  allocates some memory inside the process,  writes memory that was allocated (repeats 3 times),\r\nthen starts a remote thread to execute this new code, wait for thread to exit then cleanup handles.  The reason 3\r\nsections of memory are mapped into the target process is there is a loader there that reconstructs a dll in memory\r\nthat is allocated inside Explorer.  This happens all before the exit status code is returned from the thread and the\r\nhttps://malwarereversing.wordpress.com/2011/09/27/debugging-injected-code-with-ida-pro/\r\nPage 3 of 5\n\ncode is successfully injected.\r\nLet’s fire up another IDA instance and use the Attach -\u003e Remote Win32 Debugger and put in the port for the\r\nsecond server that was different than the first. Hit ok then we should see a process listing and let’s choose our\r\ninjected process (explorer.exe) from the menu. If you took note of the injected code locations from\r\nCreateRemoteThread structure.\r\nHANDLE WINAPI CreateRemoteThread(\r\n __inHANDLE hProcess,\r\n __inLPSECURITY_ATTRIBUTES lpThreadAttributes,\r\n __inSIZE_T dwStackSize,\r\n __inLPTHREAD_START_ROUTINE lpStartAddress,\r\n __inLPVOID lpParameter,\r\n __inDWORD dwCreationFlags,\r\n __outLPDWORD lpThreadId\r\n);\r\n __inLPTHREAD_START_ROUTINE lpStartAddress,\r\nlpStartAddress [in]\r\nA pointer to the application-defined function of type LPTHREAD_START_ROUTINE to be executed by\r\nthe thread and represents the starting address of the thread in the remote process. The function must exist in\r\nthe remote process. For more information, see ThreadProc.\r\nWe can mark this location with a breakpoint once we attach to explorer.exe (before the thread is started but after\r\nthe memory was written). Then we hit run in the shylock.exe (injector process) and then we should have a\r\nbreakpoint hit in explorer.exe and sure enough we do. We can continue on reversing from here but let’s dump this\r\nsegment and save it so we can annotate our debugging sessions and build on this previous knowledge. The way we\r\ncan do this in IDA is take a memory snapshot.  We have to View -\u003e Open Subviews -\u003e Segments so that we can\r\nview a memory map. Noting our addresses from WriteProcessMemory we need to change those segments to\r\nLoader segments. Next up go to Debugger and take memory snapshot and choose only Loader Segments. If you\r\nnotice in our column our only dump will be of the three sections we marked ‘Loader’ segment.  If you don’t mark\r\nthem as Loader segments IDA will ignore them and exclude from putting them into the database/idb.  Here you\r\nhave it and that’s how you dump injected code from any process with IDA Pro. Hope you enjoyed reading this\r\narticle.\r\nReferences:\r\n[1] – Tiga’s IDA video tutorials\r\n[2] – CodeProject Code Injection methods\r\n[3] – Contagio malware dump\r\nhttps://malwarereversing.wordpress.com/2011/09/27/debugging-injected-code-with-ida-pro/\r\nPage 4 of 5\n\n[4] – IDA Docs Page\r\n[5] – Virtualbox Networking Doc\r\nPosted in Uncategorized\r\nSource: https://malwarereversing.wordpress.com/2011/09/27/debugging-injected-code-with-ida-pro/\r\nhttps://malwarereversing.wordpress.com/2011/09/27/debugging-injected-code-with-ida-pro/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://malwarereversing.wordpress.com/2011/09/27/debugging-injected-code-with-ida-pro/"
	],
	"report_names": [
		"debugging-injected-code-with-ida-pro"
	],
	"threat_actors": [],
	"ts_created_at": 1775434000,
	"ts_updated_at": 1775791301,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1ffadd0abcd85fd9ad46117c761d3b4b21eb8ba8.pdf",
		"text": "https://archive.orkl.eu/1ffadd0abcd85fd9ad46117c761d3b4b21eb8ba8.txt",
		"img": "https://archive.orkl.eu/1ffadd0abcd85fd9ad46117c761d3b4b21eb8ba8.jpg"
	}
}