You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was also something that was experimented with during "toolbag" as a way of showing a user what they've currently visited and what tags are available at different locations. This was scrapped when the plugin was named "idascripts" due to the desire to keep gui-related components out of the repository, but made its way into "toolbag" as the infinitely awesome "history" view. Its only issue is that it required manual input to add locations to it.
It'd be nice, however, if there was a similar (but internal) data structure that could be used to store locations as the user navigates through the database. This way a user can immediately see what tags are available at different positions instead of requiring they manually list them via database.tags or function.tags.
IDA's navigation stack is simply that, a stack. However, code that is compiled is stored as a tree, and when executed is best represented as a graph. Therefore, if we have some kind of tree-like structure ("trie"), then this might simplify the sharing and recalling of navigation history within a database.
This component can then actually be used to replace IDA's concept of "marks". This way instead of marking a specific address in the database, the user can create and use a "trie" for each reversing project. It is suspected that this will vastly improve the way users keep track of things they have reversed within the database. This way when the user opens up a database, they can immediately list the different tries (or projects) they have previously created, select one of the projects they were working on, and then immediately pick up where they left off.
Again, this would allow a user to keep track of the different things they visited while working on a specific reversing problem and more importantly keep track of which tags they created for each node within the "trie". If this automatically updating "trie" is implemented, then maybe at some point we can create another plugin based on it that shows it as a history graph along with the tags that were made at each position in the same way the author of "toolbag" implemented it.
The text was updated successfully, but these errors were encountered:
arizvisa
changed the title
Feature: Expose IDA's navigation stack as a trie instead of a list that can be interacted with
Feature: Expose IDA's navigation stack as a tree instead of a list that can be interacted with
Oct 8, 2020
This was also something that was experimented with during "toolbag" as a way of showing a user what they've currently visited and what tags are available at different locations. This was scrapped when the plugin was named "idascripts" due to the desire to keep gui-related components out of the repository, but made its way into "toolbag" as the infinitely awesome "history" view. Its only issue is that it required manual input to add locations to it.
It'd be nice, however, if there was a similar (but internal) data structure that could be used to store locations as the user navigates through the database. This way a user can immediately see what tags are available at different positions instead of requiring they manually list them via
database.tags
orfunction.tags
.IDA's navigation stack is simply that, a stack. However, code that is compiled is stored as a tree, and when executed is best represented as a graph. Therefore, if we have some kind of tree-like structure ("trie"), then this might simplify the sharing and recalling of navigation history within a database.
This component can then actually be used to replace IDA's concept of "marks". This way instead of marking a specific address in the database, the user can create and use a "trie" for each reversing project. It is suspected that this will vastly improve the way users keep track of things they have reversed within the database. This way when the user opens up a database, they can immediately list the different tries (or projects) they have previously created, select one of the projects they were working on, and then immediately pick up where they left off.
Again, this would allow a user to keep track of the different things they visited while working on a specific reversing problem and more importantly keep track of which tags they created for each node within the "trie". If this automatically updating "trie" is implemented, then maybe at some point we can create another plugin based on it that shows it as a history graph along with the tags that were made at each position in the same way the author of "toolbag" implemented it.
The text was updated successfully, but these errors were encountered: