2

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: Note addresses EA75-EA78

The graph layout looks like this: enter image description here

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?

RobitZee
  • 41
  • 5

2 Answers2

2

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 :-/

RobitZee
  • 41
  • 5
  • One of the ea bytes was defined and had some wrong information in it would be my guess. You could probably automate it with Python using ida_bytes.del_items: undefine each byte in the function, then define function manually or again with python ida_bytes.create_data: https://reverseengineering.stackexchange.com/questions/6318/idapython-undefining-an-instruction https://reverseengineering.stackexchange.com/questions/29995/how-to-create-and-change-variables-at-address-in-ida-python – KulaGGin Apr 21 '22 at 13:41
0

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.

Sparkette
  • 166
  • 6