Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[LoSboccacc]

Well tested over a long game that eventually crashed due to an out of memory error and the lua bot was always between 65 and 80k memory so as far as the tools tell me it is something that only happens with the bot installed but it is not in the bot itself

I think it’s correlated with the bot trying to spawn units that the player still has locked, because it happens more often with factions that have a long unit timer

[lethosor]

Was the game leaking memory (i.e. was its memory usage steadily increasing until it crashed)? It's also possible for "out of memory" errors to occur when something incorrectly tries to allocate a huge amount of memory all at once (sometimes as a result of undefined behavior), which doesn't necessarily result from a memory leak.

[milo christiansen]

I was reading an article where the author was deriding SQL as an unsafe abomination that should be destroyed (in pretty much those words). Now, personally I dislike SQL, and think it could be done much better, but that is beside the point.

I was thinking about his assertions that SQLi attacks are basically a reason to get rid of the language, when it just kind of came to me: "If you are using user input before preparing the SQL statement, you are doing it wrong."

If you prepare every statement you need when you initialize the DB, and then never touch SQL again aside from calling these prepared statements, it will be pretty darn hard to find an SQLi vulnerability. (In complex cases you may need to add more statements on the fly, in those cases construct the statement off to the side through a safe interface such as a function call that does not receive any "unclean" input.)

In short, SQLi vulnerabilities are like most other security problems, they are caused by nothing other than laziness and/or stupidity. It isn't SQL's fault.

Sure, there are ways to make it so idiots can't shoot their foot, but such solutions will never be standard since you really can't make them work the same everywhere.

[bloop_bleep]

^ Or just make sure to sanitize your inputs. It takes literally like a minute to write a function that escapes special characters.

[Reelya]

In the case of SQL it's non-special characters you need to worry about. Make sure to put quotes around all users strings, as well as to escape everything inside it.

[bloop_bleep]

Actually, I just remembered that SQL now includes input parametization, which sanitizes the inputs for you automatically. Perhaps the author was using an old version of SQL or something; I don't know how long it had this feature.

[milo christiansen]

Parameterized queries have been a thing for a long time. Matter of fact, some of the code in the article was using them

I can only conclude the guy was an idiot.

[Telgin]

I think the main problem, which I've seen over and over again, is that many programmers just don't know that they should do it, or care enough to do it.

In particular, there are a vast multitude of very old and very badly written PHP + MySQL tutorials that will gladly tell you to both use inputs without sanitization and echo out HTML without sanitzation, leading to an entirely new class of injection attacks.

[bloop_bleep]

I think the main problem, which I've seen over and over again, is that many programmers just don't know that they should do it, or care enough to do it.

In particular, there are a vast multitude of very old and very badly written PHP + MySQL tutorials that will gladly tell you to both use inputs without sanitization and echo out HTML without sanitzation, leading to an entirely new class of injection attacks.

Although, pretty much all up-to-date tutorials I've seen mention sanitization/parameterization. I think the main problem is old software written back when those tutorials you mention were more common, that just kinda stuck around because no one needed to change it, or couldn't change without a lot of effort.

[Telgin]

Very true, but I was literally handed some code to improve just a couple of weeks ago from a guy who manages internet circuits at our company, and it was littered with old style mysql() functions, which have these nice big and bright notices on the documentation about how they're deprecated and you should not use them for various reasons.

The code actually did not have any SQL injection vulnerabilities that I recall, but it was just a single step away, doing things like iterating over the result set and creating queries like so:

Code: [Select]

$query = "DESCRIBE " . $table;

$table didn't come from user input so it was safe, but I have no doubt in my mind that the programmer would have used user input in a similar fashion.  The code also had conspicuous "mysql_connect or die()" code at the top, which looks suspiciously like it came from some really old and bad tutorials I learned from 15 years ago.  Seems they're still too easy to find. 

[LoSboccacc]

SQL is rooted in group theory and it’s hard to fool math; just see how many sql comcepts sneaked their way into nosql databases to the point most nosql now have a sql wrapper..

But yeah anyone that does escaping on his own is a fool and his data is soon to be breached. Prepared statement were a thing when I started in 2004.

That won’t save you from second order sequel injections, if you insist storing scriptable object on the database (json, svg, that sort of thing gets interpreted after read)

[Mephisto]

Sure, there are ways to make it so idiots can't shoot their foot

The relevant idiots went off and created Mongo, inventing a whole new category of ways to shoot yourself in the foot.

[Telgin]

Oh boy, I can't count the number of times I've accidentally obliterated data by forgetting to use $set in an update instead of just providing what I expected to be the update values, only to find out later that Mongo replaced the document with it entirely.

[Parsely]

Can anyone recommend any books or online resources for reverse engineering? I really want to learn how that works. I want to be able to do what people who develop modding tools and emulators for old games can do.

[milo christiansen]

This write up shows many of the basic techniques for reversing data or save files.

Basically, you need to know a lot about binary data and how it is stored. You need to do a lot of guess work, lots of little tweaks to see if anything changes or breaks. Most importantly, you need to be able to write a custom program to read this data into forms that can be inspected more simply. Trying to figure everything out with just a hex editor will drive you crazy in short order.

BTW: I spent some time on Yoda Stories and identified a bunch of stuff beyond what that article describes (but not the script blocks sadly).

EDIT: I love this quote from the linked article: "A lot of times this process feels like playing a stubborn puzzle game (I should know, I make them)"