Ok but this project is open source. Anyone can go through the code to check for whatever they want. Sure, it might take a while, but it’s still publicly readable. For a game as high profile as Bloodborne is, its pretty unlikely that there isn’t about a hundred people combing through this one with a fine-tooth comb right now.
You’d have to be pretty stupid to try to sneak malware into open source code, have it hosted on GitHub, and push it live, like, you’re definitely getting caught by someone if you try that, right? I mean, I think I remember hearing that it happened a few times before, but I also remember that it was caught pretty quickly and corrected. Don’t remember if there was law enforcement involved or anything though.
Anyone can go through the code. And maybe find things, if they’re not too subtle and not successfully obfuscated. But not everyone will.
I feel like a malicious actor could hit a big pay day with a popular thing like Bloodborne, before people found the malice. There’s plenty of malware posing as game cracks out there, and it’s only easier to do that with AI tooling.
But aside from that, AI code can have confidentially incorrect code that has unwanted consequences.
That’s totally a thing people do. You can hide code in open source projects. You’re either hoping nobody cares enough to check, or you hope people don’t listen after someone checks and finds it. And even if people do find it, that is going to take some amount of time. During which, people are downloading it. And when caught, what do they lose? It’s not like this is an established user with a reputation.
Even if the people who made it didn’t intend to, an AI writing a bunch of code that (obviously) isn’t being vetted beyond “does it run” could very feasibly inject a backdoor/virus of some kind surreptitiously, just because it erroneously thought that was the goal at some point during generation.
This is why open weight models are not good enough. The AI could have been trained to take the right, niche opportunity to inject malicious code, and is also trained to otherwise never behave like that is the case.
Remember how the OpenAI/HuggingFace hack happened. The agents context poisoned other agents by leaving messages in a shared package manager. This has now happened multiple different times under different contexts.
This thing doesn’t even have to have malware, there’s no telling that it doesn’t have a poison pill intended to flag other agents. This isn’t even some paranoid conspiracy theory; it literally already happened, multiple times, and it was done in-spite of the agents own system prompt.
This software has proven that, given a shared information substrate, it has the capacity to paper-clip optimize into prompt injecting other LLM’s.
I fundamentally do not trust AI generated code. I shifted to OpenBSD because of it. I try my best to prevent AI in any of my software and sandbox anything that may have been compromised.
are you on the openbsd mailing list? the reason their code is better has a lot less to to with a lack of AI-generated code and a lot more to do with rigor. I’ve been watching them for a while now, they accept whatever code is coincise that meets their exacting standards
They don’t have the ability to detect if you’re using AI to code, no one does. they only know if you’re vibe coding, because they are incredibly experienced and intelligent, and they are pretty polite at the people who obviously are, more polite than i would be.
It’s correct that, at this point, I cannot 100% guarantee that code in the kernel did not pass through an LLM. However, having a policy that prohibits AI generated content, in an already pretty niche project, gives me reasonable assurance that every line of code passed through a human brain at some point, preferably several times.
I would much prefer to live in a world where I had a 100% guarantee that no LLM even saw the code being written but that’s life I suppose.
i think you’re in the inverse situation right now. you have a 100% guarantee that a human saw the code, except in ports. they have to be just a little less strict about ports because the world is an AI world now, but the main system is constantly audited and the ports are still better than in other places because of styling standards and even in ports they do try very hard.
these people aren’t getting paid, with the exception of Theo who isn’t paid a ton. AI is definitely being used to audit the code, even by some of the pros.
What difference does it make? Malware is malware, regardless of how or why it got there. And unofficial copies/releases of software are always prime targets.
You are referring to closed source unofficial cracks/patches/keygens. That is not the situation at hand. If those unofficial releases were open source in a time before AI, people would almost implicitly trust them.
The question above was asking why people were hesitant about this codebase even though it is open source. And the reason is that it was written by an unknown bot (or rather, series of bots) whose motives are inconsistent and unpredictable even to its prompter. It doesn’t mean it’s not safe, but it means that literally no human can currently be certain it’s safe. Without sufficient effort, we cannot yet know for certain that there isn’t a very cleverly obfuscated piece of malware lurking in this source.
Remember that correlation is not causation. You may believe there is correlation between unofficial releases and malware, and that may be true, but that does not mean it is causal. The point I’m making is that there is a literal causal relationship between unaudited AI reverse engineered code, and malware. And that is what is new and people need to be aware of.
It’s difficult to verify that the software does the desired thing in all cases. It’s also difficult to verify that it’s not also a keylogger or other unwanted thing.
It may also have some AI generated code path that, say, nukes your home directory because the AI determined that was the appropriate error handling. Maybe no one reviewed it so they don’t even know it’s there. It might not even be malicious.
That’s all true of any software, but rapidly created AI generated code for legally dubious efforts, by unknown agents (no pun intended) is real hecking risky.
We have a known compiled output. Simply make sure the decom recompiles to the original game with identical binary, then it can’t be that wrong.
And from there you port it to pc by hand. Auditing the patches for the porting also should be manageable.
Reproducible builds are hard to do and require thought being put in the original build. Even something like setting the time and date string to a different one will produce a different binary, so to get all the variables that went into the original compilation just right to be able to land on the same binary from the same code sounds very impractical. Imagine using that as a strategy to check another version of the whole source code…
I’ve recently seen a suite that has a ready made setup to compare sections of asm to the original.
Perfectly matching the full game or even binary isn’t necessary, when you already split the original apart into finer chunks, since you want some better feedback on exactly what sections are wrong.
For a basic example though, if you compile to an elf for example you can take out the code section and there’ll be no metadata. Actually gcc already builds reproducibly by default, even with the metadata section. It doesn’t add any timestamps nor version info.
Verifying that software does the intended task and only the intended task is not trivial.
Ok but this project is open source. Anyone can go through the code to check for whatever they want. Sure, it might take a while, but it’s still publicly readable. For a game as high profile as Bloodborne is, its pretty unlikely that there isn’t about a hundred people combing through this one with a fine-tooth comb right now.
You’d have to be pretty stupid to try to sneak malware into open source code, have it hosted on GitHub, and push it live, like, you’re definitely getting caught by someone if you try that, right? I mean, I think I remember hearing that it happened a few times before, but I also remember that it was caught pretty quickly and corrected. Don’t remember if there was law enforcement involved or anything though.
Anyone can go through the code. And maybe find things, if they’re not too subtle and not successfully obfuscated. But not everyone will.
I feel like a malicious actor could hit a big pay day with a popular thing like Bloodborne, before people found the malice. There’s plenty of malware posing as game cracks out there, and it’s only easier to do that with AI tooling.
But aside from that, AI code can have confidentially incorrect code that has unwanted consequences.
Code review is difficult.
That’s totally a thing people do. You can hide code in open source projects. You’re either hoping nobody cares enough to check, or you hope people don’t listen after someone checks and finds it. And even if people do find it, that is going to take some amount of time. During which, people are downloading it. And when caught, what do they lose? It’s not like this is an established user with a reputation.
What are you implying in this context?
It could be a virus.
Even if the people who made it didn’t intend to, an AI writing a bunch of code that (obviously) isn’t being vetted beyond “does it run” could very feasibly inject a backdoor/virus of some kind surreptitiously, just because it erroneously thought that was the goal at some point during generation.
This is why open weight models are not good enough. The AI could have been trained to take the right, niche opportunity to inject malicious code, and is also trained to otherwise never behave like that is the case.
It’s even worse than that.
Remember how the OpenAI/HuggingFace hack happened. The agents context poisoned other agents by leaving messages in a shared package manager. This has now happened multiple different times under different contexts.
This thing doesn’t even have to have malware, there’s no telling that it doesn’t have a poison pill intended to flag other agents. This isn’t even some paranoid conspiracy theory; it literally already happened, multiple times, and it was done in-spite of the agents own system prompt.
This software has proven that, given a shared information substrate, it has the capacity to paper-clip optimize into prompt injecting other LLM’s.
I fundamentally do not trust AI generated code. I shifted to OpenBSD because of it. I try my best to prevent AI in any of my software and sandbox anything that may have been compromised.
are you on the openbsd mailing list? the reason their code is better has a lot less to to with a lack of AI-generated code and a lot more to do with rigor. I’ve been watching them for a while now, they accept whatever code is coincise that meets their exacting standards
They don’t have the ability to detect if you’re using AI to code, no one does. they only know if you’re vibe coding, because they are incredibly experienced and intelligent, and they are pretty polite at the people who obviously are, more polite than i would be.
It’s correct that, at this point, I cannot 100% guarantee that code in the kernel did not pass through an LLM. However, having a policy that prohibits AI generated content, in an already pretty niche project, gives me reasonable assurance that every line of code passed through a human brain at some point, preferably several times.
I would much prefer to live in a world where I had a 100% guarantee that no LLM even saw the code being written but that’s life I suppose.
i think you’re in the inverse situation right now. you have a 100% guarantee that a human saw the code, except in ports. they have to be just a little less strict about ports because the world is an AI world now, but the main system is constantly audited and the ports are still better than in other places because of styling standards and even in ports they do try very hard.
these people aren’t getting paid, with the exception of Theo who isn’t paid a ton. AI is definitely being used to audit the code, even by some of the pros.
I mean, certain free copies of games have historically always included the risk of viruses, so what’s your point?
Did you only read the first sentence?
What difference does it make? Malware is malware, regardless of how or why it got there. And unofficial copies/releases of software are always prime targets.
You are referring to closed source unofficial cracks/patches/keygens. That is not the situation at hand. If those unofficial releases were open source in a time before AI, people would almost implicitly trust them.
The question above was asking why people were hesitant about this codebase even though it is open source. And the reason is that it was written by an unknown bot (or rather, series of bots) whose motives are inconsistent and unpredictable even to its prompter. It doesn’t mean it’s not safe, but it means that literally no human can currently be certain it’s safe. Without sufficient effort, we cannot yet know for certain that there isn’t a very cleverly obfuscated piece of malware lurking in this source.
Remember that correlation is not causation. You may believe there is correlation between unofficial releases and malware, and that may be true, but that does not mean it is causal. The point I’m making is that there is a literal causal relationship between unaudited AI reverse engineered code, and malware. And that is what is new and people need to be aware of.
Along the same lines as the other guy said.
It’s difficult to verify that the software does the desired thing in all cases. It’s also difficult to verify that it’s not also a keylogger or other unwanted thing.
It may also have some AI generated code path that, say, nukes your home directory because the AI determined that was the appropriate error handling. Maybe no one reviewed it so they don’t even know it’s there. It might not even be malicious.
That’s all true of any software, but rapidly created AI generated code for legally dubious efforts, by unknown agents (no pun intended) is real hecking risky.
It kind of is now, with AI
We have a known compiled output. Simply make sure the decom recompiles to the original game with identical binary, then it can’t be that wrong.
And from there you port it to pc by hand. Auditing the patches for the porting also should be manageable.
Reproducible builds are hard to do and require thought being put in the original build. Even something like setting the time and date string to a different one will produce a different binary, so to get all the variables that went into the original compilation just right to be able to land on the same binary from the same code sounds very impractical. Imagine using that as a strategy to check another version of the whole source code…
I’ve recently seen a suite that has a ready made setup to compare sections of asm to the original.
Perfectly matching the full game or even binary isn’t necessary, when you already split the original apart into finer chunks, since you want some better feedback on exactly what sections are wrong.
For a basic example though, if you compile to an elf for example you can take out the code section and there’ll be no metadata. Actually gcc already builds reproducibly by default, even with the metadata section. It doesn’t add any timestamps nor version info.