Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timenator stuck at 50%, only using first payload #4

Open
dial25sd opened this issue Sep 1, 2022 · 5 comments
Open

Timenator stuck at 50%, only using first payload #4

dial25sd opened this issue Sep 1, 2022 · 5 comments

Comments

@dial25sd
Copy link

dial25sd commented Sep 1, 2022

Timeinator has been working flawlessy a few weeks ago, but is now showing an unexpected behaviour: Each run gets stuck at exactly 50% progress.
Logger++ reveals that requests are being properly sent by the extension, yet only for the very first payload. Subsequent payloads are being ignored. The intended timing analysis is hence impossible.

Observed this behaviour on different OS's, e.g. Win 10 and MacOS. Currently on Burp Pro v2022.8.2.

Let me know if I can help with more debug info to track this down.

@ustayready
Copy link

Ran into the same thing, came here to see if others had similar problems. Since this is posted back in September, I might just start debugging and look for a solution. I rely on this plugin for the standard deviation results 😬

@ustayready
Copy link

Found my problem, if the response doesn't have the field content-length, the rowData list can't get populated because the variable content_length never gets instantiated. The fix is simple, add a content_length variable and set it to 0:

Before

            analysis = self._helpers.analyzeResponse(
                response.getResponse())
            for header in analysis.getHeaders():
                if header.lower().startswith("content-length"):
                    content_length = int(header.split(": ")[1])
            meanTime = round(mean(results), 3)
            medianTime = round(median(results), 3)
            stdDevTime = round(stdDev(results), 3)
            minTime = int(min(results))
            maxTime = int(max(results))
            rowData = [
                payload, numReqs, statusCode,
                len(response.getResponse()), content_length, minTime,
                maxTime, meanTime, medianTime, stdDevTime]

After:

            analysis = self._helpers.analyzeResponse(
                response.getResponse())
            content_length = 0
            for header in analysis.getHeaders():
                if header.lower().startswith("content-length"):
                    content_length = int(header.split(": ")[1])
            meanTime = round(mean(results), 3)
            medianTime = round(median(results), 3)
            stdDevTime = round(stdDev(results), 3)
            minTime = int(min(results))
            maxTime = int(max(results))
            rowData = [
                payload, numReqs, statusCode,
                len(response.getResponse()), content_length, minTime,
                maxTime, meanTime, medianTime, stdDevTime]

@ret2src
Copy link

ret2src commented May 8, 2023

Ran into the same problem, would be great if somebody could merge the patch above...

@Grezzo
Copy link
Contributor

Grezzo commented May 9, 2023

@ret2src @ustayready thank you for the fox. If you submit a pull request, I’ll accept it (if I still can since I no longer work at F-Secure)

ret2src added a commit to ret2src/timeinator that referenced this issue May 9, 2023
@ret2src ret2src mentioned this issue May 9, 2023
@ret2src
Copy link

ret2src commented May 9, 2023

@Grezzo thank you very much, I've opened a PR: #5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants