I hacked the Skreem, the Skreemulator
not really. he means that there will be no led neither display because is not needed. just the module that goes inside the ECU.
But I have to solve some challenges (mostly the code for the program) before I can verify if the theoretic idea works like expected. Some of this challenges sounds trivial but I haven't done this so far and have trouble with it. E. g. the reading and writing to a ST95P08 EEPROM. This EEPROM works over SPI (not IC2 like mine) and I have problems to get it working on an Arduino.
So if anyone can help me with the code and has a solution he is welcome to help me.
this car, as many others, is designed to be protected from theft by incorporating a device called immobilizer (aka skreem) that prevents to be stolen by immobilizing the car if some1 unauthorized tries to steal it. no start.
problem is, that this device began to fail with no way to prevent it. no clues nothing. just suddenly you find yourself midway to nowhere unable to start.
and this has been reason of concern by many of us.
there are some (SOS, Precision ECU) that offer solving the problem by you sending the immobilizer and the ECU and they return them with the problem solved. the car starts the way it is expected to do so (but may fail again).
Precision ECU also offers to bypass ( eliminate, delete) it. which prevents this to happen again, but leaves no protection against theft.
all of these by means of programming.
there is also here Andre (viper 666), that is working on the idea of doing this by designing a circuit that is soldered to the ECU. this is another possibility. and we all wish to him success.
this is as far as i see it.
if some1 knows of other sources, please bring them to the table.
http://sosdiagnostics.com/crossfire.html
https://www.ebay.ca/itm/2004-2008-Ch...gAAOSw791ebTCR
problem is, that this device began to fail with no way to prevent it. no clues nothing. just suddenly you find yourself midway to nowhere unable to start.
and this has been reason of concern by many of us.
there are some (SOS, Precision ECU) that offer solving the problem by you sending the immobilizer and the ECU and they return them with the problem solved. the car starts the way it is expected to do so (but may fail again).
Precision ECU also offers to bypass ( eliminate, delete) it. which prevents this to happen again, but leaves no protection against theft.
all of these by means of programming.
there is also here Andre (viper 666), that is working on the idea of doing this by designing a circuit that is soldered to the ECU. this is another possibility. and we all wish to him success.
this is as far as i see it.
if some1 knows of other sources, please bring them to the table.
http://sosdiagnostics.com/crossfire.html
https://www.ebay.ca/itm/2004-2008-Ch...gAAOSw791ebTCR
Last edited by phil alvirez; Mar 23, 2020 at 05:40 PM.
I think that the hands down winner will be the cheapest and easiest solution just so long as it is reliable.
The car can easily be disabled just by interrupting a wire somewhere with a switch in it. In the days of yore a switch in the low tension wire to the coil was enough, you just hid the switch. Cheap and cheerful, you just had to remember where the switch was, a potential thief may get the car hot wired but it will not run.
I still like to use the fob though.Scrambling around under the hood switching fuses is no fun.
The car can easily be disabled just by interrupting a wire somewhere with a switch in it. In the days of yore a switch in the low tension wire to the coil was enough, you just hid the switch. Cheap and cheerful, you just had to remember where the switch was, a potential thief may get the car hot wired but it will not run.
I still like to use the fob though.Scrambling around under the hood switching fuses is no fun.
So if you achieve find a way to operate the central locking system with your SKREEMulator, we can implement a fully integrated Keyless Entry System and finally get rid of the discontinued and costly MB-Chrysler Keys.
At this point we could incorporate a push-to-start functionality, since we wouldn't need the key anymore.
So if you achieve find a way to operate the central locking system with your SKREEMulator, we can implement a fully integrated Keyless Entry System and finally get rid of the discontinued and costly MB-Chrysler Keys.
So if you achieve find a way to operate the central locking system with your SKREEMulator, we can implement a fully integrated Keyless Entry System and finally get rid of the discontinued and costly MB-Chrysler Keys.
So I can't say for sure that opening and closing the Crossfire will work with my solution.
But a start button would be possible.
I have also come a step further. I managed to read and write the EEPROM ST95P08 with my Arduino yesterday.
This was a difficult goal for me, I hope that I now only have little problems in the Arduino program to solve.
Unfortunately my wife has planned me for the coming weekend for renovation work, so I probably won't be able to do much.
whenever, Andre. nobody has come so close to solve this puzzle, neither is so open, so willing to share your experiences. and so polite and understanding.
keep doing whatever you can, whenever you can. i am confident that, being so well prepared and determined, you will find the solution.
keep doing whatever you can, whenever you can. i am confident that, being so well prepared and determined, you will find the solution.
By the way I got a Crossfire at home, some Arduino Boards and an ODBII connection too.
If you need some help I'll be glad to give you a hand, mainly because here in Mexico these types of parts are non-existent and I would not like to keep my crossfire as a 3,000lbs paperweight when my SKREEM dies.
Maybe I could help with the central locking reverse engineering; I have wide laboral experience programing in low-and-high-level programming, and laboral experience developing serial interfaces (including encoding and decoding packets for those).
By the way I got a Crossfire at home, some Arduino Boards and an ODBII connection too.
If you need some help I'll be glad to give you a hand, mainly because here in Mexico these types of parts are non-existent and I would not like to keep my crossfire as a 3,000lbs paperweight when my SKREEM dies.
By the way I got a Crossfire at home, some Arduino Boards and an ODBII connection too.
If you need some help I'll be glad to give you a hand, mainly because here in Mexico these types of parts are non-existent and I would not like to keep my crossfire as a 3,000lbs paperweight when my SKREEM dies.
I haven't a clue as to what all these men are saying, but I'm sure glad they are saying it. It sounds like some very strong minds are going to work this problem out for all of us. If there is such a thing as a cheering section for these men, I'm in! Keep up what seems like great work guy's, you have a lot of support out here, I'm sure.
Jim
Jim
Maybe I could help with the central locking reverse engineering; I have wide laboral experience programing in low-and-high-level programming, and laboral experience developing serial interfaces (including encoding and decoding packets for those).
By the way I got a Crossfire at home, some Arduino Boards and an ODBII connection too.
If you need some help I'll be glad to give you a hand, mainly because here in Mexico these types of parts are non-existent and I would not like to keep my crossfire as a 3,000lbs paperweight when my SKREEM dies.
By the way I got a Crossfire at home, some Arduino Boards and an ODBII connection too.
If you need some help I'll be glad to give you a hand, mainly because here in Mexico these types of parts are non-existent and I would not like to keep my crossfire as a 3,000lbs paperweight when my SKREEM dies.
The BCM is responsible for controlling the central locking pump in the trunk via CAN (unfortunately not the same CAN as the skreem to the PCM).
There is a connector in the passenger footwell behind the cover where the amplifier or the transmission control unit is located where this serial cable can be easily tapped.
This plug is also a potential source of error if the Crossfire can't be opened with the remote control (I already had a Crossfire with this problem).
You wouldn't even need to decode these signals, just record them (1x for open and 1x for close) and you can try reproduce them with an Arduino.
I would have no idea how to do that with the Arduino. But it works, the SPI and I2C protocol shows what the Arduino can do that.
In the picture the arrow points to the connector, is a connector with if I remember correctly only one cable.
Last edited by Viper-666; Mar 20, 2020 at 03:23 AM.
we know that the immobilizer can be deleted. the statement by Precision ECU tells that they already do it.
it is done:
"This, immobilizer delete service will delete the immobilizer (SKREEM) function in the ECM making it functional without immobilizer (SKREEM) input.The ECM will be Plug n' Drive and will require no additional programming. Original and any keys will work. Simply install the ECU and start the car. For this service, you will have to send in the ECM (original or replacement) and SKREEM module. " (and, by the way, nobody else provides so much detail on what and how they do what they do-and nobody else claims that can delete it)
so, if they already are doing it, means that there is a way.
it is a matter of time that fellows like Andre will learn how to do it, be same way as Precision ECU is doing, or other way.
so it is not a matter of if, but when.
https://www.ebay.ca/itm/2004-2008-Ch...gAAOSw791ebTCR
it is done:
"This, immobilizer delete service will delete the immobilizer (SKREEM) function in the ECM making it functional without immobilizer (SKREEM) input.The ECM will be Plug n' Drive and will require no additional programming. Original and any keys will work. Simply install the ECU and start the car. For this service, you will have to send in the ECM (original or replacement) and SKREEM module. " (and, by the way, nobody else provides so much detail on what and how they do what they do-and nobody else claims that can delete it)
so, if they already are doing it, means that there is a way.
it is a matter of time that fellows like Andre will learn how to do it, be same way as Precision ECU is doing, or other way.
so it is not a matter of if, but when.
https://www.ebay.ca/itm/2004-2008-Ch...gAAOSw791ebTCR
to delete-or not
if we dont have a problem but want to delete the immobilizer, we have to consider the alternatives:
1-to have it deleted by Precision ECU;
2-to buy the module from Andre (whenever ready) and solder it-or send to be soldered.
(in both cases, we have to remove both parts and ship-and get them back and install)
perhaps what makes the difference is:
1- if we are willing to solder or send to be soldered, and:
2- if this means considerable savings.
of course, we may decide the easy way: to do nothing-even at risk of having a sudden failure.
your choice.
if we dont have a problem but want to delete the immobilizer, we have to consider the alternatives:
1-to have it deleted by Precision ECU;
2-to buy the module from Andre (whenever ready) and solder it-or send to be soldered.
(in both cases, we have to remove both parts and ship-and get them back and install)
perhaps what makes the difference is:
1- if we are willing to solder or send to be soldered, and:
2- if this means considerable savings.
of course, we may decide the easy way: to do nothing-even at risk of having a sudden failure.
your choice.
Thanks for the great offer. I'm happy to accept it, there is a cable that goes from the skreem to the bcm through which serial data is transferred.
The BCM is responsible for controlling the central locking pump in the trunk via CAN (unfortunately not the same CAN as the skreem to the PCM).
There is a connector in the passenger footwell behind the cover where the amplifier or the transmission control unit is located where this serial cable can be easily tapped.
This plug is also a potential source of error if the Crossfire can't be opened with the remote control (I already had a Crossfire with this problem).
You wouldn't even need to decode these signals, just record them (1x for open and 1x for close) and you can try reproduce them with an Arduino.
I would have no idea how to do that with the Arduino. But it works, the SPI and I2C protocol shows what the Arduino can do that.
In the picture the arrow points to the connector, is a connector with if I remember correctly only one cable.
The BCM is responsible for controlling the central locking pump in the trunk via CAN (unfortunately not the same CAN as the skreem to the PCM).
There is a connector in the passenger footwell behind the cover where the amplifier or the transmission control unit is located where this serial cable can be easily tapped.
This plug is also a potential source of error if the Crossfire can't be opened with the remote control (I already had a Crossfire with this problem).
You wouldn't even need to decode these signals, just record them (1x for open and 1x for close) and you can try reproduce them with an Arduino.
I would have no idea how to do that with the Arduino. But it works, the SPI and I2C protocol shows what the Arduino can do that.
In the picture the arrow points to the connector, is a connector with if I remember correctly only one cable.
I'll try it out this weekend and share the results.
By the way, what do you mean with source of error?, I'm asking because of my remote got broken and I use the key to open and close the car, would it be a problem with the tests?
But this has nothing to do with a broken remote. In your case... if you can record the signal who goes from the skreem to the bcm and can reproduce this with a arduino, you have solved your problem too
EDIT: I see I haven't understand your question right. If your Crossfire opens all doors and the trunk when you open and close it with the key this should work too. What also works is the switch in the middle console with the key on it.
Last edited by Viper-666; Mar 21, 2020 at 02:52 PM.
Small setback, what worked well on the breadboard with the reading and writing of the eeprom does not work with the eeprom of the PCM.
Some values were randomly written but not all. Since my programmer can write to the soldered eeprom of the pcm it works somehow.
I have to play a little with the parameters.
I will keep you up to date.
Take care of you and stay healthy.
Some values were randomly written but not all. Since my programmer can write to the soldered eeprom of the pcm it works somehow.
I have to play a little with the parameters.
I will keep you up to date.
Take care of you and stay healthy.
I'm two steps ahead.
First, I probably managed to find the right parameters for the EEPROM.
Probably because I could read plausible values but I could not write. Since my programmer can't write to this EEPROM either, it is defective and I had to exchange it for another one.
Unfortunately I don't have the right EEPROM and because of its age it is very difficult to get it. I have ordered some in China and it will take 4-6 weeks until they are here and until then I can only continue testing with a similar EEPROM.
Second, today I was able to prove that the Immobilizer off hack generally works.
But I still have to do some hardware and software development.
Take care of you and stay healthy.
First, I probably managed to find the right parameters for the EEPROM.
Probably because I could read plausible values but I could not write. Since my programmer can't write to this EEPROM either, it is defective and I had to exchange it for another one.
Unfortunately I don't have the right EEPROM and because of its age it is very difficult to get it. I have ordered some in China and it will take 4-6 weeks until they are here and until then I can only continue testing with a similar EEPROM.
Second, today I was able to prove that the Immobilizer off hack generally works.
But I still have to do some hardware and software development.
Take care of you and stay healthy.
I have not attempted to do what you have, but have relevant experience with vehicle CAN bus hacking. I have built a CAN emulator/translator for one of my other Chryslers, to allow a late model SATNav radio to work in a non-CANBus vehicle. I used a Teensy 3.2 (Arduino from PJRC), which has an on board CAN protocol bus. Also, I use your identical OLED. It is indeed dimable, with the right code. Will be glad to help.
I'm still working on it, even if I haven't posted an update for a long time.
But at the moment it takes a bit longer to get the necessary hardware, so I often have to wait for parts and can't make any progress in this time. This slowes my development down...
But if this new way is a dead end and I go back to my first version, what since month and about 300 starts works fine in my Crossfire, I will be happy if you could help me.


