AshamedCaptain

In the 2000s SC4 was already using 3DS Max, but here we are talking about a game that started development in 97. And they already had 3D games before it...

In SC3k sprites you can also clearly see two different grid sizes, so at the very least the retouching and some props are "pixel art".

You're describing SimCity 4, not SimCity 3000. The SC3k tool is not entirely 2D, but it does mostly behave like one (with emulated voxels instead of pixels).

And while I cannot confirm what Maxis was doing internally, I am quite sure no-one was using 3DS Max for rendering game assets in the 90s considering it had just been released and well into the 2000s it was still humongously slow.

Ironically, drm-612-kmod has been pushed to ports a couple days ago (not quarterly yet) so you can now start using FreeBSD with really recent GPUs now from ... let's see ... 2024.

This still makes it like the 3rd operating system overall when it comes to hardware support.

I am annoyed that they just claim that "reverse engineering" will take care of this, instead of really trying to fight back legally.

This is a social problem, and reverse engineering can only help up to a point.

> These are exactly the kinds of sentences that would have gotten us outstanding grades as students of the language.

Not at all? They are not even full sentences...

I get that you might like the style, but there is no need for hyperbole.

And? I really do not think anyone is complaining here about the water disappearing into thin air or its atomic components or whether it goes in a pipe or into the moon. The definition of using water is quite clear (you can no longer drink it) and unless I am misreading you are totally distorting it.

No, the report is already not counting whatever can be reused. It's the point of it.

Where is the source for that? I am only familiar with one site, the STMicro one in the Alps, which already used 4000 acre-feet / 5 million m³ per year in 2023 [1], and it's been at least doubled since then. This is a huge chunk of the total water consumption of the region, and there are NIMBY demonstrations frequently because of that [2]. It's also surprisingly polluting. Whether you think the value is worth or not is a different story (I worked there, so guess).

[1] https://www.st.com/content/dam/aboutus/sustainability/report...

[2] https://stopmicro38.noblogs.org/post/2026/03/17/rando-pas-de...

50000 for the entire industry is bullshit, even if you limit it to the US.

Plus semiconductor manufacturing et al which are also heavy users of water.

I get the point, but note that (custom) datatypes and function prototypes are for readability. They are not required for working nor functionally-equivalent code.

It is weird to limit to "the same attack". Why does it even have to be the same attack? From the moment sshd loads your modified lib, you're literally running code with root privileges on the victim machine. You can literally run _any_ attack you wanted, with zero persistence. This is worse than a OpenSSH RCE.

Even in your own talk you basically admit this, so what are you doing here? If you think there's something here that everyone is missing but you don't, why not actually explain what it is?

> Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory.

I do not understand how you even expected sshd to sandbox itself. Its entire purposes is to (a) daemonize , (b) allow incoming connections in and then (c) forward (possibly-root) shell statements. All 3 things are 100% required for sshd and would have already allowed an attack like this. Any talk about sandboxing here (or dropping privileges) is wishful thinking.

But the fact that it was done indirectly from systemd has nothing to do with IFUNC.

I do not understand what is it so hard to "generate working code". Even the free version of Hexrays was doing it 15 years ago, and I have written one in my company that I have used for over 30 years. It's actually ... trivial?

The problem is readability. No one in his right mind would call what they generate "C++". Mine still interjects assembler from time to time (and not the new version that GCC supports, but the older MSVC style) .

LLMs absolutely do not help with the generate working code part, because this is an exact problem that doesn't need nor benefit from an LLM (other than maybe automating stupid iteration?). They can help with the readability part, because here once you already have a working skeleton it doesn't matter that much if they make mistakes, as it is easy to detect.

The entire argumentation here is ridiculous. There's a big jump from "IFUNC slightly undermines RELRO" to "IFUNC is the real culprit". You could have gotten all but the same effect spawning a thread from a plain init or C++ constructor. No one should think that any relro, r^x or aslr or anything like this is going to deter anyone who can literally control the contents of the libraries which are linked in. They could, literally, exec a copy of sshd with a patched config if necessary.

The title is just clickbait.

The entire argumentation here is ridiculous. There's a big jump from "IFUNC undermines RELRO" to "IFUNC is the issue". You could have gotten all but the same effect spawning a thread from a plain init or C++ constructor. No one should think that any relro, r^x or aslr or anything like this is going to deter anyone who can literally control the contents of the libraries which are linked in. They could, literally, spawn a copy of sshd with a patched config if necessary.

My point is that we have been past the "working compilation" way before LLMs, and I do not think anything in LLMs help with it, at best agents use these tools with the same efficiency. I disagree that they're good at writing compilable code, but agree on the readable part.

> Only in a very rudimentary sense and definitely not in a working compilation (much less binary equivalent) sense.

Working is the easy part; the hard part is getting something that classifies as readable C. LLMs do not really help reach the "working compilation" part but benefit from it.

Decompilation to C (and even C++!) has been done automatically for 2-3 decades at least. I am not sure what has changed in recent years other than people playing fast and loose with copyright (and GitHub allowing it, likely because their LLMs also stand to benefit). Introducing LLMs here is only going to introduce errors, delays and likely push you away from a reliable result.

The challenge here is readability. Reading the TP source leak you link I think it's even behind the current state of the art, as it's barely above assembly. This is where I suspect even the smallest of LLMs may help, since you don't care that much if it introduces errors.

Pidgin predates keychains, but if I remember correctly you had the option to set up a master password or to simply disable storing passwords, which were the only options that were truly incrementing security. But most users would not do that (they want autologin for a reason), so the example still applies.

(Note also most keychain implementations are not truly improving security in any way, but this is a separate topic)

The problem with this argument is that you can justify an infinite amount of crap with it, the security equivalent of cockroach papers; which inevitably people ends up treating as real security.

One example I remember is Pidgin storing its passwords in plain text in $HOME. They could have encrypted them with some hardcoded string, and made a lot of people happy that they would no longer grep their $HOME and find their passwords right there. However this had the side effect that now people were dropping the ball and sharing their config files with others. Or forgetting to setup proper permissions for their $HOME, etc.

In addition, these layers of obscurity are also not overhead free: they may complicate debugging, hey may introduce dangerous dependencies, they may tie you to a vendor, they may reduce computing freedom (e.g. Secure Boot), etc.

But NAT is _not_ a firewall. It's entire purpose is to allow traffic through. There's a million dozen tricks attackers can play, e.g. tricking a PC into sending traffic to some address will usually allow all traffic from that address back into one's precious network.

This is a common misconception and very dangerous -- I see a lot of people, ISPs even, who seem to think NAT is enough and you only need the firewall for IPv6.

So, wishful thinking it is.

There is a bazillion of jurisprudence about decompilation in the EU . Just search for your favorite case. I'm based in the EU (France). But FYI, despite what you may think, in practice the US is more lax about this than the EU is.

In the EU, for example, decompilation even if you don't distribute may very well be illegal (because it would be an unauthorized temporary copy of the program); the US courts are way more lax when it comes to these temporary never-distributed copies (which are almost always fair use, a concept that doesn't exist per-se in the EU). This is a big problem in the EU for security research (which obviously does not fall into interoperability).

Emulation would be acceptable, which is yet another reason the interoperability clause does not apply (since you _already_ have a way to interoperate that doesn't require distributing copyrighted software, and the EU interoperability clause very explicitly says that then it does _not_ apply).

Decompilation produces a derivative work. This is not up for debate, or disagreement.

The exception for interoperability only applies to _the minimum required_ for interoperability. You can use this exception to distribute e.g. game authorization code even if copyright would not allow you to do it.

You _cannot_ use this as an excuse to pirate the entire program, much less to create your own derivative work and distribute it!

This is just wishful thinking that comes up every so often in these threads (now it is the 5th time I see this parroted here). And then, when Nintendo inevitably shuts everything down, cue the crying. This ignorance is simply setting these projects for failure.

https://news.ycombinator.com/item?id=45643106

There is little to no creative work whatsoever if you end up with exactly the same game; and often they end up with exactly the same binary as well. Source translations are derivative works almost by definition. It doesn't matter what magic you use to generate it.

And again, where is the interoperability here? Interoperability exception would apply if there was whitebox cryptography, Nintendo logo-style things or anything else where the only method for the work to run would be to violate copyright of _exactly that_. Under no circumstances you can simply copy & distribute the entire work (or derivates) while claiming "interoperability exception!". It makes utterly no sense.

This is an absolutely ridiculous interpretation. There is no interoperability here at all, you are literally just copying the work in question.

It is like claiming that compiling Samba to run in $NEW_PLATFORM suddenly strips Samba of the GPLv3.

No, because there always are "better encryption systems", whether for good reasons or not that's another story.

And in the process immediately convert huge numbers of devices into ewaste. Then check the excuse calendar again for tomorrow's reason to deprecate yet another batch of "legacy" ciphers from openSSL.

You do not need the pointer at all. f() not specifying the arguments has been the case since forever. "Prototypes" (90s) are newer than C.

no, even though I'm not sure they cannot.