A little sql injection lesson for anyone who wants to try fucking with an automated scammer script for real:

You can't just give it an sql statement. The whole thing needs to be syntatically correct. The statement you're infecting into probably looks something like this:

INSERT INTO scam_responses ( user_id, question, response) VALUES ( $user_id, $question_id, "$response" )

Where $blah is a directive to replace $blah with the contents of that vairable in some scripting languages. So a response would need to close the string and the bracket and start a new statement (or series of statements) where adding '") ' would remain valid. Use semicolons to separate sql statements.

Eg, a response of:

deeznuts" ); UPDATE scam_responses SET response = "you've been hacked by mushrooms!"; INSERT INTO scam_responses ( user_id, question_id, response) VALUES ( 5, 0, "UPDATE scam_responses SET response = you've been hacked by mushrooms!

Would do the trick and might throw off their attempts to fix the security hole with that red herring "injection", which looks like the actual injection but isn't (and isn't even legal due to the lack of quotes).

Though you need to be able to guess enough table and column names to even do this, even if they don't sanitize the input properly, which is why having access to the source code makes a huge difference (since table/column names are usually in there, unless they are really fancy and store that information in another db, though in that case, they probably sanitize).

Though if you're using sql, use stored procedures instead of sql statement strings. You tend to get better performance, too (or at least that was the case back when I did this during the time of dinosaurs).