Nm088 Posted May 30 Author Posted May 30 @Ratinira1 I can confirm the culprit on my side by setting my vpn to japan: the fetch can be blocked depending on your provider, location, vpn server region, and IP range. In short, whether the MO2 fetch works depends on what Cloudflare or LoversLab accepts from your IP. Using a vpn region/server that works is still the simplest workaround, but I worked on an alternative fallback. I made a pre-release test update for MO2 + Firefox users. If Cloudflare blocks the direct MO2 request, automatic update checking cannot reliably work through MO2 alone. However, the plugin can now use the browser extension as a fallback. Expected behavior when fetch is blocked: 1. Fetch fails. 2. The manager shows a Cache button for the blocked row. 3. Cache opens the LoversLab download page in your browser. 4. The Firefox extension scans the available LoversLab archives on that page. 5. MO2 shows a “Choose LoversLab Archive” window. 6. You select the archive you want. 7. The extension starts the browser download and sends the archive to MO2’s Downloads folder with LL Integration metadata. 8. Once detected, the manager should offer Install when the archive matches the row well enough. Otherwise, the archive should still be available in MO2’s Downloads tab for manual install. There are still edge cases I do not handle perfectly. This is an experimental build, mainly to confirm whether this fallback works outside my own environment. I have not updated the Chromium or Vortex versions yet, because this is a lot of work. For Vortex, I will wait and see if there is demand for this fallback first, since it requires a big logic change with a lot of extra case handling. I also have not ported the Voice Manager changes to MO2 yet. You can install this over your current installation. The "Assist Fetch Current Page" button in the extension is mostly a debug helper for me, so you can ignore it for now. You are not required to test this. It is totally optional. If this version has issues and you have access to a vpn , you can always fall back to the previous version and use a vpn region or server that works. Small note (if you test it) : after selecting an archive, give the manager a few seconds while the native helper pushes it into MO2. The button should become Install or Reinstall once the archive is ready. The experimental build archive: LL-Integration-Experimental-Build.zip
Ratinira1 Posted May 31 Posted May 31 (edited) @Nm088 So, I installed new build, updated cookies through Firefox, and now I dont have any errors) Now my window looks like that. (I pressed intall button for first 3 to test) Spoiler Or like that when I first open window, before pressing fetch updates Spoiler Edited May 31 by Ratinira1
Nm088 Posted May 31 Author Posted May 31 @Ratinira1 Ty for testing the build! This looks normal in a first view, The green Install buttons mean LL Integration found matching archives already present in MO2’s Downloads folder. This can happen if the archive was downloaded before, or if the new Firefox fallback pushed it into MO2 successfully. The manager uses the file name / metadata / match score to decide whether the archive is likely the right one. If you press Install, MO2 should open its normal install window for that archive. The Cache button means the normal direct fetch was blocked or could not be completed. In that case, click Cache. It should open the LoversLab download page in Firefox, let the extension scan the available files, then MO2 should ask you which archive you want to download. So the rough flow is: 1. Fetch = try normal update check. 2. Cache = use Firefox fallback when direct fetch is blocked. 3. Install = matching archive already exists in MO2 downloads and can be installed. If an Install button appears for the wrong archive, please tell me which row and archive name. I do not have a blacklist button yet, but that is probably the next safety feature: a "wrong archive / ignore this match" action so the manager stops offering that archive for that row. If you find other bugs or have question like editing your meta, fixing versions, just ask me.
Ratinira1 Posted June 1 Posted June 1 Great, then now I need something to update to check updates) One little questions, if you dont mind: what does "not checked" in info means? Oh, and thank you very much for doing all that fixes for me🙂
Nm088 Posted June 1 Author Posted June 1 @Ratinira1 Not checked only means the manager has not checked that row yet in the current manager session. It does not necessarily mean an error. When you first open the manager, rows can show not checked until you press Fetch Updates or Fetch on that row. If your IP is blocked by Cloudflare, the normal Fetch may fail for that row. In that case the button should change to Cache. Then when you click Cache it opens the LoversLab download page through Firefox, lets the extension read the available archives, and then you can compare and select the archive from the list. So the usual flow is: 1. Open manager. 2. Press Fetch Updates or Fetch. 3. If direct fetch works, the manager compares versions normally. 4. If direct fetch is blocked, use Cache. 5. Cache lets Firefox extension read the download page and show the available archives. So not checked is just the initial state, you can ignore it.
Ratinira1 Posted June 1 Posted June 1 @Nm088 for me "not cheked" is it always state. It doesnt mater if I just opened MO2 or pressed Fetch Updates there awlays been "not cheked". Is that a problem?
Nm088 Posted Monday at 03:24 PM Author Posted Monday at 03:24 PM (edited) @Ratinira1 It depends a little on the Status column, If the row says Ready / Manual / Downloaded / Installed through registry and the info says (not checked), that usually only means LL Integration has not performed a fresh version check for that row yet. It is not automatically a problem. But if you press Fetch Updates and every row still stays “not checked”, then something is stopping the update pass before those rows are reached. For example, if Cloudflare blocks one row, the manager may stop and ask you to use Cache on that blocked row first. To force-check one mod, try pressing Fetch on that specific row. If the row changes to Cache, direct fetch is blocked and you should use Cache. If it changes to OK / Update / Downloaded, it worked. If it stays exactly “not checked” after pressing Fetch on the row, please send me a screenshot of that row including Status, Info, and the button text. Thks for the feedback, btw. This is very helpful for me. Edited Monday at 03:24 PM by Nm088
Ratinira1 Posted Monday at 05:07 PM Posted Monday at 05:07 PM Well, they all say "not checked", no matter what I press, both Fetch updetes or fetch on single raw... Spoiler
Nm088 Posted Monday at 06:35 PM Author Posted Monday at 06:35 PM @Ratinira1 Thanks, this screenshot helps. I think the wording is confusing here. "Installed through LL Integration registry; not checked" means LL Integration remembers that this archive was already installed through the manager, so it suppresses the repeated Install/Reinstall state for that archive. It does not clearly tell us whether Fetch succeeded or failed, and that is probably something I need to improve in the UI. To test the update check itself, pick one row and press Fetch on that row. 1. If it changes to OK / Update, the direct fetch worked and LL Integration could compare the versions. 2. If it changes to Cache, direct fetch was blocked and you should use Cache. 3. If the fetch works but the mod has no current version, or LL Integration cannot detect the version from the archive name, you may need to click Edit and set or fix the Current version and File pattern for that mod. 4. If it stays exactly "Installed through registry; not checked", then the registry state may be hiding the useful fetch result, and I need to improve that wording and behaviour. Some LoversLab archives do not have clean version names, or the archive name is different from the mod page name.. In those cases the tool cannot always guess the right version automatically. The Edit window is there so you can fix the metadata or pattern for that specific mod. For now, if you want to force a fresh test, you can use Install Registry and remove one entry, then try Fetch again on that row. The main goal of the tool was to speed up the LoversLab mod workflow: quickly open pages, check updates, download archives, install them, and edit metadata when needed. Another big issue I had with LoversLab mods is that it is easy to forget where an archive came from, especially when the archive name is unclear or different from the mod page name. So the tool also tries to keep the LoversLab link and metadata attached to the archive/mod, instead of relying only on memory or file names. Some labels are still based on how I debug/use the tool internally. They may be technically accurate, but not clear enough for users. I think (not checked) is one of those cases, so I will rework the wording for the UI to make it easier to understand.
Ratinira1 Posted Monday at 07:12 PM Posted Monday at 07:12 PM @Nm088 thank you very much for clarification) 1
Celticwolf369 Posted Thursday at 08:00 PM Posted Thursday at 08:00 PM I did a search for this in the thread and nothing was found for "Trojan:Win32/Tecabans.STV!cl" I get this every time I try and D/L 0.8 ver. Please explain, thnx.
Nm088 Posted Thursday at 08:26 PM Author Posted Thursday at 08:26 PM (edited) @Celticwolf369 If the detected file is from my official upload, it is very likely a false positive. LL Integration is open source, and the release is built from this repository. The tool also includes a native helper executable and browser/native messaging behavior, which can trigger LL Integration is open source, so you can inspect the code and build it manually yourself if you prefer. The release includes a native helper executable and browser/native messaging behavior, so Microsoft Defender cloud heuristics may flag it in experimental builds. If the detection is on my official release file, it is very likely a false positive, but I still need the exact file/path from Windows Security to confirm what was flagged. The experimental build didn't got pushed yet, i have a main mod in build and it's my main focus : if you want it pushed for building the experimental build yourself (because you have a fetch problem), then i will push it. Ty for your feedback. Edited Thursday at 08:27 PM by Nm088 1
Celticwolf369 Posted Thursday at 08:38 PM Posted Thursday at 08:38 PM 5 minutes ago, Nm088 said: @Celticwolf369 If the detected file is from my official upload, it is very likely a false positive. LL Integration is open source, and the release is built from this repository. The tool also includes a native helper executable and browser/native messaging behavior, which can trigger Microsoft Defender cloud heuristics in experimental builds. That said, I still need the exact detected file/path to confirm it is my official build and not a modified/corrupted download. Please send the Windows Security detection details, especially the affected file path. If it is my release file, I will submit it to Microsoft as a false positive. LL Integration is open source, so you can inspect the code and build it manually yourself if you prefer. The release includes a native helper executable and browser/native messaging behavior, so Microsoft Defender cloud heuristics may flag it in experimental builds. If the detection is on my official release file, it is very likely a false positive, but I still need the exact file/path from Windows Security to confirm what was flagged. The experimental build didn't got pushed yet, i have a main mod in build and it's my main focus : if you want it pushed for building the experimental build yourself (because you have a fetch problem), then i will push it. Ty for your feedback. Thnx for the quick reply! HYG: Detected: Trojan:Win32/Tecabans.STV!cl Removed This program is dangerous and executes commands from an attacker. file: C:\Users\ME(;P)\LL\LLIntegration-0.8.zip webfile:C:\Users\ME(;P)\LL\LLIntegration-0.8.zip|https://www.loverslab.com/files/file/48614-ll-integration/?do=download&r=2154536&confirm=1&t=1&csrfKey=203d23ff599fdab1db5c44ba497e6a4b|pid:28668,ProcessStart:134250762371934330 I hope this helps
Celticwolf369 Posted Thursday at 08:41 PM Posted Thursday at 08:41 PM 2 minutes ago, Celticwolf369 said: Thnx for the quick reply! HYG: Detected: Trojan:Win32/Tecabans.STV!cl Removed This program is dangerous and executes commands from an attacker. file: C:\Users\ME(;P)\LL\LLIntegration-0.8.zip webfile:C:\Users\ME(;P)\LL\LLIntegration-0.8.zip|https://www.loverslab.com/files/file/48614-ll-integration/?do=download&r=2154536&confirm=1&t=1&csrfKey=203d23ff599fdab1db5c44ba497e6a4b|pid:28668,ProcessStart:134250762371934330 I hope this helps I just D/L'd the LL-Integration-Experimental-Build.zip and did not get the error
Nm088 Posted Thursday at 09:11 PM Author Posted Thursday at 09:11 PM @Celticwolf369 Thanks, that helps a lot. Since the detected file is the official `LLIntegration-0.8.zip` downloaded from my LoversLab page, this is very likely a Microsoft Defender false positive. The zip contains the native helper executable used for browser/native messaging, and that kind of behavior can trigger Defender cloud heuristics, especially on small/open-source tools that are not code-signed. I will submit the release zip to Microsoft as a false positive. For now, if you do not trust the binary release, the safest option is to wait, or inspect/build the project manually from source once I push the current version. Do not whitelist it unless you are comfortable with that. Small note: you may want to avoid posting full download URLs with csrfKey in public screenshots and posts if you can edit that and remove it for your security. It is probably expired or low risk, but better to avoid sharing session like tokens. I did a check on my side: PS C:\Users\myuser\Downloads> Get-FileHash "$env:USERPROFILE\Downloads\LLIntegration-0.8_LoversLab.zip" -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 E46E41A26308938E213FCD4E4A0DDF048DFDB716EBD30020F7E64B160FBC23ED C:\Users\nm088\Downloads\LLIn... PS C:\Users\myuser\Downloads> Get-FileHash "$env:USERPROFILE\Downloads\LLIntegration-0.8)_github.zip" -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 E46E41A26308938E213FCD4E4A0DDF048DFDB716EBD30020F7E64B160FBC23ED C:\Users\nm088\Downloads\LLIn... I have not submitted the Microsoft false-positive report yet because the form asks for the Microsoft security product/version used for the detection. Can you tell me: 1. Are you on Windows 10 or Windows 11? 2. Are you using Microsoft Defender only, or another antivirus too? I already verified the file hash on my side. The LoversLab download and my local GitHub release copy have the same SHA256, so the flagged file is my official upload. 1
Nm088 Posted Thursday at 09:53 PM Author Posted Thursday at 09:53 PM (edited) @Celticwolf369 Sorry, I did not see your new comment before editing my previous reply. If LL-Integration-Experimental-Build.zip does not get flagged for you, you can use that one. It includes the same base tool as 0.8, plus the new experimental Firefox/MO2 fallback for blocked fetch requests. That is still useful information, thanks. It means Defender is flagging the 0.8 zip specifically, but not the experimental build. That is weird, but also a good sign. I will still submit the 0.8 zip to Microsoft as a false positive, since I verified that the LoversLab download matches my official release hash. Edited Thursday at 09:55 PM by Nm088 1
Celticwolf369 Posted Thursday at 09:55 PM Posted Thursday at 09:55 PM (edited) 44 minutes ago, Nm088 said: @Celticwolf369 Thanks, that helps a lot. Since the detected file is the official `LLIntegration-0.8.zip` downloaded from my LoversLab page, this is very likely a Microsoft Defender false positive. The zip contains the native helper executable used for browser/native messaging, and that kind of behavior can trigger Defender cloud heuristics, especially on small/open-source tools that are not code-signed. I will submit the release zip to Microsoft as a false positive. For now, if you do not trust the binary release, the safest option is to wait, or inspect/build the project manually from source once I push the current version. Do not whitelist it unless you are comfortable with that. Small note: you may want to avoid posting full download URLs with csrfKey in public screenshots and posts if you can edit that and remove it for your security. It is probably expired or low risk, but better to avoid sharing session like tokens. I did a check on my side: PS C:\Users\myuser\Downloads> Get-FileHash "$env:USERPROFILE\Downloads\LLIntegration-0.8_LoversLab.zip" -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 E46E41A26308938E213FCD4E4A0DDF048DFDB716EBD30020F7E64B160FBC23ED C:\Users\nm088\Downloads\LLIn... PS C:\Users\myuser\Downloads> Get-FileHash "$env:USERPROFILE\Downloads\LLIntegration-0.8)_github.zip" -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 E46E41A26308938E213FCD4E4A0DDF048DFDB716EBD30020F7E64B160FBC23ED C:\Users\nm088\Downloads\LLIn... I have not submitted the Microsoft false-positive report yet because the form asks for the Microsoft security product/version used for the detection. Can you tell me: 1. Are you on Windows 10 or Windows 11? 2. Are you using Microsoft Defender only, or another antivirus too? I already verified the file hash on my side. The LoversLab download and my local GitHub release copy have the same SHA256, so the flagged file is my official upload. 1. Windows 11 2. Microsoft Defender only Edited Thursday at 09:56 PM by Celticwolf369 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now