Toggle sidebar

Hacking [RELEASE] UWUVCI + Injectiine

  • Thread starter Thread starter NicoAICP
  • Start date Start date
  • Views Views 646,130
  • Replies Replies 1,098
  • Likes Likes 67
ZestyTS said:
UWUVCI V3 is back to free, it is now on version 3.N1.
Click to expand...
Or since the only real change in the free 3.N1 update is adding an advert for the paid version, people could use the free version of UWUVCI from ModMii, which includes the same fixes as the paid version.

Obviously, I don't agree with the paywall direction you've taken your fork in, which is why I'm compiling free versions of it. And technically, all versions of UWUVCI are free, since it's an open source project after all, so as you've said yourself, anyone can compile it. But make no mistake, I do appreciate the work both yourself and Nico have put into the project.
 
Last edited by XFlak,
  • Like
Reactions: AamitMorthos, Blythe93 and ber71
XFlak said:
Or since the only real change in the free 3.N1 update is adding an advert for the paid version, people could use the free version of UWUVCI from ModMii, which includes the same fixes as the paid version.

Obviously, I don't agree with the paywall direction you've taken your fork in, which is why I'm compiling free versions of it. And technically, all versions of UWUVCI are free, since it's an open source project after all, so as you've said yourself, anyone can compile it. But make no mistake, I do appreciate the work both yourself and Nico have put into the project.
Click to expand...
I want to clear up a few points, because some things are being conflated. When I’ve said people are free to compile UWUVCI themselves, that was never meant to imply that redistributing modified builds is exempt from license requirements. UWUVCI uses open-source tools with licenses that require anyone distributing compiled builds to make the corresponding source code publicly available. That applies to everyone, including myself. That is why I opened a ticket on your GitHub repository asking about source availability. The build currently being distributed via ModMii differs from my fork. It is missing features that are present upstream, and it also introduces a bug. There is no clear credit or publicly available source for that specific build, which makes verification and issue tracking impossible.

As for the paid version, it was paywalled to help offset ongoing development expenses. Donations were suggested, but in practice, they do not cover those costs. The intent was to use that funding to bring certain third-party tools in-house by hiring help to rewrite them. I have already paid out of pocket to begin that process, and with payments currently unavailable, it puts everyone in a lose-lose situation.

Unrelated to what you wrote, but it needs to be stated, since my fork is not the official UWUVCI release, I will no longer post updates or announcements about it in these public channels to keep it clearly separated from the official project.
 
Last edited by ZestyTS,
  • Like
Reactions: Blythe93
You've already raised the same points on GitHub and I already answered. So I'll repeat it and be more clear in case you're still having a hard time understanding how I've done this.
  • I don't have a repository (public or private) that contains a copy of the UWUVCI source code.
  • I don't have a copy of the UWUVCI source code on my PC.
What I do have is a GitHub Actions workflow/script that links to your repository and patches the latest version of the code as it's being compiled. I deliberately set it up this way so I don't need to maintain a fork and can simply press a button to output new free versions of UWUVCI. So I don't have a copy of the source code, since GitHub itself is literally using your repository to compile it. And I don't need to share my script, since that's not a part of the UWUVCI project.

And I'm not sure what you're going on about, but my custom build is not missing features (unless you count the data collection "tutorial" and blacklisting) and if there are bugs they weren't introduced by me 😂
 
  • Like
Reactions: DolphinPussy and Blythe93
XFlak said:
You've already raised the same points on GitHub and I already answered. So I'll repeat it and be more clear in case you're still having a hard time understanding how I've done this.
  • I don't have a repository (public or private) that contains a copy of the UWUVCI source code.
  • I don't have a copy of the UWUVCI source code on my PC.
What I do have is a GitHub Actions workflow/script that links to your repository and patches the latest version of the code as it's being compiled. I deliberately set it up this way so I don't need to maintain a fork and can simply press a button to output new free versions of UWUVCI. So I don't have a copy of the source code, since GitHub itself is literally using your repository to compile it. And I don't need to share my script, since that's not a part of the UWUVCI project.

And I'm not sure what you're going on about, but my custom build is not missing features (unless you count the data collection "tutorial" and blacklisting) and if there are bugs they weren't introduced by me 😂
Click to expand...
I’m going to clarify this one last time, because we’re talking past each other.

The fact that your workflow pulls my repository at build time does not change the licensing obligations around redistribution. If you distribute a compiled binary that is materially different from upstream (features removed, behavior changed, bugs introduced), then the complete corresponding source for that distributed build must be made available in a verifiable way. A GitHub Actions script that applies undisclosed patches during compilation is itself part of the build process, and without it, the distributed binary cannot be reproduced.

Whether you personally keep a local copy of the source code is irrelevant. What matters is that an end user (or maintainer) cannot audit, verify, or reproduce the exact binary being distributed via ModMii. That is the problem I’ve been pointing out from the start. Regarding features and bugs, the ModMii build does differ from upstream behavior. It removes functionality that exists in my fork, and it introduces regressions that I can consistently reproduce. One example: create an injection where no images are fetched automatically and provide custom images instead. If you use my paid version, there is no error message pop-up, it works.

I’m not interested in arguing intent or motivation here. My concern is technical correctness, license compliance, and the ability to verify and debug distributed binaries. Right now, none of those are possible for the ModMii build. I’ve already explained my position both here and on GitHub, and I don’t think continuing this discussion publicly is productive. I’ve made my expectations clear, and I’m going to leave it at that.
 
  • Wow
Reactions: DolphinPussy
I agree with you that continuing this discussion publicly is not productive but I wanted to reply one final time to address any implications that the ModMii build introduces regressions.

Thanks for sharing an example via discord. Pasted below for context:
1769688625112.png1769688632688.png

The way you were talking I thought it was an actual bug, not a submission failure, which have been disabled deliberately as previously communicated on github:

The build script is what disables the tutorial, the license check, update checks, and the ability to send compatibility and feedback reports, so as not to disrupt your issue tracker or data collection.
...
Plus, if the script was shared exactly as it is, someone else might not be as nice and could re-enable compatibility and issue reporting and flood your github with reports from custom builds that don't have static fingerprints.
Click to expand...

I just forgot to disable the prompt to submit new images, but I'll disable that shortly too. If a user opted not to share images via pull request they would never see that error.

I'll repeat one last time that I don't have a modified copy of the source code locally or in a repo, so I can't share what I don't have. I've talked to a bunch of folks and I'm confident everything's above board, even if it might feel like a catch-22 to you. That said, you also didn't release the source code for your latest update (3.200.7) or the Mac wrapper, and CNUSPACKER on NuGet doesn't align with the publicly available source either, so the situation isn't exactly clean on either side🤷‍

I know on Discord you told me that you didn't release the source code for 3.200.7 because of your living situation, which I understand makes things difficult. But if you care so much about this licensing stuff then you probably should've just pulled your 3.200.6 release, since 3.200.7 is basically a rerelease of 3.200.5.

As I mentioned on Discord, I'm not trying to go back and forth with you on this stuff. I appreciate the work you've put into the project.
 
XFlak said:
As I mentioned on Discord, I'm not trying to go back and forth with you on this stuff. I appreciate the work you've put into the project.
Click to expand...
Just to butt in: I am not a great fan of what the way the project/fork is handled either, but for what it's worth, the main reason it's not worth going back and forth with this, is that you are wrong, and discussing it is pointless. Distributing a binary under the GPLv3 requires you to publish source code that enables the end user of the binary to build the exact binary you are distributing. It's not even enough to disclose the patches (ie. your script) which I take it you're not doing either, you must make available all that is required to build the binary yourself. This is very clearly explained here: https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary

Why you believe that using a script that changes things instead of cloning the repo and making changes is plainly ridiculous. That would render the entire source license worthless. Anyone could just publish paid for or closed source apps with GPL v3 code claiming "changes were only made in a script". The obligation to publish source code does not stem from cloning anyones repo, you are free to clone whatever repo you wish, make whatever changes you wish and build whatever binaries you wish without publishing anything,

It is making a binary file available to anyone that triggers the requirement to offer the complete sources necessary to build that binary available at the same time. And you are making the resulting binary available, without offering that, which is a clear GPLv3 violation.
 
  • Like
Reactions: ZestyTS
@ZestyTS & @Narrgel, I'm still confident I am not required to share any of my code since it's not a part of UWUVCI, but just to put your concerns to rest I decided to voluntarily share what I do have.

XFlak said:
I'll repeat one last time that I don't have a modified copy of the source code locally or in a repo, so I can't share what I don't have. I've talked to a bunch of folks and I'm confident everything's above board, even if it might feel like a catch-22 to you. That said, you also didn't release the source code for your latest update (3.200.7) or the Mac wrapper, and CNUSPACKER on NuGet doesn't align with the publicly available source either, so the situation isn't exactly clean on either side🤷
Click to expand...
Like I said, I don't have\need any UWUVCI source locally or otherwise and to prove it I've made my build script\workflow public. Now anyone can see how I'm building\patching it here. So at least things are clean on my side now

I hope no one abuses this, because as I warned in our github convo, someone else might not be as nice and could easily fork my repo and re-enable compatibility and issue reporting and send nonsense and/or adult images to your github from custom builds that don't have static fingerprints... making it impossible for you to blacklist them. So yeah, don't say I didn't warn you, but you asked for it sooo 🤷
 
  • Like
Reactions: jeannotte, KirbyBot, ber71 and 1 other person
XFlak said:
@ZestyTS & @Narrgel, I'm still confident I am not required to share any of my code since it's not a part of UWUVCI, but just to put your concerns to rest I decided to voluntarily share what I do have.


Like I said, I don't have\need any UWUVCI source locally or otherwise and to prove it I've made my build script\workflow public. Now anyone can see how I'm building\patching it here. So at least things are clean on my side now

I hope no one abuses this, because as I warned in our github convo, someone else might not be as nice and could easily fork my repo and re-enable compatibility and issue reporting and send nonsense and/or adult images to your github from custom builds that don't have static fingerprints... making it impossible for you to blacklist them. So yeah, don't say I didn't warn you, but you asked for it sooo 🤷
Click to expand...
I’m going to address the remaining claims clearly, and then I’m done with this publicly.

3.200.7 was a revert to 3.200.5. It did not introduce new functionality. It was built during a period when I did not have normal GitHub access, which I explained at the time. There was no hidden branch and no attempt to withhold modified source. Calling it a closed-source release is simply not accurate.

I did not write CNUSPacker. It is a public NuGet dependency. I do not maintain a private fork of it, and there are no proprietary modifications embedded in it. If there was a version mismatch at any point, that is a dependency alignment issue, not concealed code. Implying otherwise is misleading.

The Mac wrapper is not a separate proprietary project. It uses Sikaguir (Modern) or Kegworks (Legacy) to package the existing Windows executable with configuration. If you download the app and view the package contents, everything is there, including how it is configured. There is no additional license logic, no hidden features, and no closed modifications. It is not in the repository due to size and directory structure limitations, not because it contains undisclosed logic.

XFlak said:
@ZestyTS & @Narrgel, I'm still confident I am not required to share any of my code since it's not a part of UWUVCI, but just to put your concerns to rest I decided to voluntarily share what I do have.


Like I said, I don't have\need any UWUVCI source locally or otherwise and to prove it I've made my build script\workflow public. Now anyone can see how I'm building\patching it here. So at least things are clean on my side now

I hope no one abuses this, because as I warned in our github convo, someone else might not be as nice and could easily fork my repo and re-enable compatibility and issue reporting and send nonsense and/or adult images to your github from custom builds that don't have static fingerprints... making it impossible for you to blacklist them. So yeah, don't say I didn't warn you, but you asked for it sooo 🤷
Click to expand...
Everything required to build my release distribution is public, including the build script. There are no hidden patches applied during compilation. There are no private CI steps modifying the binary. The only non-public element is credential injection for a scoped service account used for repository operations. Those credentials are not in public source for obvious security reasons and are not part of the distributed binary.

Publishing your workflow does not grant anyone credentials to push to UWUVCI’s repositories. The public source does not contain usable tokens. GitHub secrets do not propagate to forks. Re-enabling compatibility or reporting in a fork does not grant authentication rights. The suggestion that making your workflow public somehow enables people to flood NicoAICP's repository is technically incorrect. Anyone attempting to target the repository would need valid credentials. That has nothing to do with workflow visibility.

For clarity, your workflow is not simply compiling upstream source. It programmatically patches behavior before compilation, including:
  • Forcing official verification to return true and removing the unofficial build banner
  • Disabling blacklist checks and altering device fingerprint logic
  • Disabling update checks
  • Removing compatibility submission, feedback, and reporting features
  • Disabling tutorial and local install guard logic
Those are functional changes that alter runtime safeguards and verification behavior. That is a behavioral fork, not a neutral rebuild. Forking and modifying is part of open source. However, a fork that disables verification and safeguards must be clearly represented as a modified fork, not presented in a way that suggests it is official or endorsed. Users should be able to distinguish between upstream releases and patched variants.

At this point:
  • Your workflow is public.
  • My build script is public.
  • Dependencies are public.
  • No credentials are embedded in public code.
Any remaining disagreement is about interpretation, not concealment. I’m not continuing this further.
 
Last edited by ZestyTS,
  • Haha
Reactions: DolphinPussy
let me guess,Nobody same problem.
No Internet Connection To download tools, bases, or required files, you need to be connected to the Internet. The program will now terminate.
Of course I always connect Internet...
1774529778731.png

Just now,I found the way,
If we used vpn,we should with TUN mode.because it won't connect internet by VPN.
 
Last edited by matthewL7iu,
  • Like
Reactions: grandosegood
PlantedWave5190 said:
Will anyone plan to update UWUVCI to support short names of game names that use two lines?

I'm making an inject of a Wii game that uses two lines of text for its name. But I've encountered a bit of a problem. After playing it and viewing the Daily Log will only show the first line of the game's name. For example, Tales of Symphonia: Dawn of the New World will use two lines of text like this;

Tales of Symphonia:
Dawn of the New World

However, after playing it and viewing the Daily Log in the Wii U menu after exiting will only show one line of text that says "Tales of Symphonia:". But when tapped, it will show up as;

Tales of Symphonia:
Dawn of the New World

Hopefully when this update comes out, I can put a short name that really describes what the game is, so Tales of Symphonia: Dawn of the New World will show up as "Tales of Symphonia: New World" on the Daily Log.

Oh, and one more problem; When creating a bootTvTex image, when entering text for a game on two lines, It will not fit perfectly. Hopefully the new update can resolve this issue by resizing the text to actually fit in full.
Click to expand...
It's been half a decade since I mentioned a feature about short lines for game names that use two lines. Has that been added or not? Sorry to ask.
 
Last edited by PlantedWave5190,
justacrab said:
heya I keep getting stuck on "downloading needed data" is there anything I can do i've been trying for weeks now
Click to expand...
Hey there, I second this. I have downloaded the version that actually has the installer and after running into the "downloading tools" infinite screen, I downloaded them manually and added them to the folder. I am now also stuck at the "downloading needed data" (which I assume are the bases?) and nothing happens. And yes, I have been letting it run for literally hours to no avail.

Anti-virus says nothing, and even whitelisting the whole folder isn't helping. Is there a place where to downloaded these bases manually, similar to what I did for the tools? Thanks!

-- Edit

Well, after looking at the log files, seems like it is an SSL error, I sadly don't know how I can get around that :/ If anyone is curious, the logs are in /AppData/Local/UWUVCI-3.
 
Last edited by Nevenanana,
Is it possible to fix New Super Mario Bros. DS hang on exit when we use RenderScale 2? Haven't checked other games yet if they also hang but pretty sure they will.
 
mrconsole said:
Is it possible to fix New Super Mario Bros. DS hang on exit when we use RenderScale 2? Haven't checked other games yet if they also hang but pretty sure they will.
Click to expand...
this happen to every game so no we cant fix an emulator by nintendo that we dont have the source code, just dont exit just turn off the console it isnt that hard.
 
  • Like
Reactions: mrconsole
Hey, thanks for the awesome project. Injecting with UWUVCI is much more comfortable than anything I tried of wii (I know there are also wonderful project for this on wii, but I had rough times with them on linux/wine ;) ).
One question, does injector supports rumble features? I tried to inject Warioland 4 romhack with rumble support and the game works, the rumble option is set on but it's not... rumbling :D

I tried official drill dozer VC and it works great so the gameboy player emulator has this feature.
Just now I thought that maybe I should use Drill Dozer as a base image? Or maybe it's the current limitation of UWUVCI?

Edit: Tried with Drill Dozer as a base, same effect: no rumble :|
 
Last edited by poli_pyc,

Site & Scene News

Go to forum More news

Popular threads in this forum

Strange Blue Blinking Wii U

Hacking Homebrew Project  Modernized YouTube for Wii U

Struggling to get WiiFlow/USBLoaderGX to recognize USB sticks

Feedback  Community Overclock Stats: A5X vs B1X Motherboards

Sonic 3 AIR Wii U teaser screenshot

Wii Games Performance on Wii U (vWii C2W Overclock) – Community Testing & Results Sharing

My dad's Wii U cannot install Aroma. HELP!!

Gaming Homebrew Misc Project  Roséverse - a 1:1 Miiverse revival by Project Rosé!