Skip to content

Complete Code Coverage

Jump to bottom
Bw3ll edited this page Jan 5, 2023 · 3 revisions

Complete code coverage has been revamped considerably with some inner functionality having been changed, and its speed and performance have been enhanced. Additional new features have been created. Code coverage is an optional feature that must be turned on via the Emulator submenu. Additional customization is possible, although for most users it is strongly recommend to stick with the default settings used with complete code coverage. However, there may be times when expert users may want to occasionally change settings for special instances of shellcode. Any divergence from the default settings should be done on a case by case basis.

Discussion on some of these features follows:

  • Previously, SHAREM created a very large .tmp file of for each code coverage object. This has been replaced by saving memory pointed to by ESP or EBP. (This was an older feature that had been replaced by using multiple temp files.) Note that either of these could change and diverge; e.g. EBP could point to a random location of memory. In any case, snapshots of memory pointed to by ESP and EBP will be saved for each code coverage object. The default setting is 4000 bytes, but that could be increased or decreased as desired by the user. If the shellcode ends without certain code being traversed, it will restart, restoring registers, including EFLAG, and restore memory. (This can also be tested via timeless debugging and timeless debugging for the stack.)

  • After a shellcode ends, it restarts, to revisit any existing code coverage objects. In ideal circumstances, we would always let SHAREM continue emulation, even if it goes over already traversed code. However, in some cases this could increase the time required to emulate - sometimes considerably, if one gets caught in nested loops.

  • Including CALL instructions generally seems like a good idea. Here we take the address of the next instruction, and we make sure to revisit it. If the shellcode author was sloppy, there possibly could be non-code (i.e. data) that follows a CALL.

  • All jump conditionals are included, and those are NOT problematic for code coverage. JMP instructions is not something we had originally planned to include with code coverage, because we do not know what would follow a JMP. It could be any manner of data - strings, checksums, etc. So this generally is not a good setting to have on by default. Still, what about situations such as jump tables produced by switch statements? Ok, in that situation, SHAREM can help you discover some (potentially even all code) depending on how the jump table is built (and if there is not data randomly inserted). However, if you think about it, having a jump table in shellcode is extremely unnatural, and likely this would need to be carefully created artificially by the shellcode author using GetPC (Call Pop) and manually writing the addresses into jump tables. Easy for a compiler or normal Assembly - less so for shellcode. Still, we provide support.

  • Recognizing the potentially problematic nature of including JMP instructions, we decided to include addresses to EXCLUDE. For instance, maybe you have a jump table or some other reason for including JMP instructions, but there is some data that immediately follows a JMP. This can be excluded by entering the address in a special JSON file located at sharem\sharem\sharem\sharem\skipAddressesCCC.json in SHAREM. Within the JSON, you can provide an address and the the number of bytes that follow to be excluded from code coverage. E.g. {"0x12000005": 4, "0xdeadc0de": 3} Addresses from 0x12000005 thru 0x12000008 would now be excluded. The base address is 0x12000000. Thus, if we had a chunk of data that immediately followed a JMP that we wished to exclude, we could do so. While I do not imagine this feature is much useful with CALL instructions - assuming the shellcode author is competent - it could common in handy for the same reason, if the author is sloppy.

  • Highly verbose code coverage debugging info can be displayed to the screen if desirable. This likely would not be of much interest to most people.

  • If code coverage is used, then offsets for addressed that were traversed as instructions can be displayed in green, while non-traversed code or data will be in cyan. This could be useful if someone is trying to figure out if a patch of code got hit via code coverage. All data - even those accessed - will also be in cyan.

All of these settings can also be configured via the config file, at sharem\sharem\sharem\sharem\config.cfg as indeed many settings can be tweaked there. Note that if you make changes in the config file in the UI, you can also save the config, updating what you used in that session, to the config file.

Clone this wiki locally