burp-rest-api.bat is showing "The supplied license key was not recognized.." error even after providing a valid license key
S3cButch3r opened this issue · 5 comments
After installing Burp suite pro with a valid license key and running the "burp-rest-api.bat" from the installed directory, The script seems to be again asking for key for activating burp. I tried a second time by removing the license key from burp from the UI and then entered the key when the script asked for it but same error is showing on the terminal that "The supplied license key was not recognized..".
The attached screenshots shows the error message and the log while running the bat file and the java version running on the system
Steps to Reproduce
These were the steps that I did while experiencing the issue and can be used to reproduce the same behavior(I tried the same steps in 2 different Windows machines running the same OS and got the same results:
- Install a new "Windows Server 2019 Standard" virtual machine or use a fresh version of windows to install the rest api
- Install latest JDK and set JAVA_HOME env variable
- Install latest version of Burpsuite pro and activate it using a valid license key after opening the application(using GUI) and create a sample project(not temporary) then close Burp
- copy the burp-rest-api-2.2.0.jar & burp-rest-api.bat to Burpsuite pro installation directory and open "burp-rest-api.bat" from a terminal in the same location
Screenshots
Java version in Windows Server 2019 Standard machine
Error shown while running "burp-rest-api.bat"
Desktop:
- OS: Windows Server 2019 Standard
- Burp Suite Professional version 2022.9.5
- Extension burp-rest-api version 2.2.0
Note:
A long time ago I used this same method to configure the burp-rest-api on a Windows 10 VM and it's still working without any issues on it. Occasionally It'll ask for the key when the license expires so at that time a small pop up will come and I activate it using my license. That system has the following versions of application and APIs
- OS: Windows 10(VM)
- Burp Suite Professional version 2022.8.5
- java version "17.0.2" 2022-01-18 LTS
Java(TM) SE Runtime Environment (build 17.0.2+8-LTS-86)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.2+8-LTS-86, mixed mode, sharing) - Extension burp-rest-api version 2.2.0
even burp-rest-api.sh showing same error
I've tried to reproduce and cannot.
A couple of things:
- You shouldn't use Burp-Rest-API from the default Burpsuite pro installation directory. You should create a directory and place there
burp-rest-api-2.2.0.jar
,burp-rest-api.bat
and theBurp JAR
from https://portswigger.net/burp/releases. Do not use the JAR from the automatic installation - The first time you use Burp Suite on that machine / user, you're expected to run
./burp-rest-api.sh --headless.mode=false
, add the license and then close Burp.
Can you please try again following the instructions above? Also, anytime you have problems please execute Burp with headless.mode=false
so that we can understand what's going on
I was able to resolve it, please check the recommended version of java to be installed.
I downgraded the java and it works cool.
If you want to avoid entering a license in the CLI, run the burpsuite-pro.jar before only and activate it, hence the config file inside Linux would be set by default. When you run api jar it'll check for the licence config and activate it.
Thanks @iamsharan for the follow-up. I will close this.
Hi,
I am facing the exact same issue mentioned above.
I'm using a Microsoft Windows Server 2016 (standard)
Burp Suite Professional v2023.2.4
Java version "17.0.2"
Gradle version "7.3.3"
Burp-rest-api-2.2.0
I've also tested this using Java 8 and 11 but I still get asked for my burp license every time I run the burp-rest-api bat. However, the Burp Suite Pro Jar file on it's own opens without any issues (with Java 11 and 17, not 8) and the exe also opens without any issues.
I've got the exact same setup on my local machine (windows 10) and everything is working as expected there.
I've tried all the recommended steps mentioned in the previous comments but the issue still persists.