Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Filestealer truncate doesnt work with gluapack, possible ideas / solutions #49

Open
wrefgtzweve opened this issue Dec 13, 2022 · 5 comments · May be fixed by #50
Open

Feature: Filestealer truncate doesnt work with gluapack, possible ideas / solutions #49

wrefgtzweve opened this issue Dec 13, 2022 · 5 comments · May be fixed by #50

Comments

@wrefgtzweve
Copy link

Describe the issue
Servers that run gluapack()() don't work with write_mode truncate but work with append. This was expected when truncate was introduced and is logical. It might be cool to have gluapack automatically detect gluapack or other kinds of script steal preventions and "bypass them", i know this sounds and likely painful to do. But having the option to specifically disable known preventions like gluapack might be useful to people as truncate is a preferrable alternative for servers that don't run these preventions.

Maybe a complete different way of solving this would be a mode where only new code would be appended to the file while old code would still be kept.

Extra information
Might be useful, https://www.unknowncheats.me/forum/garry-s-mod/486883-gluapack-bypass.html

@wrefgtzweve wrefgtzweve changed the title Feature: Filestealer doesnt work with gluapack Feature: Filestealer truncate doesnt work with gluapack, possible ideas / solutions Dec 13, 2022
@dhkatz
Copy link

dhkatz commented Dec 23, 2022

Someone wrote a bypass in rust here https://github.com/imfriendly/gmod-filestealer-rs

@lewisclark
Copy link
Owner

lewisclark commented Dec 24, 2022

Using write_mode = "append" is the best solution to this problem at the moment. Hard coding a check for a specific packing tool inside of gluasteal is a very fragile solution.

I imagine the best solution is to add a function or variable to the gluasteal environment that gives the user the ability to decide whether or not to write a file, per execution of gluasteal.lua.

For example:

if gluasteal.SOURCE:find("some_packer()()") then
    gluasteal.SetShouldWriteFile(false)
end

or, even better, return a second value from gluasteal.lua (alongside the should load value which is already present):

local should_load = not gluasteal.SOURCE:find("while true do end")
local should_write = not gluasteal.SOURCE:find("some_packer()()")

return should_load, should_write

This way, any hard coded logic for a specific packer (which is fragile by nature) is moved from the source code of gluasteal to the user's gluasteal.lua file.

I suppose a write_mode = "once" mode would also be an appropriate solution - will not truncate or append to an existing file.

I would love to hear thoughts on this or any better solutions to the problem.

@lewisclark
Copy link
Owner

lewisclark commented Dec 25, 2022

If you can test it, please do. You can download the pre-compiled update from the bottom of this page.

@wrefgtzweve
Copy link
Author

Just tested it, works great! I like the idea of write_mode once though, not sure if that's a lot of work but it might be neat to have that so you don't need to do the lua.

@avivi55
Copy link

avivi55 commented Sep 19, 2023

https://gluapack.com/help/

Billy added a way to opt out.
You can do this by adding +tv_nochat no_gluapack to your launch options on steam or lutris.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants