Data Decryption - Small amount of Data

Closed Posted Jul 3, 2010 Paid on delivery
Closed Paid on delivery

I am looking for someone to decrypt a very small amount of data. I have several encrypted pieces of data that are encrypted using an unknown encryption type. I also know a portions of the decrypted data.

This data is stored on RFID tags attached to ink containers in a printing system. The data contains information such as Color, Expiration Date and Amount of ink pumped out of the ink container.

Here is what I have....

When the printer finishes a print, the system reads the data...

Command Sent to RFID Tag:

L3F:A00:RD

(L3F is the length - 3F or 63 Bytes of Data: A00 is the start address - 00 being the beginning: and RD is for Read Data)

Response from RFID Tag:

RD:B0A4778400000009F0FFFFFF00000000BB1FF750CE2D3B7E9BF33A3B7778F1B1F4A2DF43359A97672DAD37751026C88EBADF92C926584C2E01000000B7C018

The printer then changes 21 bytes of data (updates the ink usage data) and rewrites that 21 bytes back to the RFID tag starting at position 24 (the 36th byte) and continuing to the 56th byte.

Command Sent to RFID Tag:

A24:D72,63,00,00,29,0F,88,CC,09,DC,AF,EF,15,4B,5D,B1,A9,F1,E3,87,74:WR

(A24 is the start address - position 24 or the 36th Byte: D is followed by the actual data to be written - each byte separated by a comma: and WR for Write Data)

Response from RFID Tag:

WR:

It then reads the data again with the new 21 bytes of data (bytes 36 to 56 are now the new data that was written).

Command Sent to RFID Tag:

L3F:A00:RD

Response from RFID Tag:

RD:B0A4778400000009F0FFFFFF00000000BB1FF750CE2D3B7E9BF33A3B7778F1B1F4A2DF4372630000290F88CC09DCAFEF154B5DB1A9F1E38774000000B7C018

Another key piece of information is the serial number of the RFID Tag. The first 8 bytes (16 characters) of the response to the Read Data command are equal to the serial number of the RFID tag. (B0A4778400000009)

Therefore, all of the data is contained in the last 55 bytes of data.

If I use the following command to rewrite the original 21 bytes of data, the system is happy...

A24:D35,9A,97,67,2D,AD,37,75,10,26,C8,8E,BA,DF,92,C9,26,58,4C,2E,01:WR

and once again returns...

RD:B0A4778400000009F0FFFFFF00000000BB1FF750CE2D3B7E9BF33A3B7778F1B1F4A2DF43359A97672DAD37751026C88EBADF92C926584C2E01000000B7C018

...when sent the L3F:A00:RD command

The system now thinks that it has just as much ink in the container as it did before it finished the last print.

HOWEVER...if I write that same 21 bytes of data to an RFID Tag with a different serial number, the system returns INVALID DATA.

ALSO...if I write all 55 bytes of data after the serial number to an RFID tag with a different serial number, the system return INVALID DATA.

SO...my conclusion is that the serial number must somehow be contained in (or be used in decoding) the 21 bytes of data that gets rewritten.

The encoded data looks very much like hexadecimal data, but I cannot find any pattern (reverse order, every other character, every third character, etc) that can be converted to ASCII and produce readable text.

The 21 bytes of data DEFINATELY contains ink usage data somehow. This is the only data that is ever rewritten to the RFID tag by the printer, and eventually, the machine knows that the ink in the container has all been used.

But if I rewrite the original 21 bytes back where it belongs, the system is happy again and doesn't know that the ink has been used.

I also know that somewhere in the Full 63 byte data string (or I guess it's actually 55 bytes after you remove the 8 bytes for the serial number) is the color of the ink, along with the expiration date.

I don't know how either of these pieces of data are stored.

ie. The color of the ink container this particular RFID tag is attached to is Yellow.

However yellow could be stored in the string as "Yellow" or "Y" or ""yel" or "ylw" or "2" (yellow is always color 2 in this printer).

The expiration date is 01/2011 as reported by the printer.

However, this could be store in the string as "01/2011" or "01-2011" or "01/11" OR...

it may even contain the DAY of expiration like "01152011" or "01/23/11" or "30-Jan-2011" and the printer may ignore the DAY....

ALSO, the ink always has an expiration date 1 year from the manufacture date...and the printer knows that...so the data that is stored in the string may actually be the manufacture date (January of 2010) and the printer is calculating the expiration date.

What I need is for someone to decipher the data and get me the "plaintext" string of the entire 55 bytes, as well as tell me how to re-encode the plaintext to get back to this same 55 byte string that the printer understands.

I have data from other RFID tags (some the same color, some the same exp date, some completely different). I have attached a text file with data from other RFID tags as well. Please let me know ASAP if you can figure this out.

I am only willing to pay for this job COMPLETED. I am not willing to pay for someone to TRY and see if they can figure it out. You have enough information to determine if you can do this or not. If you can, place your bid with NO MILESTONES and send me a PM. DO NOT BID if you do not send me a PM confirming that you understand what I need done. You will be paid once you deliver the plaintext data as well as the procedure for re-encoding it and I confirm the process. If you have any questions, please PM me. I am straight by the book and I will not offer email, Chat ID, or phone number to contact me outside of Freelancer.com. I am an honest business person and I expect the same from service providers.

Thanks,

Ryan

Algorithm Cryptography

Project ID: #729375

About the project

Remote project Active Aug 7, 2010