Understanding nibbles & encoding using owasp EnDe tool?

Question

I'm using owasp EnDe web-based tool to understand nibbles and encoding in general. This online utility in my knowledge is the best free resource avaiable for anyone who is interested to learn encoding techniques.

I'm testing a sample input which is abcdwxyz.

Now, the results of encoding it based upon first nibble and second nibble is given as 36,1,36,2,36,3,36,4,37,7,37,8,37,9,37,A and 6,31,6,32,6,33,6,34,7,37,7,38,7,39,7,61 respectively.

A simple representation in hex of above sample input is 61 62 63 64 77 78 79 7a .

Can someone explain how it relates to the use in this tool?

For those who are interested in download owasp live cd here is the link http://appseclive.org/content/downloads

UPDATE

With some help from guys at stackexchange sisters I'm able to figured out the messy stuff. The whole encoding works like this.

Actually i was confusing in nibble 1 and nibble 2 definition in the tool. In theory nibble 1 should refer to high nibble and nibble 2 as low nibble. I was just confused in the use of nibbles format in the tool.

Now consider this. enDe tool takes entire set (abcdwxyz) and convert it into now the tools converts it like this 36,1,36,2,36,3,36,4,37,7,37,8,37,9,37,A based upon following logic.

For string (abcd) it writes as 36,1,36,2,36,3,36,4 by picking on e.g

'a' -> hex (61) -> chr(36) At the end appending 1 on left side as 36,1

Now, when i choose nibble 2 it translates abcdwxyz as 'a' -> hex (61) -> chr(31) At the end appending 1 on left side as 6,31

Now, two things to notice here is that in nibble 1 (encoding) msb(6) is used to get hex equivalent 36 for nibble 2 encoding lsb(1) is used to get hex equivalent 31 appending lsb before result (6,31). I'm still little confused about the use and placement of nibbles I hope someone in here would take time to comment and explain more.

I hope this explanation others to understand the use of such useful tool and a little a feedback on this little research from the site gurus would be a plus too:)

Answer 1

Although your question is far from clear, what apparently happens in your encodings is rather simple to unravel. See your example string abcdwxyz. When encoding in ASCII, this yields 8 bytes, with hexadecimal values: 61 62 63 64 77 78 79 7a.

Now, for each byte, take the left hexadecimal digit: it is a character which itself has an ASCII code, which can be represented in hexadecimal. For instance, 61 begins with 6 and the ASCII code for the character 6 is 54 -- that's 36 in hexadecimal. On the other hand, you can take the right hexadecimal digit, which represents a numerical value between 0 and 15, and represent that value as an hexadecimal digit (using digits 0 to 9 and letters A to F). In other words, you keep the right digit unchanged, except that you possibly normalize it to uppercase.

If you apply these rules, then 61 becomes 36,1, 62 becomes 36,2, and so on... up to 7a which becomes 37,A. And you end up with your first "encoding".

If you do the same process, but reversing the roles of the left and right hexadecimal digits for each byte (i.e. you keep the left hex digit of each byte unchanged, and you convert the right hex digit to the hexadecimal representation of the ASCII value of its character), then you obtain your second "encoding": 61 becomes 6,31, 62 becomes 6,32... and 7a becomes 7,61 (the ASCII code for a is 97, aka 61 in hexadecimal).

For the life of me, I cannot fathom what possible use these "encodings" could have.