Thu May 01, 2014 12:50 am by rohare
Zamok, good work on reading the EEPROM data. It is exactly what I would expect to see. Are you trying to figure out the code to the lock or do you already have it?
The data is not in a human-readable format so the method I would use to reverse engineer this is to program the code to 1-1-1 and then read the EEPROM, then program the code to 2-2-2 and read it again. Then compare the two readings. You might have to do this several times with different codes, but then you would know which memory locations are being used to store the key presses. You might even have to do something like program 1-2-3, then 4-5-6, then 7-8-9, and then something with a 0 in it so that you can see what each key looks like in memory. Just because the button says "1" on the keypad doesn't mean that the engineers programmed it to store a "1" in memory. The keypad "1" might be stored as "03 FF" or something just as impossible to guess. Another possibility is that when you program a combination in, it passes through a mathematical scheme that scrambles the data and outputs something that looks like garbage. This is called "hashing". You will be able to tell if the chip is doing this with the following experiment: Program the code to 1-1-1 and read the output. Now program in 2-2-2 and read it again. Then program in 1-2-1 and read it a third time. If there is no hash, then the first and third reading will be identical except for one spot which will instead look like the second reading. If there is a hash, all three readings will not have any apparent relationship to one another.
Of course, none of that will work if you don't already have the code. If you don't have the code then I would attempt to input every possible code which uses the numbers 3, 5, and 2. If you look at the data you got, there are only three numbers small enough to be normal digits less than 10. If we assume that the engineers simply translated the button "1" as a 1 in memory and the button "2" as a 2 in memory, etc. then those will be the numbers. I wouldn't get too exited right away because this is unlikely, but worth trying. Post back and let me know how it goes!
One more thing, you can ignore this if you already know how it works, but I'm not sure how knowledgable you are in the subject of computer science so I'll mention it. The data you are looking at is in the "hexadecimal" numbering scheme. It is just like normal decimal counting, but instead of starting at 0 and stopping at 9, it starts at 0 and stops at "F" which represents the number 15. It is numbered like so: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F (16 total digits). When you go past F, you get 10, then 11, 12, etc. This is convenient for programmers because computers store data in bytes of 8 bits and two bytes makes 16 bits. Therefore a single hexadecimal digit 0-F can represent 2 bytes worth of stored data (16 bits). Two digits 00-FF can represent 4 bytes of data (32 bits). When you read all the different memory locations, the output is represented in hexadecimal in order to make it smaller, and, if you know how, easier to read. Take the data you get from any reading and paste it into a hex editor program. There are dozens of good hex editors around. This will allow you to see that data in various different representations. It will show it to you in ASCII text format, as decimal numbers, or as any of a great many other possible things the hexadecimal numbers might be representing. I have a free hex editor on Mac OS X called "0xED" that will show me what any combination of hex numbers represents as a decimal number, a character string, a floating point number, binary, RGB color, etc. I put through the reading you posted and looked at it from a few angles, but didn't find anything that looked useful. It's always good practice to check though.
Good Luck!
