CmP

But, if I am not mistaken, something like this is already possible by modifying lib that is loaded in process memory. This way is likely more limited than modifying the file itself, but it may work.

Have you tried it at least? I highly doubt that searching for 500 consecutive addresses and editing all of them to one value can noticeably slow down your script. So are you sure that it does not suffice because of performance reasons? As pointed out above, editing values one-by-one in a loop is very inefficient. This approach should be used instead, if simple one with fuzzy search does not suffice: Example of implementing it: local startAddress = 0x12340000 local count = 500 local editValue = '555444' local values = {} for i = 1, count do values[i] = {address = startAddress; flags = gg.TYPE_DWORD; value = editValue} startAddress = startAddress + 4 end gg.setValues(values)

@DESYROLLERSE, you can't blame someone for not being able/not wanting to learn by "trial and error" approach, when you are not able/don't want to do this yourself. Just remember how many times you asked me to "give you an example" (more like write the code for you)? It looked like you were not able to progress in developing your script without getting more and more "examples". When I told similar thing to you last time, you were very angry, you were definitely thinking that I had to provide you everything you need when you ask for it. So since when you've started to agree with this statement? Looks like a clear example of hipocrisy and double standards.

JZ.N_28-01 (3)_src.lua

That's what I was writing about, making it possible to "leech". But you probably don't need to worry about it, until there will be high demand on the code stored at the server.

Yep, file extension does not matter. Show the code and contents of the file. Without this info noone will be able to help in this case.

Of course not, but in this case it does not even require medium level of "skill" or something. I agree, the protection will be stronger, but.. you forgot to consider one thing. Potential "leecher" will be able to get the code received from the server by either modifying "makeRequest" function to print/save to a file returned value or by modifying "load" function to print/save to a file it's first argument. That's all, requesting info from the server is no more required, since the "leecher" got it. After this, it can be shared with anyone.

This approach looks good, but it won't guarantee protection against leechers. With some knowledge a potential leecher can easily get "ID" that is generated for his device, then just share this ID and the password to someone else. After this, "someone else" will be able to use the script by modifying "makeRequest" function to perform a "valid" (with correct ID and password) request to the server. The "leecher" even won't need to be bothered by how the ID and the request is generated, because simple modification of "makeRequest" function to print received arguments will do everything for him.

That's good idea, but how are you going to generate those IDs?

You write some nonsense. It's also not related with the topic anyhow. Maybe my upvote to @Lenn1's comment has "hurt" you hard enough, so that you decided to mention me?

Log of using the script produced by slightly modified Script compiler: Those checks are pretty useless, because all of them can be bypassed. Script that is executing another script can override any function used for limitations (such as "blocking hooks", "setting expiration time") there. For example, a script relies on "os.date" function to check expiration time, but the function surprisingly returns not the expected result, but "0" or something else that will make that check useless.

Calling "load" function with some meaningless arguments in a loop, so that logging arguments of the function call to a separate file will produce many files with junk contents. In fact, this does not "block" anything. Actual code (in compiled or non-compiled form) will still be logged to a file, if script contains it.

@noblack, you forgot to delete the line in function "main". Also isVisible function does not accept arguments, so that "true" in this line is redundant. Moreover, this only works because of how Lua deals with extra arguments. From the Lua 5.3 reference manual (https://www.lua.org/manual/5.3/manual.html#3.4.11) : Another thing is that value returned by "prompt" function needs to be checked (because the dialog may be cancelled, in some cases accidentally) as well as value that is stored in "Result[4]", but I suggest you to leave these improvements to be done by the author of the topic (if he needs them at all).

You need to learn Lua and GG API, because the result can not be achieved without knowledge. There are at least 2 mistakes in your script because of which "it's not freezing": 1. Wrong usage of getListItems function. Incorrect usage: Correct usage: local list = gg.getListItems() 2. Using setValues function and expecting it to do the job of addListItems function. Incorrect (and even absurd) way to add items to the saved list: Correct way: list[1].value = '10000' list[1].freeze = true gg.addListItems(list)

Also that "UI" variable is redundant in your case. Don't use something just because others do it. Your main loop can be rewritten this way: while true do if gg.isVisible() then gg.setVisible(false) main() end gg.sleep(100) end

You need to explain that "idea" using words and not just drop some block of code. Noone here can read your thoughts. Moreover, quality of question/problem explanation affects receiving (or not receiving) answers more than anything else.

Got it, thanks for the answer. I assume that this information will be helpful for other forum members as well, since the question is not so trivial.

Well, this function is indeed very useful, but the question is: does it return updated information about process memory regions (because this is what author of the topic has written about, I suppose). I tried to find an answer to this question and got the following results. Script that was used for testing: local function calcTotalSize(ranges) local total = 0 for _, v in ipairs(ranges) do if v.state == 'Jh' or v.state == 'Ch' or v.state == 'Ca' or v.state == 'Cd' or v.state == 'Cb' or v.state == 'A' then total = total + (v['end'] - v.start) --print('start: ' .. v.start, 'end: ' .. v['end']) end end return total end local t1 = gg.getRangesList() print('Start') print('Count:', #t1) print('Size:', calcTotalSize(t1)) gg.setVisible(false) while not gg.isVisible() do gg.sleep(100) end local t2 = gg.getRangesList() print('\nFinish') print('Count:', #t2) print('Size:', calcTotalSize(t2)) Testing strategy: 1. Select targeted process (to get updated info about it's memory regions). 2. Launch the script. 3. Perform something in targeted process to "trigger" memory allocation/deallocation. 4. Click on GG floating icon. 5. Analyze info from the script output. Script execution result: Conclusion: Apparently, if I am not missing something, "getRangesList" function does not update info about process memory regions.

He probably meant info that GG receives when it is attached to the process. For example, list of memory regions, total "size" of process in memory, etc.