Binaries typically only store one base pointer to one string and reference the others via offset. This makes it indistinguishable from non-string data, so objects get created like this (MKW PAL as an example):
lbl_802A12F0 = .data:0x802A12F0; // type:object size:0x58
While the data stored looks like:
"NETHMACInit"
"%s(%d):[warning in %s]"
"specified interface needs too large workmemory."
This is a very minor example, but the current workflow I've developed for resolving these is really inefficient. I have to manually find the length of the string + the null terminating byte and change the size of the string manually. Then, I have two options: wait 10 seconds for DTK to generate a new block with a different address (which still isn't split up, just slightly smaller), or create a new object on a new line manually. Then, repeat until the string block is resolved. This doesn't matter with groups of 3 strings. It matters with groups of 50. vabold/mkw@14a9666
My proposed solution is to allow users to mark these blocks as data:stringblock (or data:wstringblock for wide strings). The core loop is that DTK will walk along the start of the pointer until it finds the null terminator, saves it as a string object, walks along null bytes until it finds the start of the next string (due to string alignment), and repeats the process until reaching the start of the next object.
Binaries typically only store one base pointer to one string and reference the others via offset. This makes it indistinguishable from non-string data, so objects get created like this (MKW PAL as an example):
lbl_802A12F0 = .data:0x802A12F0; // type:object size:0x58While the data stored looks like:
This is a very minor example, but the current workflow I've developed for resolving these is really inefficient. I have to manually find the length of the string + the null terminating byte and change the size of the string manually. Then, I have two options: wait 10 seconds for DTK to generate a new block with a different address (which still isn't split up, just slightly smaller), or create a new object on a new line manually. Then, repeat until the string block is resolved. This doesn't matter with groups of 3 strings. It matters with groups of 50. vabold/mkw@14a9666
My proposed solution is to allow users to mark these blocks as
data:stringblock(ordata:wstringblockfor wide strings). The core loop is that DTK will walk along the start of the pointer until it finds the null terminator, saves it as a string object, walks along null bytes until it finds the start of the next string (due to string alignment), and repeats the process until reaching the start of the next object.