nancygold's Journal
 
[Most Recent Entries] [Calendar View] [Friends View]

Thursday, July 4th, 2024

    Time Event
    1:01p
    Fixing Switches and Decompiling Larger Functions with Ghidra
    When a function is large enough Ghidra fails to decompile it,
    giving the following message:
    
      exception while decompiling 7e7c:0b9c:
      Response buffer size exceded for: st.exe #6682 
    
    And we can have multiple such large functions even in a 1993 DOS program.
    Unfortunately Ghidra doesn't expose this buffer size setting.
    So the workaround for now, go to DecompileOptions.java, and changing
    `SUGGESTED_MAX_PAYLOAD_BYTES` to 100. It is misnamed BYTES, but really
    it is megabytes. After the change one has to recompile Ghidra.
    
    The function at 7e7c:0b9c requires 2000 decompile.
    There are some switch analysis errors (the computed jmp at 8699:19fe is botched)
    Decompiler also says stuff like "Low-level Error: Unlinked join address"
    
    The proper solution would be having a per-function setting and asking the user,
    if they want to increase the buffer size for that function, if the current size
    is not enough.
    
    But part of such functions arise due to Ghidra having troubles analyzing
    Borland C++ 3.0 produced switch code, collating unrelated program parts as
    switch cases. BC++ generates a very simple switch table at the end of
    a function. Yet Ghidra ignores it, generating jumps to absolutely random places.
    These can be fixed by clearing existing references by the jump's address,
    and then manually adding a set of COMPUTED_JUMP references. That technique
    can apparently also be used to trick the decompiler to join non-switch code
    into a switch, which can then be edited manually into a compilable form
    
    It would be nice if Ghidra did some sanity checks, that the jump target lies
    inside the function or anywhere near it. And if anything is suspicious,
    just asking user for further input, mentioning that SwitchOverride.java script.
    Apparently the 8bit and 16bit CPUs are not a huge priority, which is sad since
    16bit programs are small enough for a single person to handle and less boring
    than the modern 32bit or 64bit stuff, and yet everyone supports 32bit x86.


    Current Mood: amused

    << Previous Day 2024/07/04
    [Calendar]
    Next Day >>

About LJ.Rossia.org