Virus in SMC file?

[mariotheplumber]

Can SMC files have viruses or trojans?

In other words... can your computer ever be infected by a virus or trojan by using ZSNES to load a file with a .smc extension?

Are there any ZSNES exploits or .smc exploits that allow for malicious code to execute?

Or... are SMC files like TXT and MP3 files, incapable of infecting your computer (for example, when TXT files are loaded by Notepad and MP3 files are loaded by iTunes, and only when they have the proper file extensions like .txt or .mp3)

By the way, I'm running ZSNES on Ubuntu.

[odditude]

any application that accepts input and doesn't perform boundary/sanity checks can theoretically be exploited.

this includes text editors and media players (and many media player apps have had such vulnerabilities exposed and patched, time and time again).

the impact of said exploit would depend on the application's own permissions and whether any external flaws or vulnerabilities can be triggered as well.

that being said, there are no known exploits in zsnes.

[grinvader]

Can ROM files have viruses

<_<

>_>

[odditude]

you win this thread.

[mariotheplumber]

Oops. My original post said ".rom extension".

I've edited that to say ".smc extension".

And I agree with your comment on application vulnerabilities (cough cough, Windows Media Player for example).

Anyway, It's good to know there are no known exploits for ZSNES.

But... just to be sure... I ask again:

So assuming you've downloaded ZSNES from official sources (the zsnes.com website or the Ubuntu repository, for example), there is no way in hell that using ZSNES to load a .smc file can cause malicious code to execute, right?

I mean, even if a .smc file was laced with a virus (that would destroy your computer if opened with an application the virus is targeted at), by opening the .smc file with the ZSNES application, ZSNES will fail to even recognize the malicious code, right? (That is, unless someone finds a zero day exploit. But I doubt it will happen.)

[paulguy]

There is a chance, but it'd be pretty far out there. There's more efficient ways to infect a computer than SNES ROMs.

[grinvader]

There is a chance, but it'd be pretty far out there.

Nah, not even.

If the file is too big, it doesn't get loaded and nothing happens.
If the file is loaded, but lacks the heuristics to make it snes-rom-ish, nothing happens.
If the file has the various bits needed to actually boot, by executing the code zsnes can output audio, video and use a finite amount of diskspace.

If there ever was a way to hijack a system by sending specific A/V frames or saving limited series of bytes on disk, everything and their mom would be vulnerable.

[Gil_Hamilton]

There is a chance, but it'd be pretty far out there.

Nah, not even.

If the file is too big, it doesn't get loaded and nothing happens.
If the file is loaded, but lacks the heuristics to make it snes-rom-ish, nothing happens.
If the file has the various bits needed to actually boot, by executing the code zsnes can output audio, video and use a finite amount of diskspace.

If there ever was a way to hijack a system by sending specific A/V frames or saving limited series of bytes on disk, everything and their mom would be vulnerable.

Well, it's not like certain ROM images can't crash ZSNES. Actually crashing the emulator, as opposed to locking up the virtual SNES it creates.
That is, in and of itself, a ROM image effecting a result on software outside it's virtual environment.

[nintendo_nerd]

Can ROM files have viruses

<_<

>_>

I see what you did there...well played.

[Gil_Hamilton]

Can ROM files have viruses

<_<

>_>

I see what you did there...well played.

Not really. He should've rotated the double-blue and dropped it on the lower blue virus. Put the double-yellow upright on the yellow virus, and then he's set for a yellow-blue combo.

He's making the amateur move.

[mariotheplumber]

There is a chance, but it'd be pretty far out there.

Nah, not even.

If the file is too big, it doesn't get loaded and nothing happens.
If the file is loaded, but lacks the heuristics to make it snes-rom-ish, nothing happens.
If the file has the various bits needed to actually boot, by executing the code zsnes can output audio, video and use a finite amount of diskspace.

If there ever was a way to hijack a system by sending specific A/V frames or saving limited series of bytes on disk, everything and their mom would be vulnerable.

Can the same be said for BSNES? Can BSNES ever cause malicious code to execute by loading a virus-laced .smc file?

(I just uninstalled ZSNES. It keeps crashing and freezing on my Ubuntu OS. I tried older versions of ZSNES for Ubuntu, but I still get crashes and freezes.)

[odditude]

Can the same be said for BSNES? Can BSNES ever cause malicious code to execute by loading a virus-laced .smc file?

you're better off asking on byuu's board.

[mariotheplumber]

Nevermind BSNES. Can the same be said for Snes9x? Can Snes9x ever cause malicious code to execute by loading a virus-laced .smc file?

(I just uninstalled BSNES too, ugh. It seems BSNES can't load the .smc files I have, only .sfc files. And the Linux version doesn't have "snespurify" to convert .smc to .sfc)

Gonna go ahead and install Snes9x now.

[grinvader]

Yes, the same can be said of snes9x, or pretty much any emulator that's an emulator and not a viral app in disguise.

[adventure_of_link]

The only way you're gonna be sure of getting a quality program is:

1. stay the HELL AWAY from the repositories on site

Seriously, all their "optimizations" do is end up breaking things down the road. You're far better off getting the latest code from http://www.zsnes.com and compile that.

[kode54]

The only way you're gonna be sure of getting a quality program is:

1. stay the HELL AWAY from the repositories on site

Seriously, all their "optimizations" do is end up breaking things down the road. You're far better off getting the latest code from http://www.zsnes.com and compile that.

What does this even mean? Hasn't it been almost a decade since anyone has been serving up "optimized" builds of ZSNES? Hell, I know those were totally useless, especially with the source code being mostly assembly without any specializations for modern processors, so it was a stupid thing to do.

[paulguy]

I recall the official release optimizations (compiler/assembler flags) being pretty obnoxious to begin with...

[kode54]

Yeah, using -O99 or something crazy like that for nasm, when it would be perfectly adequate to use -O3 or so, or use yasm which can automatically optimize the size of branch opcodes as necessary with a minimum of passes.

[grinvader]

Yeah, using -O99 or something crazy like that for nasm, when it would be perfectly adequate to use -O3 or so, or use yasm which can automatically optimize the size of branch opcodes as necessary with a minimum of passes.

-O3 used to produce a build that sigsegv'd. -O99 was hardly entirely optimised (and also crashed, iirc. it stopped crashing at 0 and above 9999).
The exact number of passes was between 9999999 and 99999999, and there was absolutely no gain in narrowing it down since it's an early-out process. So we let it churn every damn jump in source (nasm now comes with a -Ox option that does pretty much the same thing - keep optimising until no jumps are left).

Then jonas went inside and did everything manually. The horribly long newg162.asm build times were due to unrolled macros that end up duping millions of unoptimised jumps everyfuckingwhere. As this no longer happens, the build time of a release grade binary was substantially cut down to mere minutes on any machine made after 2000.

I recall the official release optimizations (compiler/assembler flags) being pretty obnoxious to begin with...

The compiler flags are just run-of-the-mill stuff, really. Architecture profiling (Nach pretty much made -march=native before gcc, lulz), frame pointer omission for all the ebp backup-less voodoo, loop array prefetching, stripping, -O3, babby's first optimise flags.

[adventure_of_link]

What does this even mean? Hasn't it been almost a decade since anyone has been serving up "optimized" builds of ZSNES? Hell, I know those were totally useless, especially with the source code being mostly assembly without any specializations for modern processors, so it was a stupid thing to do.

didn't some of the Linux distros try to insert their own patches, bug fixes, etc into most of their canned software?