Current work, next release

[ron...@ymail.com]

I'm actually developping and testing time based method, I'm re-using the blind module I had already created before for that purpose. Time based is very similar to blind and is even simpler, and the code should be less dirty, much more clear. For local testing, you can easily validate blind and timebased methods, each one is fast and the informations and databases appear both in place without problem, but it's different behind your network connection or worth, behind a proxy. I have tested blind using a proxy and this is very slow, I can hardly wait a very long time before validating some of my script live, so if you know open and free ways to test that faster, feel free to leave a message.
Blind and timebased need actually a valid initial tag for the job to work (tag 1 in [...]ulate_get?id=1), and I will try to make it work with any bad tag if it's possible, like [...]ulate_get?id=-1.

Also, for a safe extraction and parsing, I use hex encoding and it greatly multiplies the number of characters you have to read to obtain the final information, in fact the data is a long sequence of encoded characters, so maybe I can speed up blind and timebased with some tweaks, and if there are similar stuff to apply to normal and errorbased it should be an extra fast extraction. Speed-wise, the search for the initial tag (0,0',',-1,1,",-1)) and for the number of fields in normal mode is now threaded (select 1,2,3,...,100), also the proxy connection is tested, evasion is added (case sensitive, space, equal sign). I have read that you could break keywords with the stream comment /**/, like in sEl/**/EcT, but it seems it's not really working, I wonder if the database should match a specific version.

I think I will add a contextual menu to table names with entries 'load 1 row', 'load 10 rows', 'load all rows' because blind and timebased are awfully longer than normal and errorbased and you must wait too much before expecting any results.
For errorbased, I didn't notice the error was localized, in fact the message "Duplicate entry '%-.192s' for key %d" can be in another language, so I will change the code to match sentences that you can find in the files errmsg.sys located in \mysql\share.

Actually I manage to add features to the tool without very much problems, but I think it could become very ugly from the inside if I don't pay attention to design. I have read some papers on design pattern recently but for now I don't see the use of any of them, only MVC is actually present in it but I think some other pattern may help me and fit well somewhere (any advice will be greatly appreciated).

[alv....@gmail.com]

Good you are progresing so far with JSQL and many features you want to add, i was thinking maybing you could add optional table txt list and colunm txt list, where by user can make there own table list or get from havij table and colunm list, becuse blind injection take more time, sometime you think is not working, beside it take more system resource,

Maybe you can add multi threading to help blind injection working faster with table database colunm txt list.

if you dont mind you can send me the latest build to help you testing as well, your older jsql is cool smooth and faster but need more improvement,

on next jsql try to add STOP RESUME START AND SAVE OPTIONS OF DATAS

good luck

[ron...@ymail.com]

Thank you for that feedback, I really appreciate it. For now the tool is progressing slowly into what I expected: simplicity, as the user only interact for what the tool really can't do by itself (you make your choice with the data provided, the tool processes every other aspects automatically), and among others, control, as the user should know what's happening during the process. As you mentioned, sometimes you can think it's not working, because the task is too long or the response is unreadable crap, and I think the user must know that point very early to kill the process manually. For that purpose I'm testing a new information panel that contains every technical details of what is happening behind the scene, like url calls, or post, cookie, header data, and also response headers from the server, because when a process is started a lot of informations can be understand by you as errors, but the tool isn't that smart. Also for control, I'll use stop/pause/resume actions especially because blind and timebased should be killed when you could not stand the wait anymore (and I can't :)).

On the use of dictionary, I'm not very fond of that kind of method or anything that is not really guaranteed. For the moment I'm working on methods that should normally give results in the end or stop working early in the process. I think, maybe falsely, that dictionary isn't as interesting as others, I would like to learn more from users of dictionary method, do you get more frustration about consuming time without getting any result in the end, do you give dictionary credit?

Considering multithreading, the tool use threads already in many parts of the process, in fact only the trunks of data retrieved by normal and errorbased are not threaded because it's directly based on the results of the previous requests. It's not really efficient, but I remember that I did that because of safety and to avoid data loss, maybe I will rethink the algorithm and then I could thread that part too. If you think of something specific that could be more efficient with threads, you can leave me a word here.

Thank you for your time, I will definitely call you if some weird feature require an alpha test.

[alv....@gmail.com]

Great you are implementing all the features, that awsome, maybe it time to release the better for testing and checking for bugs and checking what features to add on the tool.

cheers