[QUOTE=sambooo;33859974]The devs shouldn't have been so lazy, they got exactly what they deserved[/QUOTE]
It's funny you know.. but I bet a lot of console games have systems like this.
[QUOTE=garry;33860093]It's funny you know.. but I bet a lot of console games have systems like this.[/QUOTE]
Atleast in console games its a bit harder to find
The linux version looked like if it was built with goddamn debugging information in
[QUOTE=voodooattack;33860017]I'm actually quite surprised by how mature you're all acting. Is this still facepunch? :tinfoil:[/QUOTE]
You are aware we're programmers, right?
[editline]24th December 2011[/editline]
[QUOTE=sambooo;33859974]The devs shouldn't have been so lazy, they got exactly what they deserved[/QUOTE]
At the expense of the players.
[QUOTE=Jookia;33860195]You are aware we're programmers, right?[/QUOTE]
Do you remember when someone posted an app that sends SMS messages through gmail and forgot to remove his personal account information?
Yeah.
Oh and apparantly someone cleared out all level data, and it causes the game to crash because its just 1 length with a null in it
Do I smell a potential exploit? :v:
I'm attempting to optimize the calculation of an angle between two vectors by using the Quake fast inverse square root algorithm. For some reason, it's inexplicably crashing when the input value is 0xEF3A7B9A
[cpp]
float fastInvSqrt(float x) {
float xhalf = 0.5f * x;
int i = *(int*)&x;
i = 0x5f3759d5 - (i >> 1);
x = *(float*)&i; //this runs
x = x*(1.5f - xhalf*x*x); //the crash occurs here
return x; //this never runs
}
[/cpp]
Any ideas?
[QUOTE=voodooattack;33860360]Do you remember when someone posted an app that sends SMS messages through gmail and forgot to remove his personal account information?
Yeah.[/QUOTE]
That doesn't mean he's not mature, it means he's an idiot.
They changed the password to the MySQL DB
Lets see if they restore from the backup we made
[QUOTE=grlira;33860421]I'm attempting to optimize the calculation of an angle between two vectors by using the Quake fast inverse square root algorithm. For some reason, it's inexplicably crashing when the input value is 0xEF3A7B9A
[cpp]
float fastInvSqrt(float x) {
float xhalf = 0.5f * x;
int i = *(int*)&x;
i = 0x5f3759d5 - (i >> 1);
x = *(float*)&i; //this runs
x = x*(1.5f - xhalf*x*x); //the crash occurs here
return x; //this never runs
}
[/cpp]
Any ideas?[/QUOTE]
If you're using a half-modern CPU it's much faster to use the built-in sqrt function because it is implemented in hardware.
[QUOTE=Jookia;33860459]That doesn't mean he's not mature, it means he's an idiot.[/QUOTE]
Er.... I'm talking about what happened to his account. :v:
[QUOTE=Robber;33860505]If you're using a half-modern CPU it's much faster to use the built-in sqrt function because it is implemented in hardware.[/QUOTE]
Actually, I need to run this code in two situations: in a VMware virtual machine and on a physical PC. Both running the Minix 3 operating system (don't ask).
[editline]Edit:[/editline]
And btw, the compiler is the acient ACK (amsterdam compiler kit), which comes with Minix. So I doubt it takes advantage of any modern improvements in architecture.
[QUOTE=voodooattack;33860539]Er.... I'm talking about what happened to his account. :v:[/QUOTE]
And what happened to the database here?
[editline]24th December 2011[/editline]
[QUOTE=garry;33860093]It's funny you know.. but I bet a lot of console games have systems like this.[/QUOTE]
Funny, this is a console game.
[QUOTE=Jookia;33860552]And what happened to the database here?[/QUOTE]
The exact opposite, which is my point. I think Edmund McMillen got a Get Out of Jail Free card with that database backup.
[img]http://dl.dropbox.com/u/4838268/mad.png[/img]
They seem rather mad
On another note I just realized I forgot to use a proxy :v:
I will laugh if they don't learn anything from this and still keep the information in the code and we get the new password
I mean, they didn't care at first and did nothing about it.
Later they say "sorry for the mishap, we will reupload the chapters and such"
[QUOTE=uitham;33861131]I will laugh if they don't learn anything from this and still keep the information in the code and we get the new password
I mean, they didn't care at first and did nothing about it.
Later they say "sorry for the mishap, we will reupload the chapters and such"[/QUOTE]
Hey man, they've got it under control. Trust them.
I tweeted a link to the DB backup to them, I'm gonna guess other people did too
10 bucks on that they're just gonna change the permissions on some tables, or do something equally stupid
Bettter (slightly) terrain gen!
[img]http://dl.dropbox.com/u/6470891/thisorthis1.png[/img]
Still need to add proper continents, but for the moment land will just have to be one big island :v:
Wake up, read thread; "Haha, oh wow."
[QUOTE=Sam Za Nemesis;33861827]What is impressive is that no one noticed the password in the game files until now, considering how long they've added that Super Meat World chapter[/QUOTE]
I'm incredibly tempted to look through other indie games and see if they do the same.
[QUOTE=Sam Za Nemesis;33861827]What is impressive is that no one noticed the password in the game files until now, considering how long they've added that Super Meat World chapter[/QUOTE]
Security through obscurity.
No one thought they'd be stupid enough to leave a password in plaintext in the exe, so no one looked.
I mean, if I were making a thing like this I WOULD NOT EVEN CONSIDER this. It would literally not even pop into my mind as a "bad idea," IT WOULD NOT OCCUR AT ALL.
While we're on the topic of security through obscurity, I wanted some input on something critical that Henry [url=http://www.facepunch.com/members/297452-Hentie](Hentie)[/url] and I are working on.
In Half-Life 2: Sandbox, we're presented with a problem that's all too familiar. We need to send client-side Lua files to connecting players. We basically have a .zip file which is called a .lcf (or Lua Cache File) that we're going to pack full of the individual Lua files that are sent through sendfile() to these players.
The idea is that we have the player only run these files, and nothing else, but we realize that this is an additive approach in that these are additional files (besides the ones that come with the mod) that need to be ran.
What should we do to ensure that the client is running files that only we authorize? I don't see many solutions here considering the complexity of the situation and the power the client is provided with in the first place. There's also a concern that everything needs to be validated before the client even fully spawns in the server, since it's not really acceptable to be doing checks by the time the player has first spawned.
[editline]23rd December 2011[/editline]
Problems I already see:
*We provide lua51.dll as a dynamically linked library. (This opens a lot of shit up, we should be statically baking the binaries in soon or something.)
*We're open source.
*Even if we find a way to do some sort of authorization, you could scan for the functions to run Lua files at anytime.
There's probably a lot more here that I'm missing, but these things come to mind first.
[QUOTE=Tobba;33860398]Oh and apparantly someone cleared out all level data, and it causes the game to crash because its just 1 length with a null in it
Do I smell a potential exploit? :v:[/QUOTE]
Oh yeah, I did that too. I replaced all levels with 0x00.
You should have made every level be a swastika.
[QUOTE=amcfaggot;33862028]While we're on the topic of security through obscurity, I wanted some input on something critical that Henry [url=http://www.facepunch.com/members/297452-Hentie](Hentie)[/url] and I are working on.
In Half-Life 2: Sandbox, we're presented with a problem that's all too familiar. We need to send client-side Lua files to connecting players. We basically have a .zip file which is called a .lcf (or Lua Cache File) that we're going to pack full of the individual Lua files that are sent through sendfile() to these players.
The idea is that we have the player only run these files, and nothing else, but we realize that this is an additive approach in that these are additional files (besides the ones that come with the mod) that need to be ran.
What should we do to ensure that the client is running files that only we authorize? I don't see many solutions here considering the complexity of the situation and the power the client is provided with in the first place. There's also a concern that everything needs to be validated before the client even fully spawns in the server, since it's not really acceptable to be doing checks by the time the player has first spawned.
[editline]23rd December 2011[/editline]
Problems I already see:
*We provide lua51.dll as a dynamically linked library. (This opens a lot of shit up, we should be statically baking the binaries in soon or something.)
*We're open source.
*Even if we find a way to do some sort of authorization, you could scan for the functions to run Lua files at anytime.
There's probably a lot more here that I'm missing, but these things come to mind first.[/QUOTE]
This is an age old problem, and there is no real solution. You have to build your system on the assumption that people will be running their own files.
[QUOTE=Catdaemon;33862309]This is an age old problem, and there is no real solution. You have to build your system on the assumption that people will be running their own files.[/QUOTE]
Thanks, I've been getting the same feedback from other folks, so I guess that's just how it is. Maybe if there's something further down the line I can do, I'll do that, but for now I guess we'll just worry about getting the files sent and ran.
[QUOTE=amcfaggot;33862028]While we're on the topic of security through obscurity, I wanted some input on something critical that Henry [url=http://www.facepunch.com/members/297452-Hentie](Hentie)[/url] and I are working on.
In Half-Life 2: Sandbox, we're presented with a problem that's all too familiar. We need to send client-side Lua files to connecting players. We basically have a .zip file which is called a .lcf (or Lua Cache File) that we're going to pack full of the individual Lua files that are sent through sendfile() to these players.
The idea is that we have the player only run these files, and nothing else, but we realize that this is an additive approach in that these are additional files (besides the ones that come with the mod) that need to be ran.
What should we do to ensure that the client is running files that only we authorize? I don't see many solutions here considering the complexity of the situation and the power the client is provided with in the first place. There's also a concern that everything needs to be validated before the client even fully spawns in the server, since it's not really acceptable to be doing checks by the time the player has first spawned.
[editline]23rd December 2011[/editline]
Problems I already see:
*We provide lua51.dll as a dynamically linked library. (This opens a lot of shit up, we should be statically baking the binaries in soon or something.)
*We're open source.
*Even if we find a way to do some sort of authorization, you could scan for the functions to run Lua files at anytime.
There's probably a lot more here that I'm missing, but these things come to mind first.[/QUOTE]
There isn't really anything that you can do because the players could just join with a modified binary of the mod.
[editline]23rd December 2011[/editline]
Woops, late.
[QUOTE=Yogurt;33862258]You should have made every level be a swastika.[/QUOTE]
Or giant dicks
