The worst, but really really rare case, would be for the tool to create damaged binary. But I'm doing a lot of checks to avoid that. And you already stumbled upon some of the checks:
The tool does a lot of checks and raises exceptions if anything looks out of the ordinary. The exceptions are then captured and the block which raised them is exported as a binary file, without trying to make it XML. In case of VICD you'll actually always see this, as I didn't published parsing of the data. This means the VICD will just always stay as binary.
If you want to be sure the data is identical to source, just go with:
./readRSRC.py -vv -x -i ./lv10/vi.lib/dex/DexPropertyNode.vi
./readRSRC.py -vv -c -m ./DexPropertyNode.xml
cmp -l ./lv10/vi.lib/dex/DexPropertyNode.vi ./DexPropertyNode.vi
In other words - export the file, then re-create the binary without changes, and compare both binaries.
The tool checks whether it can re-create the checksum from your file - after all, it always tries to re-create identical data after export and import. Brute-force scan will happen only on damaged files - where the checksum doesn't match using the usual algorithm. The tool then assumes the issue is in salt. If the tool can't figure out how to re-create the salt used for password, it will export the salt into XML, and won't re-compute it when re-creating binary (unless you modify the XML to re-enable auto-computation).
The tool will re-create everything correctly, if only you will modify it in exported form.
I could add an option which would make it assume the input file is damaged, and skip that scan.
Well, you could use the same code which handles "change password", only replace password work with your fun.
But the way to rename blocks using my work model is:
1. Export VI to XML
2. Change the tag name in XML, for example replace "<CLIv>" and "</CLIv>" with "<LIvi>" and "</LIvi>".
3. Re-build the VI from XML
Yes, block idents are just the tag names; they are only a bit modified to meet XML standard, ie. "#" are replaced by "sh" and "\0" codes are just skipped; but the tool will re-create the 4-char ident from tag name during import.
I see. Yeah, there's no way around that.