How to clone a black remote fob ....

gobble,
I am new to the forum. I need a spare remote for my 360 (USA). Are you able to clone these, and if so, how can I get in touch with you to accomplish this? Thanks
svolk

 

Just shoot me a PM.

 

Dear Eric
I have a single black remote and I would like to have two copies can you do that ? Is it a safe thing to do or is there a risk ? Will it work ? I don't know the frequency can u figure it out ? Can you make an Enzo key cut as well ? I have to say I don't have remotes nor enzo key will you provide them? How much does it cost me to do so? How long does it take to do the job ?
Thanx

 

Go to post 252 about three above here - click on the username - a list should appear

The second instruction down is send a private message (pm) to (username) - a window will open - write message - press send

The reply will appear below your username in the top right of the screen - click on private messages

This is useful to know for communicating with members of any forum that you might join as the procedure is more or less always the same

 

Can you use it?
Did anyone use it?
Image Unavailable, Please Login

 

First time I have read through this thread, I read it end to end. Lots of noise in here too...

Some very good contributions (particularly from Eric355 and Gobble) but all we seem to have concentrated on thus so far is cloning the information in the EEPROM on the Key fob remote controls. There are MANY more other very useful projects which all use almost identical techniques as described in this thread. Mainly on the 'eeprom' cloning elements.

On the 'how do I work out the pin code bit?' question asked. Well one you've got a couple of different fob dumps its easy to use software on a PC to do a 'byte for byte difference report' - this should then show you where in the file the bytes differ allowing you to home in on the specific data thats changing. *(assuming no encryption is used, I'm guessing no on these very simple devices..)

Here are some scenario's which could quickly get expensive for all (or allow us to adapt our cars to either uprated parts or improved performance). Note you will need a few different eeprom programmers for all the different types of flash chips we are talking about here but the costs of buying these devices far outweigh the price of just one of these ecu's dying.

List of EEPROM backup/replace scenario's
*1. keyfobs lost (we've done this to death now..)
2. Immobilizer ecu dies. (not yet covered)
3. Re-programming Motronic ignition computers to match Immobilizers. (not yet covered)
4. Re-programming Motronic to bypass immobilizers (also possible, not covered).
5. Re-programming Motronic to remap to CS or custom spec power gain maps (also possible).
5. Re-programming the auxillary flash on the Motronic after its gone into brick mode after a error code.
5. Dashboard (main computer) dies (lost of mileage, no.of times the doors, engine lid have been open, top speed the cars been driven, times the engine's been started, etc. etc.). Big brother.... You may want to reset some of this snooping information.
6. F1 Transmission TCU dies or you want faster shifting (also done to death) but also setting the PIS value directly from the flash without an SDx...
7. ABS computer dies (or you switch to/from ccm's)
8. Suspension computer dies (or perhaps you want to re-calibrate stiffness to match your new uprated springs, e.g. HGTC handling upgrades.. ).
9. Airbag computer (back it up incase its triggered). E.g. a low speed impact and you need to reset the airbag computer to 'working' state again.

Its also interesting to note (as per the key fobs) that Bosch do indeed 'parts bin share' with other manufacturers like Ford, BMW, Fiat, Maserati', Porsche & Alfa Romeo so you can actually buy many of the said ecu's very very cheap on ebay for other cars, all they need is reprogramming with new data and they become Ferrari capable units. Very useful for backup purposes.

Anyone interested in a wider project? It could save the wider Ferrari community literally thousands of $ and allow us to do much more without being forced to go to dealers for silly stuff like setting up the PIS after a clutch change or when it feels slippy. In essence with an appropriate obd-ii lead and some software you could even go so far as to build an SDx equivalent (or dare I say it better it...).

The first tentative steps have already been done just by learning how to clone fobs via eeprom route.

 

Looking good. I totally get what your starting to do but I do worry about jumping the gun (trying to run before we can walk...) and going straight to sending OBD-II commands without first being able to 'clone' the ecu contents and understand all the individual data segments in all the various ecu's. Please take a look at my 'how to clone the immobilizer thread'. I'd love you to contribute.

I consider that there is still a heck of a lot of value being able to get cheap universal car fit Bosch components from ebay and then use the same parts with our backed up firmware's to make them work on our cars. Thus side stepping paying thousands if our hardware parts fail (which lets face it there is always an opportunity to happen on a 5+ years old electrical component).

I have already done some work on OBD-II but when you think about it, all its doing is sending commands which ultimately change eeprom values stored in the flash (eventually) so your limited really to what the commands allow. This means it only supports setting that they programmed into it to allow, not everything is upgradable and you cannot back every flash or eeprom up from that mechanism.

For example being able to play with the data segment in the TCU, allowing you to adjust the shift speed maps at will per gear. The TCU by the way I've already decomposed and documented all the chips and programmers.

For TCU stuff see;
http://www.ferrarichat.com/forum/showthread.php?t=239882

Its a Motorola MC680x0 assembly derivative so its an old friend. (in a former life I wrote 68k assembly for a decade so know that instruction set very very well... $4e75 anyone?

 

As a starter, those Bosch (Ignition) Motronic ME7.3's also have read/write eeprom chips.

On the older ME 7.3 (as used in the 360) they are 512 kbytes. An AMD AM29F400 chip which is 4Mbit (0.5 MByte).

Again rather useful to backup a fully working set of firmwares for the Motronics, Immobilizers and keyfobs that way you can always create a fully working set...

 

@ Eric355

Did you write raw protocol commands to address the different Motronics ?

Ie..

Let's assume you have a KWP2000 connection with your Bosch ECU.

Then let's go send these messages:

82 : 2 data bytes
01
F1
1A : ISO 14230-3 ReadECUIdentification
92 : systemSupplierSpecific
20 : CRC

The ECU should respond with

87 : 7 data bytes
F1
01
5A : ISO 14230-3 positive reply
92 : systemSupplierSpecific
VV
WW
XX
YY
ZZ
CS : CRC

Now compute the following

ecuid = (VV+WW+XX+YY+ZZ) & 0x3f

Then send:

82 : 2 data bytes
01
F1
27 : ISO 14230-3 SecurityAccessRequest
01 : Request Seed
9C : CRC

The ECU should respond with

86 :6 data bytes
01
F1
67 : ISO 14230-3 positive reply
01 : Request Seed
WW : Seed MSB
XX
YY
ZZ : Seed LSB
CS : CRC

Now compute the following

Seed = (WW<<24)+(XX<<16)+(YY<<8)+(ZZ)

unsigned int table[64] =
{
0x0A221289,0x144890A1,0x24212491,0x290A0285,
0x42145091,0x504822C1,0x0A24C4C1,0x14252229,
0x24250525,0x2510A491,0x28488863,0x29148885,
0x422184A5,0x49128521,0x50844A85,0x620CC211,
0x124452A9,0x18932251,0x2424A459,0x29149521,
0x42352621,0x4A512289,0x52A48911,0x11891475,
0x22346523,0x4A3118D1,0x64497111,0x0AE34529,
0x15398989,0x22324A67,0x2D12B489,0x132A4A75,
0x19B13469,0x25D2C453,0x4949349B,0x524E9259,
0x1964CA6B,0x24F5249B,0x28979175,0x352A5959,
0x3A391749,0x51D44EA9,0x564A4F25,0x6AD52649,
0x76493925,0x25DE52C9,0x332E9333,0x68D64997,
0x494947FB,0x33749ACF,0x5AD55B5D,0x7F272A4F,
0x35BD5B75,0x3F5AD55D,0x5B5B6DAD,0x6B5DAD6B,
0x75B57AD5,0x5DBAD56F,0x6DBF6AAD,0x75775EB5,
0x5AEDFED5,0x6B5F7DD5,0x6F757B6B,0x5FBD5DBD
};

for (int i=0; i<5; i++)
{
if ((seed & 0x80000000) == 0)
{
seed = (table[ecuid]) ^ (seed << 1);
}
else
{
seed = (seed << 1);
}
}


Then send:

88 : 8 data bytes
01
F1
27 : ISO 14230-3 SecurityAccessRequest
02 : Send Key
WW : (seed >> 24 ) & 0xff
XX : (seed >> 16 ) & 0xff
YY : (seed >> 8 ) & 0xff
ZZ : (seed ) & 0xff
00
00
CS : CRC

The ECU should respond with

83 : 3 data bytes
01
F1
67 : ISO 14230-3 positive reply
02 : Send Key
34 : Not sure what this means
12 : CRC

Secure access granted, now you can read/write anything (eeprom etc.)

 

(Sorry) going off topic I know...

 

I agree that to fully understand every element of whats going on you need to reverse it back to its atoms (well individual asm instructions at the least . However backing up the software is another matter. Its like your IT dept having a 'hard disc' backup of your pc which takes minutes to restore to a working state. Having even the knowledge, spare chips and tools to do this really does give enormous potential and power at your fingertips.

I'm not proposing a full reversing exercise but simply at this stage a backup/restore project. Just even doing diff's on these images will reveal the different data segments and whats stored in what area's.

 

For instance. With a full TCU eeprom backup of the full 256kbytes.

Backup TCU. Replace in car. Set PIS using an original SD2.
Remove TCU, backup again. Do a diff. Volia,

Congrats, you've just found the byte offset position of the PIS in the firmware. Now a simple hex edit of that byte allows you to create a tool to change the PIS.
If there are checksums that need fixing I can help with that bit too.

A very trivial bit of C code can show you the diff's between dumps. e.g. ;
---
unsigned chA,chB;
int count=0;
for(i=0;i<src1len;i++) {
chA = psrc1Buf;
chB = psrc2Buf;
if(chA != chB) { printf("0x%-8.8x (%8d): %2.2x -> %2.2x\n",i,i,chA,chB); count++; }
}
printf("\ntotal byte differences: %d (%x) bytes\n\n",count,count);
--

*Where psrc1buf is firmware image1 loaded into a buffer and psrc2buf is the firmware image 2. src1len is the original firmware size in bytes.

I can provide working version of this as an executable for either linux or windows. Shows you the byte differences in one binary file and another. Its really not rocket science. Just a very simple diff program (many available on the web, do a search.)...

 

And just to get this thread back on track again, if you use the same DIFF approach on the FOB firmware between 2 different images you'll know discover where the bytes differ in the file and know what byte offset to change to change to 'pair' it to the immobilizer...

 

I do agree with you, it is far easier to snoop on the CAN bus messages. Its just that also having a backup literally guarentee's you'll be able to do stuff the SD2 doesn't allow you to do and you and that too is also big plus point. I.e. being able to make one from an old selespeed tcu for very little cost or being able to adjust timing of shifts yourself while visiting a dyno. You can buy piggyback chips that allow 'on the fly' chip changes. great for dyno days

Your right about the variables, the operating hours variable is one of the parameters stored, etc.

I could not believe the amount of snooping the dashboard clocks do on the owner, even down to the number of times the doors or engine lid are opened/closed, even the cars vmax and on the tcu the number of individual gear changes done on the box...

 

Damn, Ferrarichat is going SLOW today. Alread responded to this and it got lost ;(

I'd love to see how these different bytes (the 180 bits you where talking about?) are mapped inside the immobilizer itself and at what byte offset?

I wonder if there is some sort of algorithm that combines both the bits and the serial number of the immobilizer itself (paired). I'd be interested in making the immobilizer data section go back to 'virgin' mode and forgot all registered key fobs (just like when you buy a new unit from Ferrari).

Also like to learn about doing the same thing on the igntion computers too so you can re-use old non virgin units cheaply with your existing car.

 

Trev- Eric and I thought we had a good start on picking the PIN out of the red fobs, but no luck so far.

Duram Plummer is building an SD substitute for Ferraris and the first issue will be for the 360. Price will be less than $2K. He also thinks in the future he will be able to provide a reflashing capability in a separate piece of software that will work through the OBDII connector. The hardware is there for doing that, but Ferrari did not implement it on the earlier cars.

Taz
Terry Phillips

 

Terry, thanks for the post.

It is good to know others are working on this too but why need any seperate hardware at all? Perhaps for convienience and packaging. Technically all you need is a simple PC USB lead to OBD-II cable and some custom (serial) software running on a laptop.

This software could be something as simple as simulating all the SD2 commands and slapping together a quick and dirty Visual Basic app to 'play' them back or something more cosmetically pleasing such as a touchscreen tablet pc running embedded linux and a full screen application connected to OpenGL ES for swishy 3d animated user interface . Most of the software has already been written to send the commands (standard protocol), thats where the freeware open source OpenOBD-II software comes in, its then just a case of working out all the Ferrari specific commands and how to send them to the appropriate CAN devices.

Hardware costs: OBD-II cables costs less than $100 for the basic option to a a laptop and circa $400-600 for a nice iTablet type device (plus software dev.) if you wanted to pursue that more professional path with no PC knowledge required at all an a slick user experience.

On the upgrade front, you can upgrade all model years of the 360's Bosch Monotronic ignition computers directly from OBD-II connector but you don't have OBD-II firmware upgrade built into the F1 TCU's until hardware revision 3 I think. From late 2001 onwards, perhaps 2002, cannot remember now.

Be nice if we can work out a simple software installable app (FREE) that people can download and install on their own pc then buy a cheap cable from ebay.

 

First of all, thanks to everyone on this board for all of the invaluable information!

Second, I just purchased a '99 360 Modena and am super excited!

Finally, I have one working red fob, no codes (the alarm system was changed at some point in the past), and 2 non-communicating fobs (red led works on fobs though)

If anyone here (U.S.) would be willing to help me clone the working fob to the other two I would be greatly appreciative and be happy to pay for their time and effort.

Thanks!!!!
-RHaque

PS - I wanted to contact "Gobble" but am unsure how to message members directly.