Does no$sns 1.6 really have malware?

More than one person has requested that I develop something substantial for the Super NES. So today I got an itch to do so, which meant I needed to set up an emulator in which to test things. While waiting to see if amd64 and GCC improvements had improved the speed of bsnes-plus on an Atom CPU from the 25 fps that I had seen before, I looked for other emulators I could try. So I visited no$sns and followed the link "Download no$sns v1.6 (21 Mar 2016)". The previous version had worked OK in Wine. But instead of downloading the file, Firefox 53.0b10 said "The file contains a virus or malware."

Can anybody else reproduce this error message? Is it a false positive or actual malware? If the latter, is there another recommended option for using a debugging Super NES emulator other than buying a bigger PC so that I can use bsnes-plus?

Yeah, Chrome did the same thing to me when I tried to download the file a few days ago, so I ended up using an older version of the emulator. I too would like to know what the deal is with this file.

I ran across this a few months ago, had to settle for an older version of the software.

Maybe there is malware in the file. If there is, thanks to the magic of closed-source software, that was able to happen. If not, thanks to closed-source software, everyone lacked any reassurance or other ways of getting the program.

(Don't be surprised if I make a post soon ranting about how closed-sourcedness is of the devil. It's why I gave up on the SNES and frankly, if you are a software developer who won't share things because you want your name plastered on them or you think it's okay to just release a program on Windows and make everyone else use Wine, I don't like you.)

Edit, just want to clarify that I'm not talking about Martin Korth, since he did this stuff for money and documented it. More about all those programs on Zophar's Domain with amazing features but guess what, they only run on DOS.

My main stumbling block, is, I can't wrap my brain around how I'm going to make backgrounds. I mean a map editor that can output anything useful. SNES backgrounds work so differently than NES (multiple layers, per tile attributes, 2 bytes per tile, etc). I suppose I could try to program my own map editor, but that would set me back maybe 6 months.

I could maybe create a very big tile image, showing every tile in every palette, and use 'Tiled' to arrange them, and then write a script to transform it into useful BG data.

Oh, and I forgot music. That's another over-my-head concept currently.

I'm in, if you want to go through with that.

It's worth pointing out that all of Martin Korth's programs are written natively in x86 asm, so it's not clear that the source code would make you particularly better off.

It's also tremendously likely that that's why it was flagged as malware—because some heuristic detector decided that it doesn't look like a compiled program.

That's one thing I was planning to do: write a music engine. But it's hard to test a music engine when bsnes-plus at 30fps makes the audio stutter.


So could one of you help notify the author of this problem? His contact page states that several major email providers blackhole the mail he sends.

You could also just PM him right here on the forums.

I ran no$sns.exe through malwr and it didn't indicate anything suspicious.

The program is packed with UPX though, which many antivirus programs have a history of being overly sensitive about.

PM sent, but I'm not sure how often he reads them.

Chrome blocked it for me, and when I unblocked it Microsoft Security Essentials promptly deleted it too.
This is MSE's encyclopedia entry on the detected threat: https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?name=Trojan%3aWin32%2fDynamer!ac

No idea whether it's a false positive.

Could you use something like SPCamp to test the SPC engine? That way you are only emulating the SPC chip. Sure it won't be the most accurate of systems, but by all accounts it would be accurate enough for most of the dev work to make sure the right sample is played when etc

Failing that Geiger's ?

I don't think a tile map editor is really going to cut it for the SNES. The C64, NES sure we tend to be very code driven and there is the one way and one mode for everything. For the SNES however we don't really need a map editor but more a Game editor, something that lets up map our blocks, be it a 2x2 grid, or a 4x4 or a group of banana's in a long trail. Then you probably want to be able to turn screens into blocks so we can repeat large parts of the map but with different control characters or pallets. Of which the how, what, when and why is going to depend on the exact type and style of game we are making.

I feel a better approach would be a "standard" library, a "SNES.cs" file( well collection ) that has code to draw SNES tile data to a Panel object at a given X,Y with pallete Z. A standard Pallet RGB entry system that handles the Scaling and renders a picker for the colours. A RAW 16 colour and 256 bitmap conversion function down to SNES bpp formats, that converts either the whole things or a sub window. So we can make our tools take png, or jpeg or tga or ilbm and convert as we please. A function that takes a 2D array and spits out the data into the standard SNES DMA offset formats. A colour window/enable window rendering system,that understand a HDMA chain or will convert a 1bit bitmap to a HDMA chain. Trying to make the perfect tool will never work, but making it faster to throw together an editor would help all of us.

"Trojan:Win32/Dynamer!ac is a generic detection used by Windows Defender for a file that appears to have trojan-like features or behavior."

As someone who is developing the same game since 12 years, I can guarantee you, having your project set back to 6 months is nothing to be worried about.


Same here. Actually I did write one and it works on real hardware but I lost the source I only have the binary, and it's not terribly useful. I guess it could still be used technically, but you wouldn't be able to make any changes to it without some kind of hacking.

Does it have debugging? Once I determine that the program is behaving incorrectly, how do I go about determining which instruction in my SPC700 program is responsible for the difference from intended behavior? If there is no debugger, there is no advantage of using SPCAMP over something like Game_Music_Emu by blargg.

And the page for SPCAMP on Zophar's Domain states that it's a Winamp plug-in. Will I now have to install the whole of Winamp in Wine? Or is there a lightweight host application for Winamp plugins?


Is it good for the Super NES scene to continue relying on that abandoned piece of software?

My point was more do you need a full emulator or can you use just a SPC emulator? as just emulating the SPC would help with performance on an Atom. But if you want need the SNES CPU to interact for you needs then not enough. For you more debugging based needs and Linux? based usage this would probably suit better http://vspcplay.raphnet.net/ than same SPCamp(which I feel is the most famous of SPC players ) and being open source you could tack a debugger and code stepper in as well with probably little effort.

Its not, but always an option. Or if you don't want WINE, ZSNES and DOS BOX? *ducks*

I can use an SPC emulator if it supports debugging.


Thank you for the suggestion. I built it and tried it, and it core dumped:

I plan to open another topic about my failure to get it to work.


Other than having to learn native programming and SPC700 programming at once.


I started this topic because I'm willing to use Wine. But in any case, zsnes -d appears to be "now available in all ports". Thank you for the suggestion. Is ZSNES maintained? Because I just installed it (sudo apt install zsnes), tried my test ROM, and the envelopes appeared to be way off. Is it "for the S-SMP, use the debugger in ZSNES, but for the DSP, use an SPC player and play it by ear"?

I just tried zsnes -d /path/to/my/rom.sfc, and F1 didn't do what it said it'd do. I plan to open another topic about my failure to get it to work.

ZSNES is the most ancient of emulators, it is written in i386, its job was to run a SNES on a 486DX66. I use to run it on my P133 and it still had some issues, My VESA driver ( stupid S3 piece of crap) couldn't do 16bit so no transparency effects for me. I had to play Chrono Trigger with the 3rd layer disabled so I could see in some levels. I'm from Oz so no real cart for me.. It has not been updated in 10 years ( I was going to say 20, but the sneaked one out in 2007 ). It prays heavily at the alter of speed, not accuracy, a lot of the old SNES patches and home brew don't work on the newer emulators or even hardware as they are ZSNES compatible only. However I would think for your needs it should be sufficient, you might need to do a debug session on something newer at the end, but for the most part ZSNES should get you through the ZSKnight

After bothering to actually un-UPX the latest no$sns release, I ran it through VirusTotal to test this theory.

Detection ratio before unpacking: 31/61
Detection ratio after unpacking: 5/61

One of the 5 AVs that still gives a negative result after unpacking is AVG, which I've been able to trigger false positives from on multiple occasions by writing basic command-line tools that do nothing more than convert/extract files.

Two of the other negative results are some no-name AV programs that describe it as "malicious_confidence_65%" and "malicious (moderate confidence)", which is not particularly convincing.

UPX is a nightmare, and never worth it. I fought false positives for a few years but eventually threw in the towel and just rely on the 7zip archive for compression during distribution. It's not UPX' fault, but it's a battle you cannot win, much like screensaver suppression and joypad input.

AV software is worse than having most real viruses.

Also, even without UPX, I'm pretty sure Martin employs other tricks to try to protect his binaries from modifications, like a CRC check on the uncompressed binary. Could be mistaken, but I know there was one closed source emudev that loved doing that.



I like you :)

The thing that pushed me toward the GPL instead of the ISC license was actually FuSoYa's Snes9X SuperFX tracer. He botched a detail (turned out to be ROMB reads) in a way that broke Doom exactly like I had in my early SuperFX support. Had he released the source, it would've been a five minute fix to see what he changed from the mainline Snes9X and to fix that bug in my core.

But because he was too selfish to share a few fprintf commands after taking the entirety of Snes9X's source for himself (his site had a screed about -not- asking him for source, too, or I'd have tried that), I had to spend a few days trying to figure out the bug with no help at all.