Analzying Cars Remote Key

I got an old remote key for my car which always breaks. My father is always fixing it, and I took the opportunity to take a picture of the circuit.

The large 20-pin chip is a COP processor. The small 8-pin chip is EEPROM.  From my understanding and reading in the internet: the COP cpu is the same for all the remotes, and the dynamic data like the serial key and encryption key is stored in the EEPROM. Connecting an arduino to the SPI bus between the COP and the EEPROM should reveal the data. Depending(?) on the fact the the COP uses KeeLoq algorithm and the cpu uses the data from the EEPROM as is, I should be able to open my car manually with a arduino connected to a 433MHZ transmitter. Using arduino logic analyzer project to capture the SPI bus and rf spectrum, I did my best but it didn't work. I can see nicely the RF signal which looks very similar to this KeeLoq signal I found in the internet (preamble, header, data):

mine:

microchip pdf:

but I see nothing on the SPI bus. My guess is the SPI bus voltage is too high (near the 6V), and the arduino can't handle this kind of voltage (5V max), so I need to get some level converter.

Then I found this article:
http://www.docstoc.com/docs/144155143/2000-2008-Toyota-Keyless-Entry-Programming-Guide
This is a technician manual which explain how you can get your car in learning mode, in this state the car will accept every remote. According to this guy it might not work on the israeli models, but they all agree that when the car is in learning mode pressing on both buttons on the remote will trigger the car computer to accept the key. In this process, the key must send its serial number and encryption key in order for the car to learn it, meaning sniffing the actual moment when I press both buttons should bring me the key.

Its not what I really expected..  I expected it to send much larger packet containing all the information.. but no :(

My next step is to write something that will analyze and decode the rf data. The data is probably encoded in manchester encoding instead of pwm mentioned in the microchip documentation.

After decoding the data I also need to understand if the communication is multi-packet.

And thats it for this post.. sorry I have no news for you guys :(