Jump to content
  • 0

Can a group search be done for encrypted value or any other way to speed up the process?


Question

Posted (edited)

Hello,

The value I need is encrypted.  So I perform a search on the exact value and I check the "value is encrypted" option. Then I do the usual decrease, refine....etc until I find the correct value. I know it's encrypted because if I don't use the "value is encrypted" option I can't find it.  My question is, how can I speed up or automate the process? Normally for a non-encrypted value I would perform a group search and then create a script and done. But unfortunately in this case the value is encrypted and once I type in my group search the "value is encrypted option" disappears. And no matter what I use for a group search does not find the value. So when I close and reopen the game I am forced to repeat the whole search then decrease then refine process every time which is time consuming. Any trick to speed up or automate this situation?  Thank you very much

Edited by Sami1982

Recommended Posts

  • 0
Posted (edited)
gg.setRanges(gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC)
gg.searchNumber("17A;1,075,642,368A;1,900,544A;1,310,728A;589,828A;1,703,957A;1,703,969A;1,376,289A;1,920A;469,762,048A::185", gg.TYPE_DWORD)
gg.refineNumber("1,900,544", gg.TYPE_DWORD)
print("Group search: ", gg.getResultsCount())
local grp = gg.getResults(gg.getResultsCount())
for i, v in ipairs(grp) do
  v.address = v.address - 0x4
  v.flags = gg.TYPE_DWORD
  end
gg.loadResults(grp)
gg.searchPointer(0)
print("First Pointer search: ", gg.getResultsCount())
gg.searchPointer(0)
print("Second Pointer search: ", gg.getResultsCount())
local t = gg.getResults(gg.getResultsCount())
local sensitivity = {}
for i, v in ipairs(t) do
  sensitivity[i] = {address = v.address + 0x4, flags = gg.TYPE_FLOAT}
end
sensitivity = gg.getValues(sensitivity)
local healthPointer = {}
for i = 1, #sensitivity do
  if sensitivity[i].value == 1.0 then
    healthPointer[i] = {address = t[i].address, flags = gg.TYPE_DWORD}
  end
end
gg.loadResults(healthPointer)
print("Results healthPointer: ", gg.getResultsCount())
gg.searchPointer(0)
print("Third Pointer search: ", gg.getResultsCount())
local t = gg.getResults(gg.getResultsCount())
local health = {[1] = {address = res[1].address - 0xc, flags = gg.TYPE_FLOAT, name = "Health"}}
gg.addListItems(health)
gg.loadResults(health)
25 minutes ago, Sami1982 said:

Wait maybe I misunderstood about the pointer.....when I click on the health value and click GOTO, this is the line that I long pressed on and clicked GOTO pointer.  So from 5C to 68 is 12 bytes right?

capture5.jpg

Okay when I changed all the 0xC to 0X4 the first and second pointer searches are successful but i get 0 results for the third pointer search.

 

capture6.jpg

Edited by Sami1982
  • 0
Posted (edited)
1 hour ago, Sami1982 said:

Wait maybe I misunderstood about the pointer.....when I click on the health value and click GOTO, this is the line that I long pressed on and clicked GOTO pointer.  So from 5C to 68 is 12 bytes right?

capture5.jpg

True, but before you can do that 0xC with a script you must first get there through pointer searches.

There are some other issues with the script that need to be explained i think.

When your doing a pointer search with GG all your doing is searching a value that represent an address in memory.

Let's go from the start.

1693951128_Capturadepantalla2024-01-06005306.thumb.png.3faa9a3769685b477b9b99ddb18d8bd6.png

You have your health value at address 0x022023EC and you have a pointer 12 bytes away from it, it's at address 0x022023F8

Address 0x022023F8 has the value 8B7D02E0h

8B7D02E0h is a called a pointer because the value represents an address in memory. When you press "go to pointer" it means that GG will bring you to the address 0x8B7D02E0h.

2094014279_Capturadepantalla2024-01-06010110.thumb.png.4dd1e243ff2e5e4568970221b494b77b.png

I now whent to the pointer, as you can see the highlighted address is 0x8B7D02E0 and under it you have your refined value from the group search 0x8B7D02E4

And that is also the location where you came up with your group search.

When you did your group search and refined you had a lot of results left but let's say that you only had one address in the result list that has the value 1,900,544 and it's the correct one it would be looking like this:

imagen.thumb.png.42d7250531750fcf2cb2a9db7e004cf9.png

The value you refined is located at address 0x8B7D02E4

We now need to work backwards to get to or health value and perform a pointer search on the pointer we just whent to. The pointer that we just whent to was 0x8B7D02E0, so it's 4 addresses above the address that holds the value you just refined to, which is address 0x8B7D02E4. So first you have to tell the script to subtract the current address 0x8B7D02E4 - 0x4 and then load it in the result list. That's what

local grp = gg.getResults(gg.getResultsCount())
for i, v in ipairs(grp) do
  v.address = v.address - 0x4
  v.flags = gg.TYPE_DWORD
end

was doing, instead for 1 address in the result list it was doing it for all the addresses in the result list.

After it subtracted 0x4 from the address 0x8B7D02E4, so your address became 0x8B7D02E0 (it's the same address you whent to using "go to pointer"), and then you used

gg.loadResults(grp)

to load the new address in the result list. So now result list will look like this:

243893160_Capturadepantalla2024-01-06012439.thumb.png.009a6be4ba6ebf97d5448ad98572e830.png

Now you will ask GG to perform a pointer search on that address(0x8B7D02E0), with that i mean that your telling GG to search in memory for addresses that hold the value 8B7D02E0h

And of all the address in memory, which address you know for sure holded the value 8B7D02E0h ?

Right, address 0x022023F8 holded the value 8B7D02E0h.

888442256_Capturadepantalla2024-01-0601314.thumb.png.c13e9a8b5466c339554b9e27f16522d0.png

The same address of where the address that holds your health value was located 12 bytes above it.

So by using

gg.searchPointer(0)

Your telling GG for search the value 8B7D02E0h in memory. You get perhaps a few results.

Now you get a few results but between all those the results the right address is in there 0x022023F8h:

1725610857_Capturadepantalla2024-01-060134341.thumb.png.4f895988d562eeeb2d53e79e6c469c49.png

You know that 12 bytes above the address the address of your health is located (0x022023EC) so you don't have any reason to perform the searchPointer(0) again because your already at the address you started from.

Now you need to tell GG to subtract 12 bytes(0xC) from the address 0x022023F8h and get the value at that new address. Since you have more then one result use a loop.

local t = gg.getResults(gg.getResultsCount())
for i, v in ipairs(t) do
  v.address = v.address - 0xC
  v.flags = gg.TYPE_FLOAT
 end
gg.loadResults(t)

Get the results in a table t, and subtract all the addresses with - 0xC and set the flags as float. Then when you load the table t using

gg.loadResults(t)

it will load the new address in the result list type float. You gone have multiple addresses loaded because there are many addresses that go to the pointer you whent to, so they all hold the same value (8B7D02E0h)

In GG it would look like this if you had a more accurate group search around that address your performing a pointer search on:

imagen.thumb.png.0c71d9c663878d0798d769a42467a5a0.png

Since the group search is not that accurate which causes you have to more then 100 results when refining to your value 1,900,544 and you performing pointer search on each of those 100+ addresses that where loaded in the result list you probably gone get something like this, possible they are all health values for different objects but the health value of your character is of course in there at address 0x022023EC:

1367424172_Capturadepantalla2024-01-0601575.thumb.png.04cd3286f92f6de36b762f1bc18a2ede.png

I am not sure if all makes sense?

 

Edited by nok1a
added more parts of the script and corrected some sentences
  • 0
Posted
1 hour ago, Sami1982 said:
gg.setRanges(gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC)
gg.searchNumber("17A;1,075,642,368A;1,900,544A;1,310,728A;589,828A;1,703,957A;1,703,969A;1,376,289A;1,920A;469,762,048A::185", gg.TYPE_DWORD)
gg.refineNumber("1,900,544", gg.TYPE_DWORD)
print("Group search: ", gg.getResultsCount())
local grp = gg.getResults(gg.getResultsCount())
for i, v in ipairs(grp) do
  v.address = v.address - 0x4
  v.flags = gg.TYPE_DWORD
  end
gg.loadResults(grp)
gg.searchPointer(0)
print("First Pointer search: ", gg.getResultsCount())
gg.searchPointer(0)
print("Second Pointer search: ", gg.getResultsCount())
local t = gg.getResults(gg.getResultsCount())
local sensitivity = {}
for i, v in ipairs(t) do
  sensitivity[i] = {address = v.address + 0x4, flags = gg.TYPE_FLOAT}
end
sensitivity = gg.getValues(sensitivity)
local healthPointer = {}
for i = 1, #sensitivity do
  if sensitivity[i].value == 1.0 then
    healthPointer[i] = {address = t[i].address, flags = gg.TYPE_DWORD}
  end
end
gg.loadResults(healthPointer)
print("Results healthPointer: ", gg.getResultsCount())
gg.searchPointer(0)
print("Third Pointer search: ", gg.getResultsCount())
local t = gg.getResults(gg.getResultsCount())
local health = {[1] = {address = res[1].address - 0xc, flags = gg.TYPE_FLOAT, name = "Health"}}
gg.addListItems(health)
gg.loadResults(health)

 

Your script can not be same because your using different group search, and where you found your group search the structure is different. You only have to do one time a pointer search and your not using any values to filter out irrelevant results. You can remove most of the lines from it, here some example based on your group search and pointer you when't to.

gg.setRanges(gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC)
gg.searchNumber("17D;1,075,642,368D;1,900,544D;1,310,728D;589,828D;1,703,957D;1,703,969D;1,376,289D;1,920D;469,762,048D::185", gg.TYPE_DWORD)
gg.refineNumber("1,900,544", gg.TYPE_DWORD)
print("Group search: ", gg.getResultsCount())
local grp = gg.getResults(gg.getResultsCount())
for i, v in ipairs(grp) do
  v.address = v.address - 0x4
  v.flags = gg.TYPE_DWORD
  end
gg.loadResults(grp)
gg.searchPointer(0)
local t = gg.getResults(gg.getResultsCount())
for i, v in ipairs(t) do
  v.address = v.address - 0xC
  v.flags = gg.TYPE_FLOAT
 end
gg.loadResults(t)

 

  • 0
Posted
9 hours ago, nok1a said:

Your script can not be same because your using different group search, and where you found your group search the structure is different. You only have to do one time a pointer search and your not using any values to filter out irrelevant results. You can remove most of the lines from it, here some example based on your group search and pointer you when't to.

gg.setRanges(gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC)
gg.searchNumber("17D;1,075,642,368D;1,900,544D;1,310,728D;589,828D;1,703,957D;1,703,969D;1,376,289D;1,920D;469,762,048D::185", gg.TYPE_DWORD)
gg.refineNumber("1,900,544", gg.TYPE_DWORD)
print("Group search: ", gg.getResultsCount())
local grp = gg.getResults(gg.getResultsCount())
for i, v in ipairs(grp) do
  v.address = v.address - 0x4
  v.flags = gg.TYPE_DWORD
  end
gg.loadResults(grp)
gg.searchPointer(0)
local t = gg.getResults(gg.getResultsCount())
for i, v in ipairs(t) do
  v.address = v.address - 0xC
  v.flags = gg.TYPE_FLOAT
 end
gg.loadResults(t)

 

Okay, I am starting to get it lol.  Let me squeeze my brain again today and see what I come up with. I really appreciate al your help my friend. 

  • 0
Posted
10 hours ago, nok1a said:

Your script can not be same because your using different group search, and where you found your group search the structure is different. You only have to do one time a pointer search and your not using any values to filter out irrelevant results. You can remove most of the lines from it, here some example based on your group search and pointer you when't to.

gg.setRanges(gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC)
gg.searchNumber("17D;1,075,642,368D;1,900,544D;1,310,728D;589,828D;1,703,957D;1,703,969D;1,376,289D;1,920D;469,762,048D::185", gg.TYPE_DWORD)
gg.refineNumber("1,900,544", gg.TYPE_DWORD)
print("Group search: ", gg.getResultsCount())
local grp = gg.getResults(gg.getResultsCount())
for i, v in ipairs(grp) do
  v.address = v.address - 0x4
  v.flags = gg.TYPE_DWORD
  end
gg.loadResults(grp)
gg.searchPointer(0)
local t = gg.getResults(gg.getResultsCount())
for i, v in ipairs(t) do
  v.address = v.address - 0xC
  v.flags = gg.TYPE_FLOAT
 end
gg.loadResults(t)

 

By the way you didn't answer me on this question from the previous page:

When I run your script and get the health value, shouldn't I theoretically be able to go to the nearest pointer, which is 4 bytes above your health value and click "go to pointer" and find that block that you used for your group search? I mean since they are static they should appear on my device too just like they did on your 2 devices, right? Well I went up and down the list and I didn't find that block of numbers.   

  • 0
Posted
1 hour ago, Sami1982 said:

By the way you didn't answer me on this question from the previous page:

When I run your script and get the health value, shouldn't I theoretically be able to go to the nearest pointer, which is 4 bytes above your health value and click "go to pointer" and find that block that you used for your group search? I mean since they are static they should appear on my device too just like they did on your 2 devices, right? Well I went up and down the list and I didn't find that block of numbers.   

Yeah you should. Are you sure you did it correctelly though. I performed pointer search more then once...so you have to use go to the pointer more then onces as well in order to get to the groups search.

  • 0
Posted
1 hour ago, nok1a said:

Yeah you should. Are you sure you did it correctelly though. I performed pointer search more then once...so you have to use go to the pointer more then onces as well in order to get to the groups search.

Okay let's see if I can figure out where I am going wrong.  I ran your script and got your health value. Then I also ran your group search. Here is your group search results. All addresses start with "B431FBxx" 

 

capture11.thumb.jpg.054bfe0c382ea9239cd87bdd43b7b156.jpg

 

Next, I press on your health value from the saved area, and I press GOTO

capture9.thumb.jpg.96949d8aa543a65b40682b6885254d1f.jpg

 

Then I press on the address which is 4 bytes above it "AC0912E8" and I chose "Goto pointer"

capture10.thumb.jpg.19c18da294597a49720dda0acdce446d.jpg

capture8.thumb.jpg.b95ef32a6d1be78cea5b26e6205a08d9.jpg

 

I arrive at this list and I scoured the entire list (up and down) and I can't find your block of your group search whose addresses should start with "B431FBxx"  😞  What am I doing wrong? 

 

Capture7.thumb.jpg.520db3c5d44a88a5770b31ccb6623a6e.jpg

  • 0
Posted (edited)
2 hours ago, nok1a said:

Yeah you should. Are you sure you did it correctelly though. I performed pointer search more then once...so you have to use go to the pointer more then onces as well in order to get to the groups search.

Okay okay I finally got it!  You dug into deeper pointer "layers" in order to fine tune your group search and make it more accurate, which in turn resulted in needing that third "extra" pointer search while backtracking to find the health value.  Makes perfect sense!  LOL  

OMG bro you are amazing! You've literally taught me from scratch a skill I never had.  I will be forever in your debt man!

Edited by Sami1982
  • 0
Posted (edited)
21 minutes ago, Sami1982 said:

Okay okay I finally got it!  You dug into deeper pointer "layers" in order to fine tune your group search and make it more accurate, which in turn resulted in needing that third "extra" pointer search while backtracking to find the health value.  Makes perfect sense!  LOL  

OMG bro you are amazing! You've literally taught me from scratch a skill I never had.  I will be forever in your debt man!

That's right. I also didn't knew about pointers first. Actually this whole GG pointer thing didn't make sense because i didn't knew what where hex, bytes and bits...should have stayed in school longer to get some basics...So i totally get you...it's a pain to come in without knowledge 😕 about all this...Was watching some YT tutorials about how or what are bits and bytes and it helped me. Then after some time i understand addresses in memory a little and then pointer concept from a GG point of view made more sense. But also importantly the members in this forum contribute to making it more easy for people like us to understand something which is most likely alien language for us. There is lot's of things to learn i guess. We can use GG and the forum and other sources to learn more.

Edited by nok1a
  • 0
Posted
5 minutes ago, nok1a said:

That's right. I also didn't knew about pointers first. Actually this whole GG pointer thing didn't make sense because i didn't knew what where hex, bytes and bits...should have stayed in school longer to get some basics...So i totally get you...it's a pain to come in without knowledge 😕 about all this...Was watching some YT tutorials about how or what are bits and bytes and it helped me. Then after some time i understand addresses in memory a little and then pointer concept from a GG point of view made more sense. But also importantly the members in this forum contribute to making it more easy for people like us to understand something which is most likely alien language for us. There is lot's of things to learn i guess. We can use GG and the forum and other sources to learn more.

You nailed it right on the head. My feeling exactly. This forum is so rich and if we just use youtube and google, we feel a scarcity in information and knowledge 👍

  • 0
Posted (edited)
6 hours ago, nok1a said:

That's right. I also didn't knew about pointers first. Actually this whole GG pointer thing didn't make sense because i didn't knew what where hex, bytes and bits...should have stayed in school longer to get some basics...So i totally get you...it's a pain to come in without knowledge 😕 about all this...Was watching some YT tutorials about how or what are bits and bytes and it helped me. Then after some time i understand addresses in memory a little and then pointer concept from a GG point of view made more sense. But also importantly the members in this forum contribute to making it more easy for people like us to understand something which is most likely alien language for us. There is lot's of things to learn i guess. We can use GG and the forum and other sources to learn more.

This should absolutely be the last time I bother you LOL.  I got my own nice accurate group search now. And I almost have it down perfectly but I am stuck on the part where I can filter out the remaining addresses to only have 1 address left. I saw a "256D" value 8 bytes down from the pointer.  So I tried to do what you did with that "1.0F" value to filter them out but it's not working. I've been racking my brain until I got a headache LOL.  In this video the script gets me halfway through to the health value, and the remaining part I did manually. Could you help me bridge the gap in the script to get to the health value?  Here is the script I am using:

gg.setRanges(gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC)
gg.searchNumber("-1,049,624,576A;1,092,616,192A;1,082,130,432A;1,056,964,608A;1,062,333,317A::73", gg.TYPE_DWORD)
gg.refineNumber("-1,049,624,576A", gg.TYPE_DWORD)
print("Group search: ", gg.getResultsCount())
local grp = gg.getResults(1)
gg.loadResults({{address = grp[1].address - 0x88, flags = gg.TYPE_DWORD}})
gg.searchPointer(0)
local t = gg.getResults(gg.getResultsCount())
print("First Pointer search: ", gg.getResultsCount())
local t = gg.getResults(gg.getResultsCount())
local sensitivity = {}
for i, v in ipairs(t) do
  sensitivity[i] = {address = v.address - 0x8, flags = gg.TYPE_FLOAT}
end
sensitivity = gg.getValues(sensitivity)
local healthPointer = {}
for i = 1, #sensitivity do
  if sensitivity[i].value == "256" then
    healthPointer[i] = {address = t[i].address, flags = gg.TYPE_DWORD}
  end
end

 

You are almost finished with me I PROMISE 😆😂

Edited by Sami1982
  • 0
Posted
56 minutes ago, Sami1982 said:

I saw a "256D" value 8 bytes down from the pointer.  So I tried to do what you did with that "1.0F" value to filter them out but it's not working. I've been racking my brain until I got a headache LOL.  In this video the script gets me halfway through to the health value, and the remaining part I did manually. Could you help me bridge the gap in the script to get to the health value?  Here is the script I am using:

local t = gg.getResults(gg.getResultsCount())
local sensitivity = {}
for i, v in ipairs(t) do
  sensitivity[i] = {address = v.address - 0x8, flags = gg.TYPE_FLOAT}
end
sensitivity = gg.getValues(sensitivity)

 

Your offset is + 0x8 of the pointer, not - 0x8.

Also i not know if you saw but the memory region in which your value 256 was located was in region anonymous. So make your pointer searching more accurate by specifying the correct regions when needed...if you where sharing the scripts with multiple people i can understand you use multiple regions. But in this case it's for personal use i guess? See here the regions you can use.

1 hour ago, Sami1982 said:

 

sensitivity = gg.getValues(sensitivity)
local healthPointer = {}
for i = 1, #sensitivity do
  if sensitivity[i].value == "256" then
    healthPointer[i] = {address = t[i].address, flags = gg.TYPE_DWORD}
  end
end

When comparing two values they must be of same type as mentioned. You comparing a number type and a string type here.

 

1 hour ago, Sami1982 said:

 

gg.setRanges(gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC)
gg.searchNumber("-1,049,624,576A;1,092,616,192A;1,082,130,432A;1,056,964,608A;1,062,333,317A::73", gg.TYPE_DWORD)
gg.refineNumber("-1,049,624,576A", gg.TYPE_DWORD)
print("Group search: ", gg.getResultsCount())
local grp = gg.getResults(1)

 

If all the values are in dword no need to use "A" in front of each number. It slowers the search. It's better use the correct data type for each value or just remove the data type of each value and give them all same data type using gg.TYPE_DWORD. You will prevent issues by doing so. As mentioned here. The choice is up to you.

  • 0
Posted
8 minutes ago, nok1a said:

Your offset is + 0x8 of the pointer, not - 0x8.

Also i not know if you saw but the memory region in which your value 256 was located was in region anonymous. So make your pointer searching more accurate by specifying the correct regions when needed...if you where sharing the scripts with multiple people i can understand you use multiple regions. But in this case it's for personal use i guess? See here the regions you can use.

When comparing two values they must be of same type as mentioned. You comparing a number type and a string type here.

 

If all the values are in dword no need to use "A" in front of each number. It slowers the search. It's better use the correct data type for each value or just remove the data type of each value and give them all same data type using gg.TYPE_DWORD. You will prevent issues by doing so. As mentioned here. The choice is up to you.

Yes it's for personal use. I have specified 3 regions:

gg.REGION_ANONYMOUS | gg.REGION_C_BSS | gg.REGION_C_ALLOC)

 

Yes the value "256" is in REGION_ANONYMOUS. Isn't this okay?

12 minutes ago, nok1a said:

Your offset is + 0x8 of the pointer, not - 0x8.

Also i not know if you saw but the memory region in which your value 256 was located was in region anonymous. So make your pointer searching more accurate by specifying the correct regions when needed...if you where sharing the scripts with multiple people i can understand you use multiple regions. But in this case it's for personal use i guess? See here the regions you can use.

When comparing two values they must be of same type as mentioned. You comparing a number type and a string type here.

 

If all the values are in dword no need to use "A" in front of each number. It slowers the search. It's better use the correct data type for each value or just remove the data type of each value and give them all same data type using gg.TYPE_DWORD. You will prevent issues by doing so. As mentioned here. The choice is up to you.

Okay even when I fixed it to + 0x8 I still got the same exact thing as in the video.

  • 0
Posted (edited)
17 minutes ago, nok1a said:

Your offset is + 0x8 of the pointer, not - 0x8.

Also i not know if you saw but the memory region in which your value 256 was located was in region anonymous. So make your pointer searching more accurate by specifying the correct regions when needed...if you where sharing the scripts with multiple people i can understand you use multiple regions. But in this case it's for personal use i guess? See here the regions you can use.

When comparing two values they must be of same type as mentioned. You comparing a number type and a string type here.

 

If all the values are in dword no need to use "A" in front of each number. It slowers the search. It's better use the correct data type for each value or just remove the data type of each value and give them all same data type using gg.TYPE_DWORD. You will prevent issues by doing so. As mentioned here. The choice is up to you.

I also removed the quotes around 256 

so now it's like this:

if sensitivity[i].value == 256 then

but I still just get the same 3 results as show in the video. 

Edited by Sami1982
  • 0
Posted
16 minutes ago, Sami1982 said:

I also removed the quotes around 256 

so now it's like this:

if sensitivity[i].value == 256 then

but I still just get the same 3 results as show in the video. 

Yeah when using searchPointer() you have to specify the regions before you load the results in the result list. The regions at the first line should be the region where you try finding your group search, but i am not sure if your group search is always in the same region. Then when pointer searching you have to only specify the region where the pointer is which i think was region Ca or A.

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.