Yeep. That is not entirely unsurprising (it’s such a common flaw in basic section/chunk formats that they obviously didn’t research about even the possibility of security flaws, or consider there to be any threat model at all — it was designed to be used internally in games for game assets, perhaps). Still a little disappointing to see they were indeed that lackadaisical. I don’t expect change, they’re very set in their ways.
There is a superior, free, open-source alternative called Inochi2D — https://inochi2d.com/ — developed primarily by Luna the Foxgirl, and used by all of nullptr::live, including Asahi Lina (of Asahi Linux fame). It really should see more love because it’s superior in almost every way.
One approach could be to compile the core or file loader to WebAssembly, load the file using the WebAssembly which will ensure there’s nothing nefarious in terms of reaching outside the desired buffer, and then marshal the whole object across.
> The whole file is effectively a write-what-where primitive2. In addition to that, the Count Info Table is not bounds checked either...
File formats like that, with many offsets in the file, are troublesome. There used to be more formats like that. Microsoft Word .doc is the classic example.
OpenJPEG 2000 has a similar problem. I just hit that yesterday.[1] Valgrind is finding references to un-initialized data which affect control flow, and running the JPEG decoder on valid but truncated files (which is allowed) is causing bad memory reference crashes and errors.
New formats like this are rare. People have learned. A modern exception is Unreal Engine 5's Nanite has much offset data, and there may be an attack surface there for hostile game content. Nanite is a way to store a graphics mesh with both multiple levels of detail and common submeshes. It's a hierarchy of directed acyclic graphs, flattened into a linear file with offsets. And, sure enough, there are many crash reports. At least Unreal provides a validator for the format.
(If only C/C++ had slices in the language. Most of the things for which pointer arithmetic is used can be done with slices. Slices really are pointer arithmetic, with sanity.)
Live 2D pricing for SDK was/is also ridiculous, as published on their site.
I did the math a while back and they do by region, platform, etc - multiplied together (adds up quickly) and tiered by revenue.
So if you want all regions and platforms, for a company making about $100k a year revenue (whatever the tier was in Yen), they want about 50% of your revenue.
I brought it up with sales rep and he admitted it didn't sound right and conceded that's what it came out to, and that I can negotiate. Very strange stuff
Putting aside the technical aspects, those anti-competitive provisions sound very unconscionable and against public policy to me. There's no way they would try to enforce that in a courtroom without being laughed out of it (or worse, getting their copyrights revoked under the "copyright misuse" doctrine)
In the US maybe but it is worth noting that they are a Japanese company and Japanese copyright law is different from US copyright law (ex: no free use).
Yes. If you are a US citizen and you reside in the US when the perceived infringement occurs, then you will go to court in the US with US law (thanks to the Berne Convention).
However this software (Live2D) is originally targeted at the Japanese audience and only after vtubing became popular overseas did it get proper English support. So a significant bulk of the users of this software are individuals who reside in Japan. And on top of that, quite a large population of vtubers live outside the US in regions with their own copyright law. So to the degree this is enforceable will be decided entirely by where you live.
For US non-expat citizens & residents, this isn't a problem but for the rest of the world there is a lot wider variation in how enforceable these license terms are.
I have to admit I'm somewhat impressed with the quality of the 2d puppetry I've seen in gaming recently (e.g. Marvel Snap, andy of the Gachas). It's a simpler technical skill than full 3d rigging that 2d illustrators seem to be able to be able to pick up fairly quickly.
The field this tool grew out of (mobile gaming) is such a grey ethical area, and these puppet animations are a fascinating form of pulp media.
I don’t think it is about cost - games were always 3D until gacha came out, and early VTubers were 3D too until VTuber culture established and Live2D have become dominant, almost in parallel.
2D must be easier to comprehend more so to viewers than it is for creators.
This could be very bad for vtubers, people who often have to conceal their identity to avoid harassment. With the models they usually use 3rd party assets in the scene, and if those assets can be used to exploit live2d then that would be very bad. Along with their accounts being possible to steal without any ability to retrieve them.
I should mention that this vulnerability is even worse for 32-bit programs. Since the entire address space for those is confined to 2-3GB, a malicious MOC3 file can access all of the program's data.
From the first glance it seems like Spine provides their libraries in source format (under non open source license) with pure C++, C# and TS implementations that don't depend on binary blobs (at least it seemed like it). You can find it here https://github.com/esotericsoftware/spine-runtimes . Even if C++ version is not safe, C# and TS versions are probably fine and, and the license mentions creating derivative works (assuming you follow the Editor license terms and some of invovled parties have an editor license) so you are probably allowed to create modified library which processes the files safely.
Fun, and, doesn't surprise me based on what I hear of Live2D. Proprietary mess that is a nightmare to work with, with arcane documentation. I'll need to inform some friends to stop using all the free assets being posted around.
I find Inochi2D interesting, but, why do we keep making the same mistakes?
The codebase is written in D(!!!), using a NEW proprietary format(!!), only available on some platforms(!).
I am not up to date w/ current game development trends, but puppeteering/animating 2D assets exists in plenty of games (you see it a lot in Japanese/Korean/Chinese games, Nikke/Girl's Frontline/Arknights.) I wonder if using a format accepted by the industry, in a portable language like JavaScript, build web-first would've been a better choice.
Of course this is the lowest form of critique because I ain't gonna make it.
That's presumably because of exactly the problem mentioned in the article. Customers of the other software are forbidden from using those files with other software, which could potentially include the use of a tool to convert that to a better format, so the competing software just made up a different format.
I am ill informed about the actual industry landscape, but, Spine is listed elsewhere in this topic.
I wonder if it would've been better to ask for that format to be open source for the community. Then 2d puppeteering artists could use they tool they prefer with a shared file format.
When you need to get units on shelves as quickly as possible, you take whatever's already available and bend it to the particular project's needs. This has been game development since forever.
Maybe we could have operating systems that do not allow every program to read arbitrary user files, instead of making every program and all of its dependencies memory-safe.
There is a superior, free, open-source alternative called Inochi2D — https://inochi2d.com/ — developed primarily by Luna the Foxgirl, and used by all of nullptr::live, including Asahi Lina (of Asahi Linux fame). It really should see more love because it’s superior in almost every way.