Reverse Engineering Asked by RobitZee on June 10, 2021
I’m reversing a binary dump of an older embedded target using IDA Pro 7.0.
Now I have somehow managed to introduce a “pseudo graph node” that I for the love of god cannot make go away.
The disassembly looks like this:
The graph layout looks like this:
The “Limit A to ZERO” node is a relic from a previous collapsed group of nodes that were probably collapsed when I undefined the function.
I cannot uncollapse it – nor does it disappear if I group it with other nodes and do a collapse/uncollapse/ungroup sequence.
Doing a “Layout graph” command has no effect and it survives when the function is undefined/recreated.
Any suggestions on how to completely reset the graph layout for the function?
FWIW:
I managed to restore the original graph by undefining the whole function, then recreate it one opcode at a time, starting from the bottom. At each step I made sure to switch into graph view - and at some point IDA drew a graph that was complete gibberish. I then right-clicked and selected the "Layout Graph" option, and viola - the complete graph of the function was back to normal once the whole function was re-defined.
I still don't know exactly what caused this behaviour :-/
Answered by RobitZee on June 10, 2021
I had this same problem, except worse than you described, as the code that was in one of the broken former-groups was now nowhere to be seen on the graph. Attempting to go to that code's address directly would bring me out of graph view, and attempting to switch back from there would tell me "only instructions belonging to functions can be displayed in graph mode", despite the fact that those instructions did belong to a function.
I tried something similar to what worked for @RobitZee, only I didn't do it for every single opcode because it was a huge function. It appeared to work at first, but then eventually the broken nodes mysteriously reappeared.
I downloaded pyidbutil to see if I could manually delete the graph data, only to find that it could only read databases, not modify them. I was still able to use it to help me fix the problem, however.
What I did was run pyidbutil with the -d
flag, which gave me a big dump of a whole bunch of data. Then, I found the text for the groups in that graph (in hexadecimal format) which were all listed together, with a larger blob of data right above them, that appeared to contain them. I opened up a hex editor, searched for these blobs of data (the smaller ones containing the strings as well as the larger one) and replaced all of them with 00's. (Keep in mind there's some other data between them, which will corrupt the database if overwritten.) Then I saved the database, keeping a backup of course.
After I zeroed out all that data, IDA was able to load the database just fine. The only warning it gave me (other than an unrelated one I always got) was of an invalid CRC32 checksum, but it gave me the option to ignore it. This appeared to reset the graph entirely, removing all group nodes (including the glitched ones) and putting the missing code back in the graph.
Finally, I closed, saved, and reloaded the database right after. This was to replace my hacky-but-functional edit with the proper serialization of what IDA loaded, which fixed the CRC32, likely among other things. The database, including the now-uncorrupted graph, saved without issue.
Keep in mind that this fix is almost certainly unsupported, and I can't guarantee it will work properly for you.
Answered by flarn2006 on June 10, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP