Saving and Restoring State
[Pro version] The functions to save and restore state can be accessed from the Burp menu.
Note: The functionality to save and restore state files is now deprecated, and state files have been superceded with Burp project files. At some future point, the functions to save and restore state files will be removed from Burp Suite.
The items that can be saved are as follows:
- The Target site map, which includes all of the content discovered via the Proxy and Spider, and Scanner issues.
- The Proxy history.
- The Scanner's active scan queue.
- The contents and histories of the Repeater tabs.
- The configuration of all suite tools.
Selecting "Save state" from the Burp menu launches a wizard where you can choose which items you want to save the state and configuration of, and select the output file. The following options are also available:
- Save in-scope items only - If this option is selected, only in-scope items from tools' state will be saved. This option is useful to remove superfluous content from the state file, and reduce the file size.
- Passwords within configuration options - This lets you configure whether any passwords contained in the tools' configuration (for example, credentials for an upstream proxy server) will be remembered, and if so whether they will be encrypted using a master password. When the state file is restored, Burp will prompt you to enter the passwords that were not saved, or to enter the master password, as appropriate.
You can continue using Burp while its state is being saved, although you may experience some brief delays if you try to perform an operation on data that Burp is in the process of saving, to prevent any data corruption.
Saving the Burp Collaborator Identifier
When saving state, you will be prompted whether to include within the state file the unique identifier that Burp uses to retrieve any ongoing Burp Collaborator interactions that are associated with the project. If two instances of Burp share the same identifier in ongoing work, then some Collaborator-based issues may be missed or incorrectly reported. You should not include the Collaborator identifier if you plan to pass the state file on to someone else and you do not want them to be able to receive details of any ongoing Collaborator interactions that are associated with your testing.
Selecting "Restore state" from the Burp menu launches a wizard where you can choose which items you want to restore the state and configuration of. The first step is to select a state file that you previously saved. Burp then analyses the file to determine its contents (i.e., the tools whose state and configuration it contains). You can then choose which tools' state and configuration you want to restore, and whether to add to or replace each tool's existing state.
You can optionally tell Burp to pause the Spider and Scanner tools following the restore. This option is on by default and is usually desirable when restoring an old state file, to avoid inadvertently attacking any targets which are in-scope for that state file and which have actions pending in the Spider or Scanner queues.
You can continue using Burp while its state is being restored, although you may experience some brief delays if you try to perform an operation on data that Burp is in the process of restoring, to prevent any data corruption.
Restoring State From a Different Burp Installation
If you restore a state file that was created by a different installation of Burp, then Burp will prompt you to decide whether to take full ownership of the project.
This decision is needed because Burp stores within the state file an identifier that is used to retrieve any ongoing Burp Collaborator interactions that are associated with the project. If two instances of Burp share the same identifier in ongoing work, then some Collaborator-based issues may be missed or incorrectly reported. You should only take full ownership of a project from a different Burp installation if no other instance of Burp is working on that project.