This is an urgent update that fixes a couple of bugs in the user-defined-encoding-sequence feature that was introduced in version 5.4.
The first bug was reported by @fancy__04 and it would cause a valid encoding sequence defined by the user in Manual mode to be considered as invalid, thus making this feature unusable from this operation mode. The second bug, was discovered while I was testing the fix for the first one, and this is really ‘nasty’.

The encoding operator for XOR was defined as ‘^’ which was ok when testing this feature through visual studio with command line arguments. However, when using this character directly from the command line, then it would be ignored by Windows command prompt as this is a special character…of course. Shame on me!

This could potentially have a very big impact against the efficiency of this new feature. If for example you specified ––encode {+^-} from the command line,  the ‘^’ would be ignored and you would end up with the following sequence –encode {+-} which of course using two operators that neutralize each other in sequence would basically cause you to inject an non-encoded payload…which in turn would most likely cause some extra AV detections.
The encoding operator for XOR is now defined as ‘x’.

So, 1000 thanks fly out at fancy__04, not just because he immediately reported the first issue, but also because thanks to that I managed to find the other one which is even more critical.

Cheers,
kyREcon