Hello there,
Don't you hate when the lib.so has scrambled all the offsets after that 0.0.1 version upgrade because you're 99% sure the distance between the previous offsets and the new ones is the same, yet you're forced to use the slow IDA to find the new offsets all again?
Well, fret not because I'm sharing this self made program in C, that allows group offset calculation. This way, while IDA is disassembling that lib.so, you can at least try to take the shortcut, because if it succeeds, you may have saved yourself several idle minutes waiting for IDA to reach the that group of offsets you're interested on.
The process is simple:
For this tutorial:
Let's assume in previous modded version, we had 4 moddable offsets. We write them in file offsetorig.dad file (we can use tabulations or space to separate them).
We know from the dump.cs or the string search option in IDA, that the offsets we could easily locate were 3400 and 5c84 (We will call them Reference Offsets).
We also know which moddable offsets are related to each reference one.
We assume first two are related to 3400 and the last 2 are related to 5c84 (we keep those who share the same reference offsets together).
With the new version, we quickly obtain that these same functions, were moved respectively to 6794 and 1420. (3400 moved to 6794 and 5c84 moved to 1420).
So, we start using our calculator:
At the beginning, it will ask how many reference offsets we have. Then, it will proceed to ask us for how many offsets are linked to the 1st reference offsetwe will introduce.
Once we fill in those offsets, it will proceed to ask the same values for the second reference offset. This, until the n-th introduced reference offset. (we will be remainded which reference offset is it asking for).
After everything is filled, it will create (or replace if it already exists) an output file called offstnew.dad, where we will find the new offsets.
Offsets related to the same reference will be printed together with gaps between different reference offset. Printing order is the same as the order that offsetorig.dad had.
Now, all that is needed is to try those new offsets. If it worked, well, you can start closing IDA and go do something else.
I'm uploading both the .exe and the offsetorig.dad in the same compressed file.
There's a chance internal byte distance might have changed, so this would be useless if that were the case and you would have to do the usual IDA stuff and wait for the slow disassemble.
Please, if you have any problem using this, notify in this thread. I've tested it myself with few irl cases (where byte distance was kept), and some test cases with random hex values and I haven't found any issue with it. However, increasing statistic sample is always welcomed.
Note: this is for those cases where you usually have a big enough list of offsets to mod; for 2 or 3, you can always use a calculator.
Don't you hate when the lib.so has scrambled all the offsets after that 0.0.1 version upgrade because you're 99% sure the distance between the previous offsets and the new ones is the same, yet you're forced to use the slow IDA to find the new offsets all again?
Well, fret not because I'm sharing this self made program in C, that allows group offset calculation. This way, while IDA is disassembling that lib.so, you can at least try to take the shortcut, because if it succeeds, you may have saved yourself several idle minutes waiting for IDA to reach the that group of offsets you're interested on.
The process is simple:
For this tutorial:
Let's assume in previous modded version, we had 4 moddable offsets. We write them in file offsetorig.dad file (we can use tabulations or space to separate them).
We know from the dump.cs or the string search option in IDA, that the offsets we could easily locate were 3400 and 5c84 (We will call them Reference Offsets).
We also know which moddable offsets are related to each reference one.
We assume first two are related to 3400 and the last 2 are related to 5c84 (we keep those who share the same reference offsets together).
With the new version, we quickly obtain that these same functions, were moved respectively to 6794 and 1420. (3400 moved to 6794 and 5c84 moved to 1420).
So, we start using our calculator:
At the beginning, it will ask how many reference offsets we have. Then, it will proceed to ask us for how many offsets are linked to the 1st reference offsetwe will introduce.
Once we fill in those offsets, it will proceed to ask the same values for the second reference offset. This, until the n-th introduced reference offset. (we will be remainded which reference offset is it asking for).
After everything is filled, it will create (or replace if it already exists) an output file called offstnew.dad, where we will find the new offsets.
Offsets related to the same reference will be printed together with gaps between different reference offset. Printing order is the same as the order that offsetorig.dad had.
Now, all that is needed is to try those new offsets. If it worked, well, you can start closing IDA and go do something else.
I'm uploading both the .exe and the offsetorig.dad in the same compressed file.
There's a chance internal byte distance might have changed, so this would be useless if that were the case and you would have to do the usual IDA stuff and wait for the slow disassemble.
Please, if you have any problem using this, notify in this thread. I've tested it myself with few irl cases (where byte distance was kept), and some test cases with random hex values and I haven't found any issue with it. However, increasing statistic sample is always welcomed.
Note: this is for those cases where you usually have a big enough list of offsets to mod; for 2 or 3, you can always use a calculator.
Last edited:
