the extremes of bug compatibility

http://0xeb.net/?p=65

as we know, one man's bug is another man's feature. this is a pretty fun read about how far some blizzardfags went to emulate a buffer overflow and its read/write primitves which were often used in modding.

>0xeb
Stopped reading right there

>>2
who are you quoting?

bug compatibility is nothing new but this is something more - this is exploit compatibility!

non-0xeb link: http://hookxeb.net/?p=65

>>5
Thanks.

>>5
HOOK MY ANUS

https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/PDP-11-Options.html#PDP-11-Options

>>8
where's the bug compatibility here? that's just backwards compatibility

>>9
Thats extreme backward compatibility with an ancient system no longer on sale or in use(besides museums). While much more recent hardware platforms get "deprecated" by GCC maintainers on a whim.

deprecate those dubs!

>>1
EUDs are actually very interesting example of C and Freedom To Tinker.
If Starcraft was written in a safe language, these exploits will not work and the incredible flexibility of rewriting all map/game variables at runtime which resulted in tons of maps will be lost. Compared to the anemic and spartan staredit and its alternatives(e.g. ScmDraft), EUDs open venues of creative thought and space that extend to manipulating all loaded data inside SC memory. That example of SC converted to mario-like multiplayer platformer would be considered an "exploit" or "bug" by language purists.

>>12
I'm torn on this issue. on one hand, I admire the technical skills and creativity of exploiting a buffer overflow to create games within a game (see also: Super Mario World code execution glitch that's used in tool-assisted speedruns but someone also used to make a Pong clone with Mario sprites). on the other hand, I think that in the ideal world such a thing would not even be necessary because games would be open source (and writing a game by rewriting another one from sources is surely easier than writing a game as a shellcode).

yeah, I know that open source model doesn't seem economically feasible for most games. a man can dream though

>>13
Also consider C-based exploits enable homebrew, DRM bypasses, runtime patching (aka monkey patching, for closed source binaries)and execution(jump to buffer), numerous reverse engineering schemes(C is notoriously close to Asm, making RE much simpler),game hacks/mods not approved by publishers, etc.
In general C gives a Joe Hacker more power vs large organizations, making all software pliable and "modifiable".
While the threat of malware(generally limited to poorly designed OSes/softwares) exists it counterbalanced by Freedom to Tinker.
It also ensures no programmer can half-ass his C code, unless he want to invite vulnerabilities everything(includes non-C related logic of software) has to be tested and sanitized.That why C builds better programmers, they get trough the "bootcamp of C horrors" and recognize flaws in all code they see.

>>14
Also, note that C++(or C with Classes as i prefer to call it) code often either converts directly to C(devirtualization,specialization) or optimized by the compiler to a longer C-like sequence which is essentially C with a few sanity checks.

>>14,15
actually, when it comes to RE, C and especially C++ are more difficult to analyze than high-level languages. Java decompiles so nicely that most commercial projects use obfuscators. .NET-based languages decompile so well that it reads just like source code. same for Python, and add the fact that multi-line comments in that language are actually strings and the compiler doens't strip them for decompiled code that retains some of the comments. on the other hand, a complex C++ program will be so tedious to reverse engineer that even expensive commercial tools like IDA Pro won't make it readable (and recompileable/reassemblable) without a lot of manual work.

>>16
Decompiling and RE binaries are different things, C++ can't be easily decompiled unlike C(esp. if a program uses modern C++ idioms and deep OOP stacks(aka "Enterprise-scale code") but its code can be reverse engineered(Starcraft is actually all C++ code).
Decompiling bytecode is trivial and these languages(Java/Python/Ruby) are essentially scripts converted to bytecode.

>>17
clearly, if something is easily decompiled, it is also easier to reverse engineer because reading almost-complete source code is easier than reading inaccurately deassembled binaries.

as for C - the ease of RE depends heavily on how the code is written. the more complex runtime behavior is (esp. when dealing with hand-rolled OOP, function pointers etc.), the harder it is to grasp the asm

>>18
Reverse engineering implies there is actual work that needs to be done to reconstruct runtime behavior, pushing a button to decompile some Java bytecode isn't RE.

>>19
nice attempt at moving the goalpost, anus. in >>13 you said this:

Also consider C-based exploits enable homebrew, DRM bypasses, runtime patching (aka monkey patching, for closed source binaries)and execution(jump to buffer), numerous reverse engineering schemes(C is notoriously close to Asm, making RE much simpler),game hacks/mods not approved by publishers, etc.
In general C gives a Joe Hacker more power vs large organizations, making all software pliable and "modifiable".

which implies that C is easier to modify and reverse engineer simpler, which gives an individual power over organizations. then, when I tell you that this is even easier to do in most of the HLLs (which would imply even more power given to the individual) you start with the elitist bullshit how this is not TEH REAL RE.

either be an elitist and glorify bare metal reverse engineering and work required to do it or praise the ease of doing it. you can't have it both ways - it can't be good because it's easy and also good because it's not easy. if we talk strictly about empowering individual programmers to RE the program, HLLs are clear winners

>>20
Not all HLLs are easy to reverse engineer. Try "decompiling" a moderate sized Haskell program, then we'll talk.

decompile those dubs!

>>21
this is of course completely irrelevant when we talk about individual programmer vs large organizations because most large organizations don't use the dead dog to code user-facing shrinkwrapped proprietary programs that an individual programmer would want to decompile

>>23
Ackshually, Haskell is used by major companies and corporations. Avoiding success doesn't work long term.
https://www.reddit.com/r/haskell/comments/6p2x0p/list_of_companies_that_use_haskell/

>>23
The problem is conceptual, Haskell thunking and lazy evaluation create a major roadblock to determine the control flow of a program, especially when its optimized well. Consider the C output of Haskell compiler(ghc) vs normal C.
Obviously the haskell C output is far more complex for equivalent C program, and consequently far harder to reverse engineer.

>>24
ackshually, most if not all of those companies use haskal for internal software (if you're a programmer that uses it, you probably can access the source), not for user-facing closed-source programs you'd decompile?RE.

>>26
Source: your ass

>>27
SOURCE MY ANUS

>>10
You can put in pretty much anything into GCC as long as it doesn't conflict with any of the GCC team's philosophy and as long as you're willing to maintain it.

>>29
what if it's closed source?

>>30
Well then you gotta hax it first.

>>31
HAX MY ANUS

hax your're are own anus and check my dubs

Who needs a modding engine when you can just leave a buffer overflow in the code? Why are they even bothering with all these web browsers and all these other programs? What's the point of a video player when you can have a text editor with fixed-length buffers and use that to run your video decoder? Why do we even need executables anymore? Everything can be a text file. Just open the file you want and a buffer will overflow and run the code. Why do we even need drivers? We can hack the text editor to support whatever devices we want just by opening files. Why is it even a text editor? We can hack a simpler program so it can edit text. The only program on the computer can be an Open dialog box that loads a text file into a fixed-length buffer which is overflowed causing that code to be executed.

>>12

In general C gives a Joe Hacker more power vs large organizations, making all software pliable and "modifiable".

That's what high-level languages do. They enable one person to accomplish more with less time and effort, which creates more individual programmers who don't need all these monkeys working for them. C takes away your power. C makes it so nobody can compete with these organizations unless they had similar resources. The bad programmers like C because they get paid more hours to do what you can do in a couple minutes with a better language, and they keep getting paid again and again to fix the thousands of bugs that are revealed over the next couple decades.

It also ensures no programmer can half-ass his C code, unless he want to invite vulnerabilities everything(includes non-C related logic of software) has to be tested and sanitized.That why C builds better programmers, they get trough the "bootcamp of C horrors" and recognize flaws in all code they see.

Every piece of C code is half-assed. Better programmers would make it so you wouldn't have to jump through hoops to do these things. You shouldn't have to write to arbitrary fixed memory addresses.

These C programmers have no honor or respect for anyone. They complain when developers change undocumented internal data structures because it breaks their code that only works because it exploited a buffer overflow. Software is buggy because developers are not allowed to fix bugs.