For what looks at first glance to be a potentially impactful development, this post and the "encode.su" one linked from it are extremely sparse on details.
Where is the source code? A detailed description of what the codec actually does? References to relevant publications?
All I see are two mystery Windows binaries, hosted on a forum I've never heard about. The fact that "encode.su" uses the world's most notorious domain extension doesn't inspire confidence, to put it mildly.
> The fact that "encode.su" uses the world's most notorious domain extension doesn't inspire confidence, to put it mildly.
Encode.su (formerly encode.ru) is indeed the most known forum dedicated for data compression in general. So much that many if not most notable data compression projects posted to HN are often first advertised to that forum first (for example, Zstandard [1]).
Hydrogenaudio is well known in this area and many new prototype codecs are announced there first. Also, the lack of source control and Windows-only binaries are very much congruent to the style of development there. See it as your confrontation with a new world, because small it is not!
And later, you will learn to understand the depth of the contribution that the ffmpeg project provides :)
My goal is to try to do something practical just on data compression. I have neither knowledge nor experience about malicious software mentioned. You may be comfortable about this.
https://www.linkedin.com/in/hakan-abbas-178b5852/
I was referring to the practice of downloading executables from such forums in general, not to your post specifically. I have no reason to suspect that this particular post contains any malware. But in most parts of the software world, Open Source has been the standard for experimental publications for a long, long time, and seeing a forum depart so strongly from that standard is certainly surprising, and does of course have security implications when this practice is used at scale.
You can always use a sandbox if that's the most concern. A bigger issue is that, as like other established forums, enough many people don't know much about data compression and contribute to the noise.
Yeah, I too was using the web in the late 90s. I remember countless programming and "hacking" forums where .exes were shared, and I downloaded and ran anything and everything that had a download link.
It was a fun time, and I do harbor some nostalgia for it. But I can't imagine going back.
Corporate? That's not a sound way to describe the totality of the world of programmers that lean towards free/open and beyond.
Sure, closed-source communities exist and have for a long age, but many folk have grown beyond the ethos or tradition of closed releases for reasons like, IDK, competitive individualism for clout or potential code quality shame that AFAICT drive such corners of the software world, especially at the level of freeware, not just for business. It's certainly a new world for younger people who skipped the era when that was more prevalent.
If people don't like corporate, there are newer source available licence options that folk to the left of free/open have been advocating more recently.
Tell us more about "I don't aee anything suspicious". How exactly do you know it's not a binary that hashes all your files using a key and asks for btc to revert?
Open in hex/text editor, scroll through and look for anything suspicious like network, crypto, obfuscated sections (major red flag), strange strings, etc. The #1 most reliable sign of malware is if it's unusually large and packed/obfuscated, but this isn't.
The guy even has his full name and contact info in there.
This is harmless.
If you don't trust me you could upload to an online malware multiscanner (which tends to invite false positives, but better than nothing).
It's not about whether this particular announcement, with these particular executables, is trustworthy or not.
It's about the whole process of regularly downloading and running executables uploaded by individuals to a BBS-type forum being unimaginable in most other parts of the software world, and violating every security "best practice" written about in the past 30 years.
I know that this is how things were once done everywhere. But that was a long time ago.
The vast majority of the world still downloads and runs executables uploaded by individuals, albeit perhaps not on a bulletin board or forum (most of those have been killed and replaced by social media).
Yes, I'm new in hydrogenaud.io. However, I have been active since 2018 in "encode.su".
This year, "3rd Global Data Compression(gdcc.tech)" organized by Huawei and Barcelona Autonoma University was held. In this competition, I have the world 3rd place in the "Professional Task 6 - Ultra Fast" category(JABBAR). And I spent only 2 weeks of the 5-month competition process for this degree.
We can only share and test such a specific work in specific environments.
You are simply toeing the line of corporate propaganda, that says people must always submit to centralised authority instead of exercising their own judgement.
That is what is leading us to dystopia.
We are not "pretending", we are simply stating that the magnitude of risk is absolutely tiny.
Insecurity is freedom. Don't let them take away the latter in the name of security.
A lot of malware just waits for a while and the opens another file (or a pastebin) and downloads the payload from somewhere else. A small executable without anything dodgy in it means nothing.
FWIW: I support your position and wish that there was more trust on the internet. I’m happy that some of these old-school forums still have that level of trust.
But, from a technical perspective, I think it’s naive to assume that you can easily spot obfuscation that’s trying to stay hidden. If I understood your analysis model (open in a hex viewer and scroll around), then it is quite trivial to just add a few normal-looking functions that happen do things like manually load socket DLLs and make network requests without the API names being visible.
I could even, say, hide the code or data in a table of opaque filter constants or lookup tables, and it wouldn’t have to be much: you can implement a very dumb PE parser and function loader in a couple dozen lines of C, and an IP address target is just 4 bytes which can be smuggled into anything. Open up a socket, read everything from it into an RWX buffer, jump to it and voila, a programmable backdoor. Make the trigger something random so dynamic analysis doesn’t find it immediately.
The Underhanded C Code Contest demonstrates that even with source you can hide malicious behaviour; how are you going to detect malicious behaviour in a binary that’s trying to evade manual detection?
It is still possible that the author's machine had a virus and the executable got infected without the author's knowledge. I too trust the author in that matter, but that's irrelevant here.
There are libraries that would be useful for cryptography that you wouldn’t likely need in an audio codec. If the binary imports those libraries, it may be visible with a bit of prodding.
And precense of those things is basically the first thing any malware heuristic looks at. Why are you so emphatically stating them as if they are news?
i think they were just examples of how simply looking at imports isn't good enough, and it's true. on the plus side, by hitting HN there are more eyes on it and hopefully more consensus on how safe/interesting this is
Also, what does the High Availability in the name of the codec refer to?
I've searched the web and found not a single mention of "high availability" in the context of audio codecs. In fact, the top-ranked result was this very post, which doesn't explain what the term is intended to mean.
HALAC and HALIC really consume very little memory. The process speed is high at the same rate. And they offer a reasonable compression rate. Therefore, they can be used at high level and different areas.
All three references are 10 years old (or only have a secondary reference that is 10 years old). More recent analyses give much more diverse set of TLDs---.ga, .tk, .us, .ru, .ml, .pw and so on [1]. In fact, at this point we should be much more concerned about .us than .su.
Where is the source code? A detailed description of what the codec actually does? References to relevant publications?
All I see are two mystery Windows binaries, hosted on a forum I've never heard about. The fact that "encode.su" uses the world's most notorious domain extension doesn't inspire confidence, to put it mildly.