Changing String length in a C++ Executable's Combo Boxes

[zerohp]

Hi, I apologize in advance if I've posted this in the wrong place, plus I'm a newbie so please spare me some punishment regarding the following.

I want to modify an executable that uses combo boxes for several hundred strings.

I have no source, and when you use a resource editor only dialogs appear.

I've been told this program's combo boxes use a tricky string structure.

Since hex edit seems to be my only option at this point, I change the current text while leaving null(00?) characters alone.

The null character data position can't be changed and they signify the start of the next string.

Due to being only able to edit original text, I also have to keep the original string lengths.

My modifications then have to be cut short or waste space if I used less characters.

How do I modify these lengths to my liking? I also hope to remove unused strings.

Edit: A sample of the program can be found on the sixth post.

Edited November 23, 2010 by zerohp

[ghandi]

This only applies to strings shorter than the one it is replacing, to go the other way you would have to relocate the entire string table to accomodate the new bytes OR modify the strings in the resources (i'm assuming they are in a table which is stored in the resource section, if not i'm right off track here...) in whatever way you find most suitable.

If the NULL byte signs the end of the string/ beginning of next string, could you remove the 'left over' bytes between strings?

IE:

X = New string

Y = 'Left over' chars

Z = Next string

Before removal:

XXXXXXXXXX0YYYYYYY0ZZZZZZZZZZZZZZZZ0

After removal:

XXXXXXXXXX0ZZZZZZZZZZZZZZZZ0

This way the NULL byte would still sign the eos/sof.

HR,

Ghandi

[zerohp]

This only applies to strings shorter than the one it is replacing, to go the other way you would have to relocate the entire string table to accomodate the new bytes OR modify the strings in the resources (i'm assuming they are in a table which is stored in the resource section, if not i'm right off track here...) in whatever way you find most suitable.

I'm guessing I may have to relocate since a previous version seemed to have a modification like this, and had no length issues. I'm not quite sure what you mean by resources, since I'm guessing the pure data can be called that. I know resource editors show Dialogs, Version, Manifest, String tables(?), and etc, but any form of the "pure data" and tables don't appear.

If the NULL byte signs the end of the string/ beginning of next string, could you remove the 'left over' bytes between strings?

IE:

X = New string

Y = 'Left over' chars

Z = Next string

Before removal:

XXXXXXXXXX0YYYYYYY0ZZZZZZZZZZZZZZZZ0

After removal:

XXXXXXXXXX0ZZZZZZZZZZZZZZZZ0

This way the NULL byte would still sign the eos/sof.

HR,

Ghandi

No, but I have to null leftovers sometimes. Some code will look at a string position and take the entire string length if leftover characters aren't nulled.

Ex: String is "Concentration" -> Modified to "One           " (One with 10 spaces)
The code normally uses the string then adds text: ConcentrationExample -> Modified: One          Example -> Spaces nulled: OneExample

I'm forced to keep the position of the starter null bytes. Ex: Original0Inputted0Lengths0Created0Randomly0 -> First0000Second000Third000Fourth00Fifth0000

If I try "First0Second0Third0Fourth0Fifth0" the First is shown fine, but second through fourth get entirely lost. Fifth replaces the fourth entry because the null starter position matches.

Original null starter positions: 0 9 18 26 34 -> Modified: 0 6 13 19 26 | Sacrificing a string entry to make the previous one longer works, but I won't do that.

[atom0s]

The strings might be read into an array rather then read specifically during runtime. Meaning any alterations you are making are creating more strings when read in.

Such as:

First0Second0Third0

The program then reads this looping in each string upto the null char so:

Strings[0] = First

Strings[1] = Second

Strings[2] = Third

Then your alterations may be causing this:

Fir000Secon00Third0

Strings[0] = Fir

Strings[1] = 0

Strings[2] = 0

Strings[3] = Secon

Strings[4] = 0

Strings[5] = Third

Another option to correctly adjusting this if the program does read the strings like this would be to allocate a new block of memory holding the modified strings in a correct manner and point the application to read the new block of strings rather then the old one. Just an idea.

[ghandi]

I thought of the same thing as i read the OP's response, i also thought that if the dev used a multi-dimensional array then the elements could all be a set size but the OP stated that the NULL signified the EOS so i discarded that idea.

The only problem i can see with allocating memory (or even statically relocating the strings) is that the structure/layout needs to be understood before it can be copied. It would probably be preferable to modify the strings in their current position but if that is not possible then relocation will be necessary, either way the structure/layout still needs to be understood.

HR,

Ghandi

Edited November 21, 2010 by ghandi

[zerohp]

The strings might be read into an array rather then read specifically during runtime. Meaning any alterations you are making are creating more strings when read in.

Nah each string has a value used by the code. The amount of strings are set, so if I sacrifice one as I mentioned before, you'll just be unable to use that value.

If you try more than one string/null between the original null positions, only the first will be usable and take on a value.

Probably won't clarify anything, but the program is a save file editor for a game. I'll upload a sample of it if needed I guess.

Another option to correctly adjusting this if the program does read the strings like this would be to allocate a new block of memory holding the modified strings in a correct manner and point the application to read the new block of strings rather then the old one. Just an idea.

I'm all ears for whatever can let me change the pointers(starter null?) of each string. The program has about 20 "string sets" that are listed after each other, with some that are unused.

In my previous post I mentioned someone successfully changed the pointers of each of these sets in a previous version. He didn't have to deal with string lengths.

If I try to hex edit his modification, it will act the same as the original regarding his new lengths.

I thought of the same thing as i read the OP's response, i also thought that if the dev used a multi-dimensional array then the elements could all be a set size but the OP stated that the NULL signified the EOS so i discarded that idea.

The only problem i can see with allocating memory (or even statically relocating the strings) is that the structure/layout needs to be understood before it can be copied. It would probably be preferable to modify the strings in their current position but if that is not possible then relocation will be necessary, either way the structure/layout still needs to be understood.

HR,

Ghandi

Sounds like it is a multi-dimensional array. My hex edits are probably quite improper regarding nulls etc, but I'm fine as long as it still functions.

Seems like I should do that sample upload. I'll try to have it ready soon.

Edit: I was actually hex editing the program while it was a WIP. The dev added new strings to a set, and there was surplus nulls after some strings.

He got rid of them later so I had to redo my edits due to the new lengths since they lacked the surplus. All strings now have one null separating.

Edit 2: Added the sample. Changing A values activate the "I" combo boxes. I nulled out strings I didn't label, but they still appear as a blank entry.

Combo box order is by how "string sets" appear in a hex editor. F uses multiple "sets" which is why it has two letters. You have to scroll F and G due to blanks.

E, H, and "I" have edit boxes on their left. "I" involves 9 combo boxes, and J is on the left instead. Increasing edit boxes changes the combo string if it isn't blank.

The sample literally is the program I've been modifying, I just removed some dialogs and nulled out unneeded text. I simplified dialog 7 to just have the boxes.

Some of the labeled strings already need a character increase: A005(2) A006(2) A009(1), A586(1), D004(I used D4), IB set(2), II set(3), IJ set is just "I"(4), etc.

You can see things I noted in a hex editor. "U.S2-5" is "unused sets 2-5" while "NotIn" and "Other(on) Dial Stuff" means not used by dialog 7.

tutsforya.zip

Edited November 22, 2010 by zerohp