However, the debugger in OllyDbg just feels more natural and user-friendly to me than IDA’s, so I usually separate the two. This is because IDA offers a non-linear graph view for disassembly, which makes a program’s flow of execution much easier to understand. However, I personally prefer using OllyDbg for debugging and IDA for viewing the disassembly, but not everyone would agree with that statement. IDA is a more advanced tool than OllyDbg and has more to offer in terms of features and plugin support. Just a side note: if you’ve never used IDA before, you’ll notice some differences and similarities with OllyDbg. The freeware version is one major version behind the current release, but it still gets the job done.
You can download a freeware version here. If you recall, IDA is a powerful disassembler and debugger that is best suited for static analysis due to features like graph view and function naming. Once you open the memory map you can right-click any section of memory and dump it to disk, you can give it any filename you’d like.Īfter saving the memory segment, you can load it up with IDA to view the code. There are other ways to dump the memory, but this method will work fine for our example. In order to dump the memory to disk for analysis, the simplest approach is to use the memory map in OllyDbg, a tool mentioned in the first part of this series. I’m going to follow up right where we left off with our ZeroAccess Trojan called new-sirefef.exe, starting with dumping the ephemeral memory to disk for static analysis. In that article I’ll talked about some basic memory concepts to better aid readers in understanding how programs work when they enter memory and execute. About a month ago, I wrote a blog post explaining how malware can use process memory to its advantage, changing dramatically as it executes using ephemeral memory sections created at runtime.
0 kommentar(er)
