{"id":286,"date":"2025-12-22T14:20:47","date_gmt":"2025-12-22T14:20:47","guid":{"rendered":"https:\/\/haco.club\/?p=286"},"modified":"2025-12-22T14:20:47","modified_gmt":"2025-12-22T14:20:47","slug":"executable-startup-and-initialization","status":"publish","type":"post","link":"https:\/\/haco.zone\/?p=286","title":{"rendered":"Executable Startup And Initialization"},"content":{"rendered":"\n

CRT (C Runtime) “glue code”<\/strong> refers to a set of pre-compiled object files (typically crt1.o<\/code>, crti.o<\/code>, crtn.o<\/code>, crtbegin.o<\/code>, and crtend.o<\/code>) that are automatically linked with your program. They “glue” the operating system’s process loader to your main()<\/code> function by handling low-level setup (stack, environment) and high-level initialization (global constructors).<\/p>\n\n\n\n

Execution Order Summary:<\/strong><\/p>\n\n\n\n

    \n
  1. _start<\/code><\/strong> (Entry Point)<\/li>\n\n\n\n
  2. __libc_start_main<\/code><\/strong> (Standard C Library setup)<\/li>\n\n\n\n
  3. __libc_csu_init<\/code> \/ _init<\/code><\/strong> (Generic initialization hooks)<\/li>\n\n\n\n
  4. .init_array<\/code><\/strong> (Global constructors\/C++ initializers)<\/li>\n\n\n\n
  5. main()<\/code><\/strong> (Your code)<\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    Detailed Explanation<\/strong><\/h3>\n\n\n\n

    1. What is CRT Glue Code?<\/strong><\/h4>\n\n\n\n

    The “glue” consists of startup files provided by the OS (glibc) and the compiler (GCC\/Clang). They wrap your code to ensure the environment is ready before main<\/code> runs.<\/p>\n\n\n\n

      \n
    • crt1.o<\/code> (Start):<\/strong> Contains the actual entry point symbol _start<\/code><\/strong>. It sets up the very first stack frame and arguments before calling into the C library.<\/li>\n\n\n\n
    • crti.o<\/code> (Init Prologue):<\/strong> Contains the “header” (prologue) instructions for the _init<\/code> and _fini<\/code> functions.<\/li>\n\n\n\n
    • crtn.o<\/code> (Init Epilogue):<\/strong> Contains the “footer” (epilogue\/return) instructions for _init<\/code> and _fini<\/code>.<\/li>\n\n\n\n
    • crtbegin.o<\/code> \/ crtend.o<\/code>:<\/strong> Provided by the compiler (e.g., GCC) to handle language-specific features like C++ global constructors and destructors.<\/li>\n<\/ul>\n\n\n\n

      2. Execution Order of an Executable<\/strong><\/h4>\n\n\n\n

      Here is the step-by-step flow from the moment the kernel hands over control to the moment your code runs:<\/p>\n\n\n\n

      Step 1: The Kernel & _start<\/code><\/strong><\/p>\n\n\n\n

        \n
      • The OS loads the ELF binary and jumps to the address defined as the Entry Point<\/strong> (usually _start<\/code> inside crt1.o<\/code>).<\/li>\n\n\n\n
      • _start<\/code><\/strong> clears the frame pointer (ebp\/rbp) to mark the end of the stack trace.<\/li>\n\n\n\n
      • It grabs argc<\/code>, argv<\/code>, and envp<\/code> (environment variables) from the stack.<\/li>\n\n\n\n
      • It calls the helper function __libc_start_main<\/code>.<\/li>\n<\/ul>\n\n\n\n

        Step 2: __libc_start_main<\/code> (The Coordinator)<\/strong><\/p>\n\n\n\n

          \n
        • Located in glibc<\/code>.<\/li>\n\n\n\n
        • It performs critical setup: initializes threading (pthreads), security cookies (stack canary), and registers the cleanup function (rtld_fini<\/code>) for the dynamic linker.<\/li>\n\n\n\n
        • Crucially<\/strong>, it receives pointers to the program’s initialization functions (often __libc_csu_init<\/code> or similar) and calls them.<\/li>\n<\/ul>\n\n\n\n

          Step 3: Initialization Phase (The “Before Main” Logic)<\/strong>
          This is where the statement in your prompt comes into play. The CRT initialization code calls these in specific order:<\/p>\n\n\n\n

            \n
          1. _init<\/code> function:<\/strong>\n
              \n
            • Constructed from crti.o<\/code> + system-specific init code + crtn.o<\/code>.<\/li>\n\n\n\n
            • Historically used for setup, though now deprecated in favor of .init_array<\/code>.<\/li>\n\n\n\n
            • Executes strictly BEFORE .init_array<\/code>.<\/em><\/li>\n<\/ul>\n<\/li>\n\n\n\n
            • .init_array<\/code> processing:<\/strong>\n
                \n
              • The CRT iterates through the .init_array<\/code> section of the ELF file.<\/li>\n\n\n\n
              • This array contains function pointers to C++ global constructors<\/strong> and functions marked with __attribute__((constructor))<\/code>.<\/li>\n\n\n\n
              • These execute one by one.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n

                Step 4: main()<\/code><\/strong><\/p>\n\n\n\n

                  \n
                • Once all .init_array<\/code> functions return, __libc_start_main<\/code> finally calls your main(argc, argv, envp)<\/code><\/strong>.<\/li>\n<\/ul>\n\n\n\n

                  Step 5: Cleanup<\/strong><\/p>\n\n\n\n

                    \n
                  • When main<\/code> returns, exit()<\/code> is called.<\/li>\n\n\n\n
                  • This triggers functions in .fini_array<\/code><\/strong> (destructors) and finally _fini<\/code>.<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n

                    \u00a0CRT Symbols\u00a0<\/h3>\n\n\n\n
                      \n
                    • _start<\/li>\n\n\n\n
                    • deregister_tm_clones<\/li>\n\n\n\n
                    • register_tm_clones<\/li>\n\n\n\n
                    • __do_global_dtors_aux<\/li>\n\n\n\n
                    • frame_dummy<\/li>\n\n\n\n
                    • __libc_csu_init<\/li>\n\n\n\n
                    • __libc_csu_fini<\/li>\n<\/ul>\n\n\n\n

                      AFL++ Instrument<\/h3>\n\n\n\n

                      Unfortunately, in a stripped binary<\/strong>, you cannot reliably exclude these specific functions by name<\/strong> because their names are stripped. You’ll need to rely on heuristics<\/strong> and location<\/strong> to identify and exclude them.<\/p>\n\n\n\n

                      Here’s how to approach it, along with why it’s more challenging:<\/p>\n\n\n\n

                      The Challenge with Stripped Binaries<\/h3>\n\n\n\n
                        \n
                      • No Symbol Names:<\/strong>\u00a0deregister_tm_clones,\u00a0register_tm_clones,\u00a0__do_global_dtors_aux,\u00a0frame_dummy\u00a0are completely unknown.<\/li>\n\n\n\n
                      • Variable Location:<\/strong>\u00a0Their exact position and size can vary significantly between compiler versions, optimization levels, and even different target architectures (though you’re on ARM64).<\/li>\n\n\n\n
                      • Interdependence:<\/strong>\u00a0These functions might be called by other CRT code, or call into other parts of the CRT that you also need to exclude.<\/li>\n<\/ul>\n\n\n\n

                        Heuristics and Exclusion Strategies<\/h3>\n\n\n\n
                          \n
                        1. Entry Point Analysis (Still Key):<\/strong>\u00a0As discussed before, the initial analysis of\u00a0_start\u00a0is crucial. It gives you the addresses of\u00a0__libc_csu_init\u00a0and potentially\u00a0__libc_csu_fini. These are the “entry points” into the CRT initialization and cleanup sequences.<\/li>\n\n\n\n
                        2. __libc_csu_init\u00a0and\u00a0__libc_csu_fini:<\/strong>\n
                            \n
                          • __libc_csu_init:<\/strong>\u00a0This function is where\u00a0deregister_tm_clones\u00a0and\u00a0register_tm_clones\u00a0are often called. If you exclude\u00a0__libc_csu_init\u00a0(by finding its address from\u00a0_start), you are likely excluding the blocks that contain calls to these\u00a0tm_clones\u00a0functions.<\/li>\n\n\n\n
                          • __libc_csu_fini:<\/strong>\u00a0This function is the counterpart for cleanup.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                          • __do_global_dtors_aux:<\/strong>\n
                              \n
                            • Purpose:<\/strong>\u00a0This is responsible for calling the destructors of global C++ objects.<\/li>\n\n\n\n
                            • Heuristic:<\/strong>\u00a0It’s often called by\u00a0__libc_csu_fini\u00a0or the program’s exit handler. It typically involves iterating through a list of destructors and calling them. You might be able to identify it by looking for loops that call functions via indirect jumps or register manipulation. This is harder to pinpoint reliably.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                            • frame_dummy:<\/strong>\n
                                \n
                              • Purpose:<\/strong>\u00a0This is a compiler-generated function used for stack frame setup, often in functions that require frame pointers (even if\u00a0-fomit-frame-pointer\u00a0is used).<\/li>\n\n\n\n
                              • Heuristic:<\/strong>\u00a0It’s a very small function (often just a few instructions). It’s usually called by other CRT or compiler-generated functions. It’s quite hard to identify purely by disassembled code unless it’s a very obvious pattern and you can trace its caller.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n
                                \n\n\n\n

                                Practical Approach for Stripped Binaries:<\/h3>\n\n\n\n
                                  \n
                                1. Prioritize the “Big Wins”:<\/strong>\n
                                    \n
                                  • Entry Point (_start):<\/strong>\u00a0Always exclude.<\/li>\n\n\n\n
                                  • __libc_csu_init\u00a0and\u00a0__libc_csu_fini:<\/strong>\u00a0Exclude by finding their addresses from\u00a0_start. This is your highest priority, as it covers a lot of CRT code.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                  • The\u00a0cbz\u00a0Safety Net:<\/strong>\n
                                      \n
                                    • This is your primary defense.<\/strong>\u00a0Even if you miss some edge-case CRT blocks, the\u00a0cbz\u00a0instruction in your instrumentation callback will prevent the program from crashing. It’s extremely cheap performance-wise.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                    • Heuristic Exclusion for\u00a0__do_global_dtors_aux\u00a0and\u00a0frame_dummy\u00a0(Advanced):<\/strong>\n
                                        \n
                                      • __do_global_dtors_aux:<\/strong>\u00a0This is the most likely one you might want to\u00a0try<\/em>\u00a0to exclude after the\u00a0csu\u00a0functions. It’s usually called near the end of the program’s life. You might identify it by looking for code that loads a function pointer from a list and calls it. This requires some rudimentary static analysis or symbolic execution.<\/li>\n\n\n\n
                                      • frame_dummy:<\/strong>\u00a0This is the hardest to identify generically. It’s so small and often inlined or called indirectly. Trying to exclude it without symbols is generally\u00a0not worth the effort<\/strong>\u00a0compared to the robustness of the\u00a0cbz\u00a0instruction.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n
                                        \n\n\n\n

                                        Recommendation for Your Stripped Binary:<\/h3>\n\n\n\n
                                          \n
                                        1. Implement the\u00a0cbz\u00a0in your\u00a0bb_callback.<\/strong>\u00a0This is non-negotiable for reliability in stripped binaries.<\/li>\n\n\n\n
                                        2. Implement the\u00a0_start\u00a0and\u00a0__libc_csu_init\/fini\u00a0exclusion using Capstone analysis.<\/strong>\u00a0This will eliminate the most problematic CRT code.<\/li>\n\n\n\n
                                        3. Do NOT try to reliably exclude\u00a0__do_global_dtors_aux\u00a0or\u00a0frame_dummy<\/strong>\u00a0by heuristics alone in a stripped binary. The complexity and unreliability outweigh the benefits. The\u00a0cbz\u00a0will handle these cases gracefully.<\/li>\n<\/ol>\n\n\n\n

                                          By following this, you get the best of both worlds:<\/p>\n\n\n\n

                                            \n
                                          • Safety:<\/strong>\u00a0The\u00a0cbz\u00a0prevents crashes from uninitialized pointers.<\/li>\n\n\n\n
                                          • Performance:<\/strong>\u00a0You avoid instrumenting the main CRT initialization\/cleanup entry points.<\/li>\n\n\n\n
                                          • Simplicity:<\/strong>\u00a0You don’t have to build fragile heuristics for every single minor CRT helper function.<\/li>\n<\/ul>\n\n\n\n
                                            \n\n\n\n

                                            PS: For a single object (executable or shared library), the .init<\/code><\/strong> section is processed and executed before the functions in the .init_array<\/code><\/strong> section. <\/p>\n\n\n\n

                                            The typical execution order for initialization routines in an ELF binary is as follows: <\/p>\n\n\n\n

                                              \n
                                            1. Functions in the\u00a0.preinit_array<\/code><\/strong>\u00a0section (only in executables).<\/li>\n\n\n\n
                                            2. The code in the\u00a0.init<\/code><\/strong>\u00a0section.<\/li>\n\n\n\n
                                            3. Functions pointed to by entries in the\u00a0.init_array<\/code><\/strong>\u00a0section.\u00a0<\/li>\n<\/ol>\n\n\n\n

                                              This entire sequence happens as part of the C\/C++ runtime startup (often within a function like __libc_init_array()<\/code>), before<\/strong> the program’s main()<\/code> function is called. The .init<\/code> section is a legacy mechanism, and modern libraries and compilers (like GCC using __attribute__((constructor))<\/code>) primarily use the more flexible .init_array<\/code> section. <\/p>\n","protected":false},"excerpt":{"rendered":"

                                              CRT (C Runtime) “glue code” refers to a set of […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[30],"class_list":["post-286","post","type-post","status-publish","format-standard","hentry","category-knowledge-base","tag-binary"],"_links":{"self":[{"href":"https:\/\/haco.zone\/index.php?rest_route=\/wp\/v2\/posts\/286","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/haco.zone\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/haco.zone\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/haco.zone\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/haco.zone\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=286"}],"version-history":[{"count":1,"href":"https:\/\/haco.zone\/index.php?rest_route=\/wp\/v2\/posts\/286\/revisions"}],"predecessor-version":[{"id":287,"href":"https:\/\/haco.zone\/index.php?rest_route=\/wp\/v2\/posts\/286\/revisions\/287"}],"wp:attachment":[{"href":"https:\/\/haco.zone\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=286"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/haco.zone\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=286"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/haco.zone\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=286"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}