Solved negative value on armv7

[kayro7]

helo guys, im sorry im newbie here about modding a game, and i just wanna ask about value on armv7, how to make values in game be negative like item price or something that we spend to increase not decrease, thanks in advance

 

[Yaskashije]

Due to how memory storage process works, a negative number like -1, is stored as the biggest value that could be stored (All bits being one: 1111...11111) minus the value you have in binary (in this case: 1111...11110) with some "bit check". That check will be called the sign.
A signed integer (or signed int) will work this way.

However, because of the fact you would never have negative currency, you use unsigned integers (uint) [Or developers shoud anyway]. This means you are removing that "bit check" I previously mentioned. This would mean any signed negative value would be accounted as a big number, thus, making it impossible to have negative prices you mention.
Also, the idea you propose would requiere two instructions instead of one. If you are tight into editing the function (you can only change one instruction or else it wont work/will crash the game), this would mean you won't be able to mod it.
(Maybe the game you're modding uses signed and that would work, but it's really unlikely.)



With this said,
You may try the following (everywhere):
>Locate the instruction that changes the value (usually SUB) and turn it into an ADD for increase or put there a func that will do nothing like NOP or CMP (Increasing your currency instead of decreasing it).
>Remove the check that would block the operation if you try to buy some that costs more than your actual currency value, thus allowing for "negative currency" (This would mean you would be able to spend without any restriction).
>Find the price storing instruction and make it store a low value or 0 (So no currency is consumed).

You may try the following (signed ints are on place and you have plenty space to spare):
>Locate the instruction that manages the price, and modify the following offsets into:
MOV Ra, #0 (get a 0 value)
SUB Rx, Ra, Rx (subtract that price value to 0, thus obtaining a signed negative value)
Where Ra is some registry you can freely use without crashing the game, and Rx is the registry that holds the price value.


Note:
This are just some ideas.
Game may be more complex and none of those ideas could actually work (or maybe it's server sided so you can't even modify them).

 

[mars12]

SUB Rx, Ra, Rx (subtract that price value to 0, thus obtaining a signed negative value) ?
are you sure? lol

 

[Yaskashije]

SUB Rx, Ra, Rx (subtract that price value to 0, thus obtaining a signed negative value) ?
are you sure? lol

Well, I'm pretty positive it would work like that with the assumption developers make the function work using signed integers (which is kinda unlikely).
If function is simple enough and you pretend using bx lr afterwards, then using SUB R0, Ra, Rx would work too.

I believe I haven't ever had the need to do this, so I can't say I'm sure 100%.

 

[kayro7]

thanks broo

 

[kayro7]

Due to how memory storage process works, a negative number like -1, is stored as the biggest value that could be stored (All bits being one: 1111...11111) minus the value you have in binary (in this case: 1111...11110) with some "bit check". That check will be called the sign.
A signed integer (or signed int) will work this way.

However, because of the fact you would never have negative currency, you use unsigned integers (uint) [Or developers shoud anyway]. This means you are removing that "bit check" I previously mentioned. This would mean any signed negative value would be accounted as a big number, thus, making it impossible to have negative prices you mention.
Also, the idea you propose would requiere two instructions instead of one. If you are tight into editing the function (you can only change one instruction or else it wont work/will crash the game), this would mean you won't be able to mod it.
(Maybe the game you're modding uses signed and that would work, but it's really unlikely.)



With this said,
You may try the following (everywhere):
>Locate the instruction that changes the value (usually SUB) and turn it into an ADD for increase or put there a func that will do nothing like NOP or CMP (Increasing your currency instead of decreasing it).
>Remove the check that would block the operation if you try to buy some that costs more than your actual currency value, thus allowing for "negative currency" (This would mean you would be able to spend without any restriction).
>Find the price storing instruction and make it store a low value or 0 (So no currency is consumed).

You may try the following (signed ints are on place and you have plenty space to spare):
>Locate the instruction that manages the price, and modify the following offsets into:
MOV Ra, #0 (get a 0 value)
SUB Rx, Ra, Rx (subtract that price value to 0, thus obtaining a signed negative value)
Where Ra is some registry you can freely use without crashing the game, and Rx is the registry that holds the price value.


Note:
This are just some ideas.
Game may be more complex and none of those ideas could actually work (or maybe it's server sided so you can't even modify them).

thanks broo

 

[G-Bo ッ]

Due to how memory storage process works, a negative number like -1, is stored as the biggest value that could be stored (All bits being one: 1111...11111) minus the value you have in binary (in this case: 1111...11110) with some "bit check". That check will be called the sign.
A signed integer (or signed int) will work this way.

However, because of the fact you would never have negative currency, you use unsigned integers (uint) [Or developers shoud anyway]. This means you are removing that "bit check" I previously mentioned. This would mean any signed negative value would be accounted as a big number, thus, making it impossible to have negative prices you mention.
Also, the idea you propose would requiere two instructions instead of one. If you are tight into editing the function (you can only change one instruction or else it wont work/will crash the game), this would mean you won't be able to mod it.
(Maybe the game you're modding uses signed and that would work, but it's really unlikely.)



With this said,
You may try the following (everywhere):
>Locate the instruction that changes the value (usually SUB) and turn it into an ADD for increase or put there a func that will do nothing like NOP or CMP (Increasing your currency instead of decreasing it).
>Remove the check that would block the operation if you try to buy some that costs more than your actual currency value, thus allowing for "negative currency" (This would mean you would be able to spend without any restriction).
>Find the price storing instruction and make it store a low value or 0 (So no currency is consumed).

You may try the following (signed ints are on place and you have plenty space to spare):
>Locate the instruction that manages the price, and modify the following offsets into:
MOV Ra, #0 (get a 0 value)
SUB Rx, Ra, Rx (subtract that price value to 0, thus obtaining a signed negative value)
Where Ra is some registry you can freely use without crashing the game, and Rx is the registry that holds the price value.


Note:
This are just some ideas.
Game may be more complex and none of those ideas could actually work (or maybe it's server sided so you can't even modify them).

Impressive answer my friend!

 

[kobina]

what if you have SUB w9, w9, w2 can't you change it to add w9, w9, w7 into hex editor after you put the binary into hex editor