Sqlmap: Bug with scan

[Kuhicop]

[22:13:18] [INFO] parsing HTTP request from '/root/Escritorio/scan.txt'
[22:13:18] [CRITICAL] the specified HTTP request file does not exist

I replaced files for this files you fix:
https://github.com/sqlmapproject/sqlmap/commit/56b6bf72f440a40cb0c58a2552b721bf5f437a8d

But still not working

[stamparm]

That file doesn't exist and you are raising the Issue? How is that a bug. I've updated now the sqlmap to change the order of those messages (for you to not open new Issues), but still I don't see what's the bug here.

[Kuhicop]

LOOOOL
of course the file exist, it's a request from burp suite in .txt, and it's there ~/Escritorio/scan.txt

[stamparm]

Basically, your report is trivial at least. It looks like the problem is on your side. Also, you haven't spend a second on debugging it. Please don't raise any more issues

[Kuhicop]

I updated as you posted
@stamparm Update for an Issue #2472
I didn't see it, sorry. I'm getting the following error now when I open sqlmap

Traceback (most recent call last):
File "/usr/bin/sqlmap", line 35, in
from lib.controller.controller import start
File "/usr/share/sqlmap/lib/controller/controller.py", line 66, in
from lib.core.target import initTargetEnv
File "/usr/share/sqlmap/lib/core/target.py", line 47, in
from lib.core.option import _setDBMS
File "/usr/share/sqlmap/lib/core/option.py", line 60, in
from lib.core.common import saveConfig
ImportError: cannot import name saveConfig

[stamparm]

You are updating it wrongly. You should remove the existing sqlmap
installation and do the git clone as explained on sqlmap.org pages.

On Apr 11, 2017 21:53, "Kuhitacop" [e-mail] wrote:

I updated as you posted
@stamparm https://github.com/stamparm Update for an Issue #2472
https://github.com/sqlmapproject/sqlmap/issues/2472
I didn't see it, sorry. I'm getting the following error now when I open
sqlmap

Traceback (most recent call last):
File "/usr/bin/sqlmap", line 35, in
from lib.controller.controller import start
File "/usr/share/sqlmap/lib/controller/controller.py", line 66, in
from lib.core.target import initTargetEnv
File "/usr/share/sqlmap/lib/core/target.py", line 47, in
from lib.core.option import _setDBMS
File "/usr/share/sqlmap/lib/core/option.py", line 60, in
from lib.core.common import saveConfig
ImportError: cannot import name saveConfig

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sqlmapproject/sqlmap/issues/2472#issuecomment-293381153,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA4P05mRGEy3CXsNOE2CXupTC__k_lMgks5ru9o1gaJpZM4M5SA-
.

[noraj]

https://sqlmap-users.narkive.com/Xp6pjiG4/error-while-running-sqlmap-with-request-file

• Relative path :x: sqlmap -r test.req
• Absolute path :heavy_check_mark: sqlmap -r "$(pwd)/test.req"

[stamparm]

@noraj

Relative path :heavy_check_mark: :

Absolute path :heavy_check_mark: :

p.s. I guess that your sqlmap script is actually responsible for all your mess (most probably changing the pwd during the runtime)
p.p.s. tested with 3 different versions: pip installed, apt installed and regular git cloned source

[noraj]

2 options so:

1. The issue came from SQLmap and was fixed between 1.4.4.1 and 1.4.4.9
2. The issue is coming from AL packaging: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/sqlmap

It seems to be more likely option 2.

Update: it is option 2. https://bugs.archlinux.org/task/56287?project=5&string=sqlmapbut @stamparm it seems the guy had a hard time to create a proper wrapper. Can you take a look at it?

[stamparm]

@noraj:

1) As I can see from https://bugs.archlinux.org/task/56287#comment191051, somebody already provided a "way around"
2) Comments as "Again, I don't see how this could work sensibly without a proper entry point. E.g. using setup.py, which the upstream project doesn't have." are fun because there is always a PyPI version (e.g. available through pip install sqlmap) of a start-of-the-month sqlmap version <- thus, there is no need to use git clone version
3) Regarding point 2). People that complaint that "there is no proper environment" for a simple dependency-less python projects that runs out of the box, while that same "environment problem" is regarding a "problem" with changing of the running directory in some well-intuitive "why" it doesn't work situation, are FUN FUN FUN

[noraj]

Yes it's an issue with ArchLinux packaging. Using pip is out of question when talking about distro packaging. But the the AL maintainer is wrong there is not need of setup.py A setup.py would effectively ease the packaging but it's possible to do without it.
Actually 2 people in the AL issue said they fixed it and it was working but it seems the AL maintainer has a hard time to understand. We just need to way for the patch to be accepted.