Make a custom unzized string type

[aldelaro5]

I am dealing with a binary that has its own string encoding. It's basically a sequence of 16 bits characters (but can also contain formatting information) and it ends with 2 bytes: the first is the length and the second is a terminator being 0x80.

Obviously, I would need to do some scripting for me to add a type such that ghidra can show me the string in a pretty way, but I would like to know how I could go about doing that? Ghidra's unsized types appears to be handled specifically for them (cause I can't create an unsized type).

[astrelsky]

Are you looking for them to be properly represented as a string in the decompiler or just in the listing? For the decompiler the short answer is you can't (as far as I know). I think you can in the listing with a DynamicDataType if there isn't a direct solution for a string. I don't have the documentation in front of me do take this loosely. You should be able to override the methods for getComponents and for getValue to achieve what you want. At least I think. If I can remember I'll take a look tonight if you don't get a response from someone who knows better.

[astrelsky]

I haven't checked yet. Will check in a few hours.

You would need to create an extension. The only requirements would be that your class implements DataTypeand has a name ending in DataType. It should only take me a few minutes to check the details of exactly what is needed to do. I will see if there is a better way though.

This will only make the string easier to make and see in the listing. The decompiler requests an "equivalent" c datatype from a DynamicDataType so I don't think there is a way to make it decompile as a string.

[aldelaro5]

I haven't checked yet. Will check in a few hours.

You would need to create an extension. The only requirements would be that your class implements DataTypeand has a name ending in DataType. It should only take me a few minutes to check the details of exactly what is needed to do. I will see if there is a better way though.

This will only make the string easier to make and see in the listing. The decompiler requests an "equivalent" c datatype from a DynamicDataType so I don't think there is a way to make it decompile as a string.

I am currently investigating on my own and it appears there's a better way, will make as answer once I fully figured this out, but here's what I got:

You want to extend AbstractStringDataType and override stuff like getting the length, getting the string value and getting the representation.

To make it lookupable and other stuff, you do the same thing with a custom StringDataInstance that just redirects the calls to the data type itself (which you receive in the constructor). Then, you just override the getStringDataInstance of the class you extended earlier.

I ended up discovering the way the class searcher works for the data types because I didn't even needed to add it manually.

No idea if this is the intended way to do this (cause this stuff is terribly documented), but at least I am getting results so far.

[astrelsky]

I was just doing this myself. It is a bit quirky though. The string value also does show up in the decompiler. It seems you only need to override getLength.

No idea if this is the intended way to do this (cause this stuff is terribly documented), but at least I am getting results so far.

I don't believe that is true.

[astrelsky]

I got it working. This example uses a 0xff terminator. When created in the listing it consumes the terminator but it is not part of the string as you would expect. If you expect these to always be constants I recommend overriding getDefaultSettings to have the mutability be constant by default. That will make them render as strings in the decompiler.

package cppclassanalyzer.graph;

import ghidra.docking.settings.Settings;
import ghidra.program.model.data.*;
import ghidra.program.model.mem.MemBuffer;
import ghidra.program.model.mem.MemoryAccessException;

public class CustomStringDataType extends AbstractStringDataType {

	public CustomStringDataType() {
		this(null);
	}

	public CustomStringDataType(DataTypeManager dtm) {
		super("CustomStringDataType", // data type name
			"myds", // mnemonic
			"MY_STRING", // default label
			"MYSTR", // default label prefix
			"mys", // default abbrev label prefix
			"String (Custom Terminated)", // description
			USE_CHARSET_DEF_DEFAULT, // charset
			CharDataType.dataType, // replacement data type
			StringLayoutEnum.FIXED_LEN, // StringLayoutEnum
			dtm// data type manager
		);
	}

	@Override
	public StringDataInstance getStringDataInstance(MemBuffer buf, Settings settings, int length) {
		// strip the terminator out of the string
		return super.getStringDataInstance(buf, settings, length - 1);
	}

	@Override
	public int getLength(MemBuffer buf, int maxLength) {
		try {
			if (maxLength < 0) {
				maxLength = Integer.MAX_VALUE;
			}
			for (int i = 0; i <= maxLength; i++) {
				if (buf.getUnsignedByte(i) == 0xff) {
					// include terminator for creation in listing
					return i + 1;
				}
			}
		} catch (MemoryAccessException e) {
			// End of valid memory or memory block
		}
		return -1;
	}

	@Override
	public DataType clone(DataTypeManager dtm) {
		if (dtm == getDataTypeManager()) {
			return this;
		}
		return new CustomStringDataType(dtm);
	}
}

[aldelaro5]

I was just doing this myself. It is a bit quirky though. The string value also does show up in the decompiler. It seems you only need to override getLength.

No idea if this is the intended way to do this (cause this stuff is terribly documented), but at least I am getting results so far.

I don't believe that is true.

well not in my case because the encoding isn't standard so I need to override other stuff like get value.

The reason I NEED to mess with the StringDataInstance is because the string table directly uses it instead of going through the DataType, but in my case, the DataType would know MORE than that.

Also yeah, your implementation was similar than mine so I'll call that an answer. I wish it was a bit easier to make this work tbh, but eh :)