Jump to content
  • 0

How to load addresses from new allocated memory page


Platonic

Question

How can i load the addresses from new allocated memory pages. When i use gg.loadResults it only loads the addresses from the already existing memory pages. The script is supposed to load the table 'q'. Which are addresses from new allocated memory pages.

I want to edit all the bytes to some UTF16 characters using gg.editAll. But do let me know if there is other way.

menu = {}
menu[1] = {address = gg.allocatePage(gg.PROT_WRITE) + 0x10, flags = gg.TYPE_QWORD}
strings = {}
loop = 0
for i, v in ipairs(menu) do
for i= 1, 118 do
strings[#strings + 1] = {address = menu[1].address + loop, flags = gg.TYPE_BYTE}
loop = loop + 1
end
end
q = gg.getValues(strings)
gg.loadResults(q)

 

Link to comment
Share on other sites

4 answers to this question

Recommended Posts

1 hour ago, Platonic said:

When i use gg.loadResults it only loads the addresses from the already existing memory pages.

Your codes load the new addresses that you just loaded. Run script repeatly and you can see loaded addresses are always changing. You can also browse there that all values are zero(s). and that memory region has 4kb size.

1 hour ago, Platonic said:

The script is supposed to load the table 'q'. Which are addresses from new allocated memory pages.

Yes. It does. I dont see any error.

 

1 hour ago, Platonic said:

I want to edit all the bytes to some UTF16 characters using gg.editAll.

I noticed an error here.

UTF16 is word type(2 bytes). But in codes, you chose to work with byte type(1 byte-char-utf8).

 

Here's is my codes.

local newmem = gg.allocatePage(gg.PROT_WRITE)
local string = "Its been a while. How are you in these days, my buddy?"
local stringTable = {}
string:gsub(".",function(c) table.insert(stringTable,c) end) --convert string to table
  
local addrs = {}
local utf16Size = 2
for i=1, #string do
    addrs[i] = {}
    addrs[i]["address"] = (newmem+0x10) + (i-1)*utf16Size
    addrs[i]["flags"] = gg.TYPE_WORD
    addrs[i]["value"] = ";"..stringTable[i]
    --utf8 :
    --utf16 ;
end
gg.setValues(addrs)
gg.loadResults(addrs)

 

If you want editAll() only, remove some unnecessary lines and add two line like this after loadResults().

gg.getResults(gg.getResultsCount())
gg.editAll(";"..string, gg.TYPE_WORD)

 

Link to comment
Share on other sites

1 hour ago, Lover1500 said:

Your codes load the new addresses that you just loaded. Run script repeatly and you can see loaded addresses are always changing. You can also browse there that all values are zero(s). and that memory region has 4kb size.

This is extremely weird. I swear on my life that before i posted this question the addresses did not load in the result list, and i did not change anything to the script, it was as posted here. I could not even find the address using the address (mask) search feature in GG. Weird that it now works with the same script. I recall now that the only addresses GG does not find using address mask search are the addresses that are out of boundary. Like with tagged pointers, perhaps thats why it did not load in the result list. Not sure.

Link to comment
Share on other sites

4 hours ago, Lover1500 said:

I noticed an error here.

UTF16 is word type(2 bytes). But in codes, you chose to work with byte type(1 byte-char-utf8).

 

Here's is my codes.

local newmem = gg.allocatePage(gg.PROT_WRITE)
local string = "Its been a while. How are you in these days, my buddy?"
local stringTable = {}
string:gsub(".",function(c) table.insert(stringTable,c) end) --convert string to table
  
local addrs = {}
local utf16Size = 2
for i=1, #string do
    addrs[i] = {}
    addrs[i]["address"] = (newmem+0x10) + (i-1)*utf16Size
    addrs[i]["flags"] = gg.TYPE_WORD
    addrs[i]["value"] = ";"..stringTable[i]
    --utf8 :
    --utf16 ;
end
gg.setValues(addrs)
gg.loadResults(addrs)

 

The script works great. Yes i used byte, i believed it not to make a difference if i load them afterwards in the result list as the editAll should give the same result. But i can see the logic of working by WORD. Its the appropriate data type and must be faster as it does less loops to.

Did not change anything to your script. Just added some things so its adjusted to the test subject. Script working fine.

local newmem = gg.allocatePage(gg.PROT_WRITE)
local string = "Doing good. Hearing good stories from the Admin, proud of what it has and will become"
length = {{address = newmem + 0x10, flags = gg.TYPE_BYTE, value = #string, name = "Length"}, {address = newmem, flags = gg.TYPE_DWORD, value = 0, name = "START"}}
gg.setValues(length)
gg.addListItems(length)
local stringTable = {}
string:gsub(".",function(c) table.insert(stringTable,c) end) --convert string to table
local addrs = {}
local utf16Size = 2
for i=1, #string do
    addrs[i] = {}
    addrs[i]["address"] = (newmem+0x14) + (i-1)*utf16Size
    addrs[i]["flags"] = gg.TYPE_WORD
    addrs[i]["value"] = ";"..stringTable[i]
end
gg.setValues(addrs)

gg.searchNumber('238,113,273', gg.TYPE_QWORD)
r = gg.getResults(20)
for i, v in ipairs(r) do
v.address = v.address + 0x18
v.value = newmem
end
gg.setValues(r)
gg.addListItems(r)

Appreciated.

Link to comment
Share on other sites

11 hours ago, Platonic said:

This is extremely weird. I swear on my life that before i posted this question the addresses did not load in the result list, and i did not change anything to the script, it was as posted here. I could not even find the address using the address (mask) search feature in GG. Weird that it now works with the same script. I recall now that the only addresses GG does not find using address mask search are the addresses that are out of boundary. Like with tagged pointers, perhaps thats why it did not load in the result list. Not sure.

The issue does happen. See video. Not sure why:

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.