DosTips.com

Here the SO user showed me a not so well documented additional switch of the certutil -encodehex. So you can pass an additional number as a format flag. Here they are:

certutil -encodehex -f strings64.exe strings12.hex 12 - one line HEX value without spaces , columns ,addresses
certutil -encodehex -f strings64.exe strings5.hex 5 - without the addresses
certutil -encodehex -f strings64.exe strings2.hex 2 - pure binary - pointless according to me.
certutil -encodehex -f strings64.exe strings1.hex 1 - base64 without certificate headers
certutil -encodehex -f strings64.exe strings0.hex 0 - base64 with certificate headers
certutil -encodehex -f strings64.exe strings4.hex 4 - in columns with spaces , without the characters and the addresses
certutil -encodehex -f strings64.exe strings7.hex 7 - base64 - X509 without headers (slightly bigger than the normal b64)
certutil -encodehex -f strings64.exe strings8.hex 8 - base64 - x509 with headers

I think these are all. I (still) don't know how X509 can be decoded.

Wonderful - Thankyou

I just noticed that "certutil -encodehex -f strings64.exe strings8.hex 8" doesn't give "base64 - x509 with headers", but does the same as "number 4" ("in columns with spaces , without the characters and the addresses") at least on my win10.

penpen

I ran a bunch of tests on Windows 10 with various flavors of -encodehex, and here is what I found.

General notes

CERTUTIL has a surprisingly low limit to the size file it can encode/decode. I'm not sure about the exact value, but the encode limit is only in the tens of millions range.

CERTUTIL accepts both decimal and hex notation for the type argument, but not octal.
Hex values must be prefixed with 0x
Since octal is not recognized, it is safe to prefix any decimal value with zeros.

The type argument seems to be flag based, but in a very freaky, inscrutable way - the meaning of low bits changes depending on the value of other bits. but the top two high order bits have a constant meaning:

0x40000000 bit - The output is encoded on a single line, without any line terminator.
Depending on the format, the result may not be able to be decoded with CERTUTIL.
Documentation states this flag is not supported by XP.

0x80000000 bit - Use \n line terminators instead of \r\n
Note that CERTUTIL only accepts positive numbers, so the type value cannot be computed by SET /A, else it will be converted into a negative value.
It is best to specify a type with this flag using hex.

The 0x80000000 and 0x40000000 bits can be ORed with any of the values documented below.

Unless the 0x40000000 bit is set, any -encodehex result can be decoded using either -decode or -decodehex (whichever is appropriate).

Hex Formats

Generally, each line of output represents 16 bytes of input (except for the last line). The hex pairs are delimited by spaces, with two spaces between the 8th and 9th bytes.

If the 1 bit is set, then 3 spaces are appended to each line, followed by the ASCII string representation, with control codes and non-ASCII bytes represented as dots.

If the 2 bit is set, then the hex address is prepended. The address is always represented with at least 4 hex digits (possibly left 0 padded), and followed by a <TAB> character.

0x4 - Formatted hex only
0x5 - Formatted hex + trailing ASCII
0x8 - Formatted hex only (same as 0x4)
0xA - Formatted hex + prepended address
0xB - Formatted hex + prepended address + trailing ASCII
0xC - Raw hex on a single line, without any spaces between bytes (not supported by XP)

Base 64 formats

Generally all encodings are identical, with 64 bytes per line in the output, and = padding appended as needed, regardless which type is chosen. The only thing that changes is the format of the beginning/ending headers. The only exception is the undocumented 0xD type.

0x0 - Certificate headers
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

0x1 - No headers

0x3 - Request headers
-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----

0x6 - No headers (same as 0x1)

0x7 - No headers (same as 0x1)

0x9 - X.509 CRL headers. Note that no encryption is done, it simply changes the header.
-----BEGIN X509 CRL-----
-----END X509 CRL-----

0xD - No headers, base64url format
Index 62 is represented as - (dash) instead of +
Index 63 is represented as _ (underscore) instead of /
No = padding at the end


Dave Benham

dbenham wrote: ↑

03 Sep 2018 10:55

CERTUTIL has a surprisingly low limit to the size file it can encode/decode. I'm not sure about the exact value, but the encode limit is only in the tens of millions range.

Through trial and error, I've determined that the limit is 74472684 bytes. I'm guessing that there's an output file size threshold of 100000000 bytes.

ShadowThief wrote: ↑

03 Sep 2018 19:42

dbenham wrote: ↑

03 Sep 2018 10:55

CERTUTIL has a surprisingly low limit to the size file it can encode/decode. I'm not sure about the exact value, but the encode limit is only in the tens of millions range.

Through trial and error, I've determined that the limit is 74472684 bytes. I'm guessing that there's an output file size threshold of 100000000 bytes.

I thought I remember reading somewhere it was roughly 75MB.

It's possible that your mileage may vary, but I don't know why it would.

ShadowThief wrote: ↑

03 Sep 2018 22:20

It's possible that your mileage may vary, but I don't know why it would.

Mine varied

I tried to use encodehex instead of encode, and it failed well before 74 MB,

I've posted a convenient HEXDUMP.BAT utility that utilizes these "new" CERTUTIL -encodeHex formatting options at viewtopic.php?f=3&t=8816


Dave Benham

dbenham wrote: ↑

03 Sep 2018 23:24

ShadowThief wrote: ↑

03 Sep 2018 22:20

It's possible that your mileage may vary, but I don't know why it would.

Mine varied

I tried to use encodehex instead of encode, and it failed well before 74 MB,

Indeed. It seems that the limit for encodehex is 21510272 bytes.

downloading files with certutil is no more possible:
As certutil has access to sensitive directories it was able to download (and overwrite) files in system directories this way of downloading is now taken as thread:

Threat detected: Trojan:Win32/Ceprolad.A
Alert level: Severe

Though I think is still possible to be used for bad things with -decode or -decodehex and with a file downloaded with CURL or BitsAdmin.

There´s indeed a file size limit and I have verified that.

On Windows 7 Ultimate SP1 X64 (fully patched) AND Windows 10 Pro v.2004 the size limit is: 51199999 which is ~50 MB.

A single extra byte and you get the error. This either a limitation of the API used to encode the files or an operating system issue or an architecture (x86 VS x64) issue.

Any of you remember the good old days of Windows XP 32bits ? ... If you were to install it on a machine with 4GB of RAM memory, it would only be able to read up to ~3GB of RAM. (Just an example)

The simplest workaround to this issue is create a script that verifies the size of the file you want to HEX encode, and split it into 51199999 parts:

file.txt.1
file.txt.2
file.txt.3

and so on... then encode each part separetedly and respectively and save them into memory or temporary files, then join them in the respective order and finally save the HEX encoded data to a single file. The bigger the file the longer you will wait. And on older machines it could be a real pain to encode and decode the files.

Notice that HEX encoding data produces an encoded data with double of the size. So a 4 bytes file, upon encoded will be 8 bytes. no big deal, right...but imagine a 2 GB ISO image for example.

That´s why Base64 is the way to go and most apps, including in the web, will be able to convert to and from. It produces files considerably smaller compared to HEX (which is "Base16" .

Regarding some arguments being flagged as malicious by antimalware, this is because some people do nasty things with legitimate features, like eg. using to download malicious files and overwrite local files, encapsulate malicious binaries into script based files like .BAT / .CMD

I remember an old tool that would "convert" an EXE to BAT file by converting the bytes into HEX and writing to the batch script (text based file) and then using a builtin DOS program (mode.com ??? ) to re-assemble the code back to an EXE that would be extracted anywhere and run.

dbenham wrote: ↑

03 Sep 2018 10:55

CERTUTIL has a surprisingly low limit to the size file it can encode/decode. I'm not sure about the exact value, but the encode limit is only in the tens of millions range.

The file size limitation seems not to be bound on the input file but on both input and output files, or to the internal en-/decoding process itself.

For instance, I had no problem to convert a 50 MiB file to a plain hexadecimal stream: In contrast to that, I failed in coverting a file of half that size to a full hexadecimal table: As soon as I further reduce the file size to about 20 MiB, conversion to a full hex table succeeds: I hate this limit!

Yes, it is frustrating when something has the potential to be extremely useful in a general sense, but then has a limitation that interferes with achieving the full potential.