3

I am attempting to follow this reply and change a few hex bytes in a file by using hexdump, xxd, and sed.

According to that response, after converting the CSR generated with keytool (which happens to be base-64 PEM format) into DER, I should be able to do a straight bytes replacement, replacing 0x13 with 0x0c.

Here is what I have attempted:

#convert csr pem to der
openssl req -in openfire.csr -outform der -out openfire_csr.der
cat openfire_csr.der | grep -aP '\x13' | md5sum
#e61387f5c1xxxxeb832df102524220d81  - #it has some length
#perform replacement of hex bytes:
sed 's/\x13/\x0c/g' openfire_csr.der
#convert csr der to csr pem:
openssl req -in openfire_csr.der -outform pem -out openfire_utf8.csr
#unable to load X509 request
#3078055660:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:698:Expecting: CERTIFICATE REQUEST

I suspect I'm missing some conversion, but I do not know where.

How do I perform byte replacement using available tools (like sed, xxd, and/or hexdump)?

Community
  • 1
  • 1
brandeded
  • 2,080
  • 6
  • 25
  • 52
  • I think I just realized how much lunacy it is to replace a hex byte in a cert globally. It will affect the entire certificate, and the output file will always been an invalid certificate. As explained in the reply linked above, I think conversion is only possible if you retrieve the byte offsets and perform a straight replacement _only at those byte offset_! – brandeded Nov 19 '13 at 20:51
  • 1
    The error you're getting is because you are sending in a DER formatted CSR. Either convert back to PEM, or add the argument `-inform DER`. That being said, I agree with your comment that it's probably not a good idea to globally replace a byte value in the certificate. In fact, I'm not sure it will work. CSRs are signed, and if you change the signed content, the CSR signature will not verify. – gtrig Nov 20 '13 at 02:13
  • Thanks gtrig. I'm much more okay with just using `-policy policy_anything` than hacking away at bits to conform to something that the CSR need not conform to. Too bad Oracle doesn't update `keytool` to export fields `UTF8STRING`, as `PRINTABLESTRINGS` is old school and depreciated. – brandeded Nov 20 '13 at 14:57
  • You may wish to consider [this answer](https://stackoverflow.com/questions/2604964/binary-sed-replacement#4999140) and question. – aghast Aug 26 '17 at 01:16

1 Answers1

2

From http://everydaywithlinux.blogspot.ca/2012/11/patch-strings-in-binary-files-with-sed.html:

So, you have a binary file that you need to patch. Perhaps it is a pre compiled proprietary program or dynamic library that contains hard coded paths (text strings) that you need to change.

If the file had been a text file, then sed would probably come to your rescue. For binary files there are hex editors available, but they require manual handling and can't be scripted. Other binary patch programs are out there as well but might not be packaged in your favorite distribution and compiling things from source is boring. You could also have the need to do the patching in a packaging stage when building say an RPM.

So, how can you use sed then?

Well, it's quite simple. Just convert the binary file to ASCII HEX with hexdump, patch it with sed and the convert it back to binary with xxd:

hexdump -ve '1/1 "%.2X"' file.bin | \
sed "s/<pattern>/<replacement>/g" | \
xxd -r -p > file.bin.patched

Of course there are caveats to this approach. The most significant one is that you can't replace a string with a string that is longer then the original one. Shorter is OK though. Another one is that the strings must be null terminated, but this is almost always the case. You also have to create and yourself as the ASCII HEX representations of the null terminated strings with their null terminator present. Further, must be padded to the same length as <pattern>.

Refer to this example

Community
  • 1
  • 1
constantlearner
  • 5,157
  • 7
  • 42
  • 64