Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stuck at 'Analyzing gaps' for a suspiciously long time. #81

Open
Raphtaliyah opened this issue Nov 13, 2024 · 3 comments
Open

Stuck at 'Analyzing gaps' for a suspiciously long time. #81

Raphtaliyah opened this issue Nov 13, 2024 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@Raphtaliyah
Copy link

Describe the bug
Ghidra (11.2.*) spends a suspiciously long time at the 'Analyzing gaps' step when analysing a 9 MB 32 bit windows executable (the same executable from cmu-sei/pharos#274). At first I didn't want to report this as a bug because "surely it just takes this long" until I saw a similar issue (#65) where someone was analysing a larger executable for 9 hours and after a fix it end up being 640 seconds so I assume something has to be wrong here as well and it shouldn't take this long.

Looking at the logs (of which I have 2 GBs of (spread across 29 files) just from this!) it's mostly Skipping address, searching for any of the addresses shows around 67 matches/file. Looking for anything not Skipping address is Created alignment at:, the addresses are unique but in between them there is this repeating:

2024-11-05 22:56:10 DEBUG (X86ImproverStrategy) Disassembly status at 006c7983 was: Disassembler requires a start which is an undefined code unit  
2024-11-05 22:56:10 DEBUG (X86ImproverStrategy) Disassembly status at 006c7993 was: Disassembler requires a start which is an undefined code unit  
2024-11-05 22:56:10 DEBUG (X86ImproverStrategy) Disassembly status at 006c7aba was: Disassembler requires a start which is an undefined code unit  
2024-11-05 22:56:10 DEBUG (X86ImproverStrategy) Disassembly status at 00709d14 was: Disassembler requires a start which is an undefined code unit  
2024-11-05 22:56:10 DEBUG (X86ImproverStrategy) Disassembly status at 007819f0 was: Disassembler requires a start which is an undefined code unit 

Always the same address.

There is nothing else in the log files (other than when I stopped it), Kaiju Disassembly Improvements ran for 14 hours and did 26880 iterations.

To Reproduce
Steps to reproduce the behavior:

  1. Start analysis on the executable with the default settings with WindowsPE x86 Propagate External Parameters and Decompiler Parameter ID (with a really high timeout) enabled.
  2. Wait a lot...

Expected behavior
Less waiting? (Unless this isn't a bug and is expected behaviour...)

Desktop (please complete the following information):

  • OS: Fedora Linux 41 (KDE)
@sei-eschwartz
Copy link

Thanks for reporting. This definitely sounds like a bug to me. Did this happen to be for the same executable that you already shared with me?

@sei-eschwartz sei-eschwartz added the bug Something isn't working label Nov 13, 2024
@Raphtaliyah
Copy link
Author

Yes, it's the same!

@sei-eschwartz
Copy link

Without disassembly improvements:

2024-11-13 14:04:54 INFO (AutoAnalysisManager) -----------------------------------------------------
      ASCII Strings 2.798 secs
      Apply Data Archives 0.325 secs
      Call Convention ID 0.199 secs
      Call-Fixup Installer 0.633 secs
      Create Address Tables 1.459 secs
      Create Address Tables - One Time 10.360 secs
      Create Function 3.597 secs
      Data Reference 2.287 secs
      Decompiler Switch Analysis 62.805 secs
      Decompiler Switch Analysis - One Time 788.057 secs
      Demangler Microsoft 0.342 secs
      Disassemble 7.303 secs
      Disassemble Entry Points 2.235 secs
      Disassemble Entry Points - One Time 0.002 secs
      Embedded Media 0.287 secs
      External Entry References 0.002 secs
      Function ID 5.857 secs
      Function Start Pre Search 0.061 secs
      Function Start Search 2.144 secs
      Function Start Search After Code 2.150 secs
      Function Start Search After Data 1.366 secs
      Function Start Search delayed - One Time 0.049 secs
      Kaiju Function Hashing 28.663 secs
      Non-Returning Functions - Discovered 8.774 secs
      Non-Returning Functions - Known 0.005 secs
      PDB Universal 0.008 secs
      Reference 2.359 secs
      Scalar Operand References 6.959 secs
      Shared Return Calls 1.789 secs
      Stack 23.121 secs
      Subroutine References 2.132 secs
      Subroutine References - One Time 0.088 secs
      Windows x86 PE Exception Handling 5.720 secs
      Windows x86 PE RTTI Analyzer 17.349 secs
      Windows x86 Thread Environment Block (TEB) Analyzer 0.012 secs
      WindowsResourceReference 0.961 secs
      X86 Function Callee Purge 26.814 secs
      x86 Constant Reference Analyzer 22.840 secs
      -----------------------------------------------------
      Total Time 1041 secs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants