2

What's that .00cfg section that is being added by Visual Studio 2017 to PE32+ binary files (for x64 builds)? I'm assuming it stands for "Control Flow Guard" section. It is relatively small and mostly empty:

enter image description here

Any idea what is the layout of data in it?

Improve this question

2 Answers 2

Reset to default
5

Windows loader does not care about section names, so the name does not really matter, but usually this section contains the pointer to the indirect call guard check (___guard_check_icall_fptr). The pointer to it is stored in the GuardCFCheckFunctionPointer field of the load configuration directory.

I guess in the newer files it may contain some additional pointers (see below). The zeroes are probably just padding to the default section alignment (512 or 1024 bytes, not sure which).

P.S. found a recent x64 PE with more pointers. Apparently the following is the full layout for a 32-byte section:

 __guard_check_icall_fptr       dq offset _guard_check_icall_nop
 __guard_dispatch_icall_fptr    dq offset _guard_dispatch_icall_nop
 __guard_ss_verify_failure_fptr dq offset __guard_ss_verify_failure_default
 __guard_ss_verify_sp_fptr      dq offset __guard_ss_verify_sp_default

First two pointers are part of the Control Flow Guard implementation, the other two are from the now-deprecated Return Flow Guard. All four are referenced by fields in the load configuration directory, i.e. in theory they don't have to be in this order or even placed together.

Improve this answer
2
  • Thanks. What was weird for me is that they chose to dedicate the entire section to that. Why not use an existing data section.
    – c00000fd
    Oct 10, 2018 at 19:35
  • in most binaries I've seen it's meged into .rdata or .text. Ifact, I'm not sure if I've ever seen it remaining separate. possibly your sample had some customization
    – Igor Skochinsky ♦
    Oct 10, 2018 at 19:44
2

The most useful reference I've seen about this section is in this Adobe source comment:

//
// Allocate xyz in the .00cfg so that it is implicitly merged into the 
// import section of the binary (which is read-only).
// Indirect calls using this pointer do not have the guard check function,
// and so will not fail the CFG check.
//

The code appears to add the following data to the section (assuming x64):

8 byte address the function
4 byte boolean (speculation) whether or not indirect calls should be verified.
4 byte boolean (speculation) whether or not the function pointer is valid.

I have yet to see any official documentation on the section though.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.