Omega Owners Forum
Omega Help Area => Omega Electrical and Audio Help => Topic started by: Dave DND on 09 October 2008, 10:32:02
-
Said theory on hold after a chat with a certain member who knows more about such things than I do
In view of the number of people actively trying to crack this one from different directions, and to prevent me (and a few others) from having the same conversation with every OOF member regarding this, I suggest the following, I am more than happy to discuss this on the open forum and share any thoughts and information with others as I have not yet found an easy way to do this either. Somebody out there may trigger off some thoughts that could assist us all and save us all some time, by hitting the same brick wall every time.
If I could make one request though, could any actual data dumps, Hex memory locations and "sensitive" data be retricted to PM to those who have the technical knowledge and capabilities to interpret such data, and not offered out on the general forum for obvious reasons, but would encourage those to openly report back on any findings and theories.
I think you know what I am trying to say?
:-/
-
Split off to a new thread.
Your request sounds appropriate to me, esp considering it will always need specialist equipment and skills.
-
For those wanting to share memory dumps with me, please use this address to send them to.
technical@dndservices.co.uk
8-)
-
So then Mr TB.....I guess the next step is to start pulling some dumps from these various units we have floating around!
-
Said theory on hold after a chat with a certain member who knows more about such things than I do
In view of the number of people actively trying to crack this one from different directions, and to prevent me (and a few others) from having the same conversation with every OOF member regarding this, I suggest the following, I am more than happy to discuss this on the open forum and share any thoughts and information with others as I have not yet found an easy way to do this either. Somebody out there may trigger off some thoughts that could assist us all and save us all some time, by hitting the same brick wall every time.
If I could make one request though, could any actual data dumps, Hex memory locations and "sensitive" data be retricted to PM to those who have the technical knowledge and capabilities to interpret such data, and not offered out on the general forum for obvious reasons, but would encourage those to openly report back on any findings and theories.
I think you know what I am trying to say?
:-/
Not got a clue! :-? :-? :-? It all went waaay waaay over my head! ;D ;D ;D
-
The NCDC Code and CDC3 changer codes are different.
CDC3 Code fairly easy to spot, not encrypted !! But the code location is not actually used for the Non-Coded ones, there may be data in there, but it is not read nor used. The Code is simply "disabled" elsewhere in the dump on the Changer. For instance you could show code as 1234 and some external devices would require it, where the internal devices would not, but the code location may still show 1234. I do not see how knowing the code location or data within the CDC3 would help with the NCDC system for carrying out any other functions though, such as depairing etc?
The code information for the NCDC systems are found within the 24LC64 & 24LC16 devices on the main board of the NCDC unit (often contained within a 28C64 plcc28 processor), not in the changer, which by the way uses a standard 8 pin 24LC64 smd on the vertical pcb.
however, if you want to send me the dump from the vertical PCB from the changer, I am happy to read the CDC3 code data for you but as I said, I do not see how it actually will help to depair the head unit
-
Not got a clue! :-? :-? :-? It all went waaay waaay over my head! ;D ;D ;D
For those who are unawares of this problem. The NCDC range of radio`s and displays are electronically "paired/married" to a specific car by use of a tech2 programmer - and as such cannot be reprogrammed nor transferred to another vehicle unless they have gone through a Tech2 removal procedure rather than simply pulling them out. If they are simpley pulled out, the Tech2 programmers cannot reprogram them for use at all as they have not yet been depaired from the original vehicle.
As this makes virtually all secondhand radios and displays now scrap, with the exception of a few Oofers who are taking this to the next level regarding mixing and matching some incompatable units for clever features, the initial aim of this excercise is to find a way to depair a secondhand display or screen so that it can be used and reprogrammed into another vehicle once more.
did that make sense? :-/
-
......
did that make sense? :-/
Perectly clear that time! :y :y :y :y
-
The systems can be taken from one car to another without depairing, but only if kept together (radio and display). New configs can be put on all the devices via Tech2. But, all items must be kept together - you cannot change screen or headunit without the depairing process, which needs the original code it was paired with (which, for factory fit, should be the car immobilisr PIN).
What initiated this discussion is myself, with my NCDR1500/GID/Telematics/CDC3, wanting to upgrade to colour screen, and Marks DTM, with his NCDC2013/GID also wanting colour screen. But deeper than that, for me, is an understanding of how it all fits together.
I was hoping that all devices in NCDC setup would simply share the same code, and when queried by headunit at switch on would compare the HU code with their own. Then, by looking at eprom on CDC3 (easiest to get to), was hoping I could work see the code in there. With that, I could then depair the setup.
To help me achieve this, I have a spare depaired NCDC2013, and a depaired CID here that I can play about with, as they are mine. Aren't they Tunnie ;D. I also have a faulty CID belonging to user Weds, but that looks to have a couple of faults meaning it won't talk to tech2. Possibly also paired as well.
I know Marks DTM has a couple of bits, but unknown condition/state.
-
The systems can be taken from one car to another without depairing, but only if kept together (radio and display). New configs can be put on all the devices via Tech2. But, all items must be kept together - you cannot change screen or headunit without the depairing process, which needs the original code it was paired with (which, for factory fit, should be the car immobilisr PIN).
What initiated this discussion is myself, with my NCDR1500/GID/Telematics/CDC3, wanting to upgrade to colour screen, and Marks DTM, with his NCDC2013/GID also wanting colour screen. But deeper than that, for me, is an understanding of how it all fits together.
I was hoping that all devices in NCDC setup would simply share the same code, and when queried by headunit at switch on would compare the HU code with their own. Then, by looking at eprom on CDC3 (easiest to get to), was hoping I could work see the code in there. With that, I could then depair the setup.
To help me achieve this, I have a spare depaired NCDC2013, and a depaired CID here that I can play about with, as they are mine. Aren't they Tunnie ;D. I also have a faulty CID belonging to user Weds, but that looks to have a couple of faults meaning it won't talk to tech2. Possibly also paired as well.
I know Marks DTM has a couple of bits, but unknown condition/state.
And I must add, the initial idea of pulling code from CDC3 looks to be dead in the water, so we are on plan B ;D. Possibly. :-X
-
And I must add, the initial idea of pulling code from CDC3 looks to be dead in the water, so we are on plan B . Possibly.
whilst I agree strongly with that, it is something that should at least be explored to confirm this. This is the whole idea behind this thread - somebody has an idea but no knowlegde of how to proceed, whilst I personally have lots of technical gadgets and gizmo`s here, but little raw data to work with - which is why I want us to all work together.
Send me your CDC3 dump and I can extract the code for you - at least you can continue your own train of thought and let us know the findings.
;)
-
And I must add, the initial idea of pulling code from CDC3 looks to be dead in the water, so we are on plan B . Possibly.
whilst I agree strongly with that, it is something that should at least be explored to confirm this. This is the whole idea behind this thread - somebody has an idea but no knowlegde of how to proceed, whilst I personally have lots of technical gadgets and gizmo`s here, but little raw data to work with - which is why I want us to all work together.
Send me your CDC3 dump and I can extract the code for you - at least you can continue your own train of thought and let us know the findings.
;)
My own CDC board in 2013 is missing, but I hope to have a replacement tonight. That board is currently showing CDC SAFE in another radio, but it actually came from the 2013 I have.
Be interesting to see if it is CDC SAFE in its original unit :-/
-
Can the various PROMs be read in situ (by soldering wires from my pony prog (::)), or need to be removed first?
-
My own CDC board in 2013 is missing, but I hope to have a replacement tonight. That board is currently showing CDC SAFE in another radio, but it actually came from the 2013 I have.
Be interesting to see if it is CDC SAFE in its original unit
Back to top
Can we all please try to work with some known good working units, as all these faulty items are giving us inconsistant data !! The faults are masking the readings we are looking for.
:(
-
Can the various PROMs be read in situ (by soldering wires from my pony prog (::)), or need to be removed first?
To ensure a good clean read without any interference from the processor and external circuitry, it would be usefull to have the raw data from an IC that has first been removed.
After we have some clean data to work with, subsequent readings can be made in circuit, although you may find it more consistant with PonyProg to read and write out of circuit.
-
My own CDC board in 2013 is missing, but I hope to have a replacement tonight. That board is currently showing CDC SAFE in another radio, but it actually came from the 2013 I have.
Be interesting to see if it is CDC SAFE in its original unit
Back to top
Can we all please try to work with some known good working units, as all these faulty items are giving us inconsistant data !! The faults are masking the readings we are looking for.
:(
Yup, agreed. If this CDC board works in my 2013, it shows it is somehow coded to it. If thats the case, by pairing/depairing a few times with different codes and reading eprom in cdc board, we should get something interesting ;). Thats Plan A.
If it works, and I can do the pair/depair process, then that gives me a NCDC2013 (with CDC) and CID in delivery state (unpaired), which should provide a good basis for images, which somebody with the right equipment can utilise :-X. Thats Plan B.
Plans C,D,E still need to be thought up, and, like Dave DND, I am open to suggestions :y
-
Can the various PROMs be read in situ (by soldering wires from my pony prog (::)), or need to be removed first?
To ensure a good clean read without any interference from the processor and external circuitry, it would be usefull to have the raw data from an IC that has first been removed.
After we have some clean data to work with, subsequent readings can be made in circuit, although you may find it more consistant with PonyProg to read and write out of circuit.
Bugger - I've had around a 50% success rate of removing small serial eproms without breaking pins or cooking them. I do have a better iron now though, my £9.99 from craplins wasn't really up to the job ;D
-
As the code has to be verified between married units is it not possibe to interrogate the verification between the two units at power on via the can bus?
In simple terms can we decode by interrogating the can bus?
-
As the code has to be verified between married units is it not possibe to interrogate the verification between the two units at power on via the can bus?
In simple terms can we decode by interrogating the can bus?
Depends if we need to simply know the code, or to put it back into "delivery mode" I guess. I guess the bus between the units is likely to be encrypted in some way, as it's the obvious way to compromise it.
Sounds like I need to repair my Logic Analyser.
Kevin
-
As the code has to be verified between married units is it not possibe to interrogate the verification between the two units at power on via the can bus?
In simple terms can we decode by interrogating the can bus?
Depends if we need to simply know the code, or to put it back into "delivery mode" I guess. I guess the bus between the units is likely to be encrypted in some way, as it's the obvious way to compromise it.
Sounds like I need to repair my Logic Analyser.
Kevin
Ah....a logic analyser.
I was thinking a PIC, Can I/F chip and conncting to a PC USB port.....
But a logic analyser would be much easier!
-
As the code has to be verified between married units is it not possibe to interrogate the verification between the two units at power on via the can bus?
In simple terms can we decode by interrogating the can bus?
Depends if we need to simply know the code, or to put it back into "delivery mode" I guess. I guess the bus between the units is likely to be encrypted in some way, as it's the obvious way to compromise it.
Sounds like I need to repair my Logic Analyser.
Kevin
Ah....a logic analyser.
I was thinking a PIC, Can I/F chip and conncting to a PC USB port.....
But a logic analyser would be much easier!
It's not a great logic analyser (TEK 1240), but I'll renew my efforts to fix it if it's going to be useful. Failing that, I have a Megasquirt 2 which, IIRC, has a CAN interface. Would need a few lines of code to set it up and dump what it sees to the serial port but not a great deal of work.
Kevin
-
I was thinking:
a UM245R USB module from FTDI (USB to parralel convert module)
a PIC of some sort plus code
a MCP2551 microchip can interface chip.
Then connecting to a USB port to sniff......
-
Ow yes
I have a working CID
and a paired and working NCDC/GID.
-
As far as I can see, it is my understanding that Tech2 can perform a programmed subroutine program to write a code in a particular location to pair or unpair the unit, given that the data within the particular location is known, but if the data is not known, then the program will simply not run. (why Tech2 cannot retrospectively depair)
This means that Tech2 and subsequently any CAN interrogation are not directly reading the memory locations which is why we are all struggling. I do not think that the Code could actually be read by CAN intervention anyway. The CAN reads the data held elsewhere on the main processor, loaded from the Code eeprom as far as I can tell.
A few thoughts on how I could see us progressing forward.
It would prove usefull beyond anything else, is to depair a known good working NCDC and screen froma vehicle, and take a memory dump from them both. Reprogram them back to the car, and take a memory dump again. From that we can probably work out the data locations within the dump and this would then allow us to reprogram the data accordingly. From this we could potentially recover 99% of all secondhand units, providing of course that the data is only held within one component.
It would also prove usefull to exchange the code IC from a working head unit or screen into a "Secondhand" head unit or screen to see if they then power up correctly. This would then confirm that the codes are contained within a single component inside, and not held within multiple IC`s within a unit, as is becoming more commonplace.
Once that has been done, we can then look towards the possibility of reprograming the unit so that it would work in a new vehicle WITHOUT the need for Tech2 intervention at all.
-
Quick question, while were on this subject.
I have a NCDC2013 with a CID (paired) from a Vectra C, but dont have the Audio Pass or Log Book details as car was scrapped, can this still be depaired or Tech 2d?.
Sorry another one, will the above fit a Meg?, I know the screen is a diff size, but will the screen talk to Miggy MID interface?
NCDC should be fine but, the computer type functions etc are CAN based on the Vectra screen
-
From what I am thinking, the code must be passed across the CAN interface.
Cant think of any other way the setup could pair like it has.
-
Quick question, while were on this subject.
I have a NCDC2013 with a CID (paired) from a Vectra C, but dont have the Audio Pass or Log Book details as car was scrapped, can this still be depaired or Tech 2d?.
Sorry another one, will the above fit a Meg?, I know the screen is a diff size, but will the screen talk to Miggy MID interface?
NCDC should be fine but, the computer type functions etc are CAN based on the Vectra screen
[/highlight]
How did that get there?, I never wrote that (Highlighted)?
-
I think it depends on what happens via CAN. Some negotiation obviously happens at startup to determine if the devices are paired. If this were a straightforward exhange of the codes this would tell us all we need to know. I suspect it'll be a challenge and response based on the codes but without revealing the code itself.
Decoding the EEPROM contents is useful inasfar as we could determine how to place an item in delivery mode but only by gaining physical access to the EEPROM - perhaps by exchanging it for a "de-paired" one, or perhaps by programming it in-situ to revert it to the de-paired state. Tech 2 would obviously still be required to pair it again.
If our goal is also to eliminate the Tech 2 from the equation we surely need to know how the Tech 2 codes the unit to take it out of delivery mode so we can do this by alternative means, or we need to disable the protection in the firmware of the unit(s).
I was thinking:
a UM245R USB module from FTDI (USB to parralel convert module)
a PIC of some sort plus code
a MCP2551 microchip can interface chip.
Then connecting to a USB port to sniff......
Sounds good. I will have to get myself back up to date with Megasquirt and see if anyone has written any useful CAN routines yet.
Just an aside... probably not viable but an ELM 327 does CAN. I wonder if it's limited to OBD or if it can sniff other things going on...
Kevin
-
Quick question, while were on this subject.
I have a NCDC2013 with a CID (paired) from a Vectra C, but dont have the Audio Pass or Log Book details as car was scrapped, can this still be depaired or Tech 2d?.
Sorry another one, will the above fit a Meg?, I know the screen is a diff size, but will the screen talk to Miggy MID interface?
NCDC should be fine but, the computer type functions etc are CAN based on the Vectra screen
[/highlight]
How did that get there?, I never wrote that (Highlighted)?
Sorry, hit modify rather than quote.....
-
I suspect it'll be a challenge and response based on the codes but without revealing the code itself.
Thats my understanding - there is data to link the screen and head and vehicle together, but not necessarily the code. The code data and Paired/depaired information is registered within the code chip, but is also relaint on other data from elsewhere.
Decoding the EEPROM contents is useful inasfar as we could determine how to place an item in delivery mode but only by gaining physical access to the EEPROM - perhaps by exchanging it for a "de-paired" one, or perhaps by programming it in-situ to revert it to the de-paired state. Tech 2 would obviously still be required to pair it again.
I was looking ahead of this - assuming that most units would need the eeprom to be physically accessed to depair, rather than simply cloning a virgin dump so that Tech2 is then needed, surely it would be the ideal oppurtunity to program in the data that is actually required, the same data in fact that would be written by tech2, so that the unit would function. If you know the data, and its location, theres nothing to stop us doing this at the same time. This may be related to some form of car pass information etc? possibly an encrypted algorythm of the car pass perhaps?
Once we have understood the codes / pairing and depairing etc, then we could then look at disabling the need for the pairing data altogether.
Just as a quick aside, Fiat have been using CAN programmable code for around 7 years now, needing a similar programmer like the tech2. We managed to crack that one fully a good few years ago, and can now actually manipulate the data inside the stereo so that the CAN handshake is eliminated completly and the stereos now function perfectly inside any vehicle (even non fiat) without any additional programming required at all - I am also working towards this on the latest Ford 2007/08 and Nissan 2008 units - just wanted to inform you that we have got quite a way forward with understanding this type of technology already.
-
Said theory on hold after a chat with a certain member who knows more about such things than I do
In view of the number of people actively trying to crack this one from different directions, and to prevent me (and a few others) from having the same conversation with every OOF member regarding this, I suggest the following, I am more than happy to discuss this on the open forum and share any thoughts and information with others as I have not yet found an easy way to do this either. Somebody out there may trigger off some thoughts that could assist us all and save us all some time, by hitting the same brick wall every time.
If I could make one request though, could any actual data dumps, Hex memory locations and "sensitive" data be retricted to PM to those who have the technical knowledge and capabilities to interpret such data, and not offered out on the general forum for obvious reasons, but would encourage those to openly report back on any findings and theories.
I think you know what I am trying to say?
:-/
Not got a clue! :-? :-? :-? It all went waaay waaay over my head! ;D ;D ;D
And me, you guys may as well be on everest, :-/ i think your safe tbh
edited, understood after reading on then lost again...logic reader? :-/
PS i am going to the rolling road day so if any body needs any gadgets or whatever transporting via OOF network, happy to help, also have 2015 with cid working if you want play with data :y
-
Well, I plugged the CDC board into my currently depaired 2013, and live data on security state on CDC was ID N.OK Yet (basically CDC Safe). I told the 2013 it now had a CDC, and live data on CDC, security state was ID OK (ie, working). 2013 still depaired from anything.
So, as Dave DND correctly said, seems CDC is not involved in coding.
As to end game. If we have depaired 2013 and depaired CID and depaired GID and possibly depaired telematic, then we are in a state where that could be put on to paired units with no code?
Or we could, perhaps, take images of stuff coded with a known code? Say 1111? So these could be put on devices (both stereo and screen), so no tech2 required, but the code is then known so we can depair again later if required?
For the last paragraph to work, I guess we need to pair up 2 seperate sets with same code, then swap screens over to see if they still work. If the challenge/response is clever, that may not work?
As said, if just going for former depaired images, I have depaired 2013 and CID. I cannot provide depaired GID.
I suspect the 2013 and 2015 are identical - adding telematics converts 2013 to 2015 (and changes assignment of some buttons). I need to check this further once I have got the screen on my CID working.
-
What if we look at the issue of code confirmation and think about it another way?
The HU checks the display has an identical code and is therefore paired, so if we can interogate what code a particular HU is looking for and jump into this communication before it gets to the display and return the correct code regardless would the display code then become irrelevant?
I'm hinting at some sort of piggyback type CAN device that can generate the required code. I guess the HU is expecting a particular can device id to respond though?
-
I suspect the 2013 and 2015 are identical - adding telematics converts 2013 to 2015 (and changes assignment of some buttons). I need to check this further once I have got the screen on my CID working.
Yes indeed, German companies offer a 1100 - 1500 upgrade service which is essentially that. I have a 2015 front panel that appears to be no more than different icons and legends to a 2013, the main board for the front panel appears identical.
For reference the front control panel circuit board is marked up as:-
Preh 13248-059.4000
90120-448/0000
656109.76.36 B
-
I suspect the 2013 and 2015 are identical - adding telematics converts 2013 to 2015 (and changes assignment of some buttons). I need to check this further once I have got the screen on my CID working.
Yes indeed, German companies offer a 1100 - 1500 upgrade service which is essentially that. I have a 2015 front panel that appears to be no more than different icons and legends to a 2013, the main board for the front panel appears identical.
For reference the front control panel circuit board is marked up as:-
Preh 13248-059.4000
90120-448/0000
656109.76.36 B
Live data on a 2013, watching button presses, shows both variations for which button pressed if it has different functions between the 2...
-
I suspect the 2013 and 2015 are identical - adding telematics converts 2013 to 2015 (and changes assignment of some buttons). I need to check this further once I have got the screen on my CID working.
Yes indeed, German companies offer a 1100 - 1500 upgrade service which is essentially that. I have a 2015 front panel that appears to be no more than different icons and legends to a 2013, the main board for the front panel appears identical.
For reference the front control panel circuit board is marked up as:-
Preh 13248-059.4000
90120-448/0000
656109.76.36 B
Live data on a 2013, watching button presses, shows both variations for which button pressed if it has different functions between the 2...
So purely down (as you rightly say) to the presence of a telematics unit, front panel purely cosmetic change with correct icons for phone function.
-
As to end game. If we have depaired 2013 and depaired CID and depaired GID and possibly depaired telematic, then we are in a state where that could be put on to paired units with no code?
Or we could, perhaps, take images of stuff coded with a known code? Say 1111? So these could be put on devices (both stereo and screen), so no tech2 required, but the code is then known so we can depair again later if required?
There is an extra element to this though that we are all missing
How does it pair with the vehicle itself ?
A matched screen and head unit can power up fine on the test bench, but I was to assume that there was a third bit of data here? The car itself. Pairing a screen to a head unit is one thing - but how and where is the data from the car figured amongst this - thats the real stumbling block I am hitting at the moment. tech2 obviously adds something, but what?
I guess we need to pair up 2 seperate sets with same code, then swap screens over to see if they still work. If the challenge/response is clever, that may not work
Yes, they do - but we need to isolate where the data is located inside the relevant sets for that to be usefull - Swapping the code chip from one set to another would indicate whether we are dealing with singular or multiple code chip(s) / processors etc inside.
-
What if we look at the issue of code confirmation and think about it another way?
The HU checks the display has an identical code and is therefore paired, so if we can interogate what code a particular HU is looking for and jump into this communication before it gets to the display and return the correct code regardless would the display code then become irrelevant?
I'm hinting at some sort of piggyback type CAN device that can generate the required code. I guess the HU is expecting a particular can device id to respond though?
With reference to the Fiat ones previously played with, once code locations and data were understood, it was simply a case of changing a few bytes of the dump to effectively turn off the need for the code conformation - no need for complex CAN piggyback devices, in theory its much simpler than that - just need to understand the data first.
-
I suspect the 2013 and 2015 are identical - adding telematics converts 2013 to 2015 (and changes assignment of some buttons). I need to check this further once I have got the screen on my CID working.
Yes indeed, German companies offer a 1100 - 1500 upgrade service which is essentially that. I have a 2015 front panel that appears to be no more than different icons and legends to a 2013, the main board for the front panel appears identical.
For reference the front control panel circuit board is marked up as:-
Preh 13248-059.4000
90120-448/0000
656109.76.36 B
Live data on a 2013, watching button presses, shows both variations for which button pressed if it has different functions between the 2...
So purely down (as you rightly say) to the presence of a telematics unit, front panel purely cosmetic change with correct icons for phone function.
Thats quite usefull then, it would give the impression that the solution we find for one unit, may indeed work for both types?
-
Well, I plugged the CDC board into my currently depaired 2013, and live data on security state on CDC was ID N.OK Yet (basically CDC Safe). I told the 2013 it now had a CDC, and live data on CDC, security state was ID OK (ie, working). 2013 still depaired from anything.
Do I understand correctly then that you have managed to fix the fault on the 2013/CDC3 of CDC-SAFE by reprogramming using the live data? As that may help with another way in !!
-
As to end game. If we have depaired 2013 and depaired CID and depaired GID and possibly depaired telematic, then we are in a state where that could be put on to paired units with no code?
Or we could, perhaps, take images of stuff coded with a known code? Say 1111? So these could be put on devices (both stereo and screen), so no tech2 required, but the code is then known so we can depair again later if required?
There is an extra element to this though that we are all missing
How does it pair with the vehicle itself ?
A matched screen and head unit can power up fine on the test bench, but I was to assume that there was a third bit of data here? The car itself. Pairing a screen to a head unit is one thing - but how and where is the data from the car figured amongst this - thats the real stumbling block I am hitting at the moment. tech2 obviously adds something, but what?
I guess we need to pair up 2 seperate sets with same code, then swap screens over to see if they still work. If the challenge/response is clever, that may not work
Yes, they do - but we need to isolate where the data is located inside the relevant sets for that to be usefull - Swapping the code chip from one set to another would indicate whether we are dealing with singular or multiple code chip(s) / processors etc inside.
AFAIK it doesn't, it's purely down to head unit and screen (and telematics if fitted) hence why you can fit a paired HU and screen from another car without issue even without Tech II, as long as you have a married pair.
The CAN bus is purely beteween the HU and it's components, the rest of the car isn't CAN.
-
Please explain in very simple terms ::) ...... While I understand, in very simplistic terms, the muliplex idea, the
testicle technical amongst you are talking about CAN of the can-bus .... what's it mean? :-?
-
As to end game. If we have depaired 2013 and depaired CID and depaired GID and possibly depaired telematic, then we are in a state where that could be put on to paired units with no code?
Or we could, perhaps, take images of stuff coded with a known code? Say 1111? So these could be put on devices (both stereo and screen), so no tech2 required, but the code is then known so we can depair again later if required?
There is an extra element to this though that we are all missing
How does it pair with the vehicle itself ?
A matched screen and head unit can power up fine on the test bench, but I was to assume that there was a third bit of data here? The car itself. Pairing a screen to a head unit is one thing - but how and where is the data from the car figured amongst this - thats the real stumbling block I am hitting at the moment. tech2 obviously adds something, but what?
I guess we need to pair up 2 seperate sets with same code, then swap screens over to see if they still work. If the challenge/response is clever, that may not work
Yes, they do - but we need to isolate where the data is located inside the relevant sets for that to be usefull - Swapping the code chip from one set to another would indicate whether we are dealing with singular or multiple code chip(s) / processors etc inside.
AFAIK it doesn't, it's purely down to head unit and screen (and telematics if fitted) hence why you can fit a paired HU and screen from another car without issue even without Tech II, as long as you have a married pair.
The CAN bus is purely beteween the HU and it's components, the rest of the car isn't CAN.
That is certainly the case on the Omega....and appears to be the case on Astra H to!
-
Please explain in very simple terms ...... While I understand, in very simplistic terms, the muliplex idea, the testicle technical amongst you are talking about CAN of the can-bus .... what's it mean?
OK, I`ll try to confuse everybody further. For those that know this is not entirely accurate, but hopefully its brief laymans view of what we are all talking about ?
In the good old days, to connect electrical items in a car together, we used a simple switch, a bulb / motor / whatever and a battery source for the. These were all connected together by simple wires, usually a switched power feed and an earth return, and we all knew how to fault find and fix things.
Things progressed, and effectively went computerised for want of a better explanation, and it meant that larger numbers of items could be connected together and controlled, but instead of thousands of wires connecting them, you could control everything by sending a data signal down a couple of wires to an interface at the other end, a bit like connecting a network of computers together. Depending on what switch you pressed, one of the other items would receive a data signal and then react accordingly. This is basically the theory behind the Multiplex systems in the car. No more simple wires carrying a 12 Volt on/off signal, it would instead be a few wires carrying thousands of data signals.
The wires that carry these multiple signals are often called Data Bus lines, or simply "Bus" for short. Now, all computers speak a language and have a form of operating system, you are all familiar with the terms Windows, XP, Basic etc etc, in a vehicle is often called CAN or CAN Protocol, and I think you should now be able to see where the term CAN-BUS comes from ?
The CAN protocol and language itself is a closely gaurded secret amongst the Manufacturers, and what we are all trying to do is effectively learn the language without the aid of any books and unlock its many secrets - very similar to the first people who starting hacking the operating systems of computers in order to allow some of the many features we now have to have evolved.
" Hackers of the Omega World - Have Now United !! " ;D ;D ;D
Did that help?
:-?
-
AFAIK it doesn't, it's purely down to head unit and screen (and telematics if fitted) hence why you can fit a paired HU and screen from another car without issue even without Tech II, as long as you have a married pair.
The CAN bus is purely beteween the HU and it's components, the rest of the car isn't CAN
So the coding is purely between head and screen? Car immaterial? SO if I am correct, as long as the screen / head / telematics communicate correctly, they could effectively be placed within any vehicle without the need for any further vehicle communication?
:-/
I think I may have been looking into this in too great a depth then, as one of my other forum projects is the DVD90 from the 07 Vectra, and Oh Boy, does that communicate with the car!
:(
This is where not being an Omega owner puts me at a disadvantage - I assumed the can was CAN ? If not, why on earth is Tech2 needed then, or is this just an overcomplication from Vx?
:-/
-
......
Did that help?
:-?
:y :y Yes! :y :y
-
That is certainly the case on the Omega....and appears to be the case on Astra H to!
AFAIK that is only true when the basic CD30 is fitted - The DVD90 certainly communicates with the vehicle ECU also, but unsure of CD70 as yet.
That applies to most post 05 models on the Vx range using this protocol.
-
AFAIK it doesn't, it's purely down to head unit and screen (and telematics if fitted) hence why you can fit a paired HU and screen from another car without issue even without Tech II, as long as you have a married pair.
The CAN bus is purely between the HU and it's components, the rest of the car isn't CAN
So the coding is purely between head and screen? Car immaterial? SO if I am correct, as long as the screen / head / telematics communicate correctly, they could effectively be placed within any vehicle without the need for any further vehicle communication?
:-/
I think I may have been looking into this in too great a depth then, as one of my other forum projects is the DVD90 from the 07 Vectra, and Oh Boy, does that communicate with the car!
:(
This is where not being an Omega owner puts me at a disadvantage - I assumed the can was CAN ? If not, why on earth is Tech2 needed then, or is this just an overcomplication from Vx?
:-/
The Omega only has a minimal CAN implimentation and it only covers the Radio-display link (only some units i.e. CCRT, NCDC, some CDC2's etc) and some gearbox-engine ECU links on later cars.
Its far from a fully blown CAN setup as per the Vectra C, Astra H and Corsa D (Corsa C also had a half way house on later models).
I suspect the NCDC in the Omega was CAN based as it allows re-use between other modesl which were fully CAN (i.e. Vectra C).
Also, yes, you can take a paired screen and NCDC and fit it in any car....this is something I have done a few times and is what is currently allowing TB's setup to work :y
What this also sudgests is that the NCDC is probably (an inference on my part) also doing the same in a Vectra C setup given it has the same internal firmware.
-
The Omega only has a minimal CAN implimentation and it only covers the Radio-display link (only some units i.e. CCRT, NCDC, some CDC2's etc) and some gearbox-engine ECU links on later cars.
Its far from a fully blown CAN setup as per the Vectra C, Astra H and Corsa D (Corsa C also had a half way house on later models).
I suspect the NCDC in the Omega was CAN based as it allows re-use between other modesl which were fully CAN (i.e. Vectra C).
Also, yes, you can take a paired screen and NCDC and fit it in any car....this is something I have done a few times and is what is currently allowing TB's setup to work
What this also sudgests is that the NCDC is probably (an inference on my part) also doing the same in a Vectra C setup given it has the same internal firmware.
That would explain my problems!! The unit I have here is from a Vectra C and I have far more internal data than the Omega seems to be able to provide.
I have been going round in circles trying to find where the missing data is coming from without the realisation that I can now disregard a HUGE chunk of the memory dump.
:)
-
Has anyone tried to Tech2 a head unit not fitted to a car?
For those playing, can somebody send me any depaired dumps from any equipment (screens or head) that has originated from an Omega - As I can then compare with the Vectra dumps I have here and rule out some information.
-
Has anyone tried to Tech2 a head unit not fitted to a car?
For those playing, can somebody send me any depaired dumps from any equipment (screens or head) that has originated from an Omega - As I can then compare with the Vectra dumps I have here and rule out some information.
As Marks DTM said, on Omega, CAN is not really implemented across the car. As long as Pair screen and stereo stay together, they will work anywhere.
Vectra may be more complex, particularly at the display end, as the display is a bridge between low and medium speed buses (Vectra-C has 3 buses).
My NCDR1500/GID/Telematics/CDC3 came from a Astra-G. I do not have the code it was originally paired with, hence cannot depair it all. It works perfectly in the Omega, bar a couple of issues unrelated to this discussion.
The 2013 and CID I am playing with are connected up to a battery by a few wires, and car on my living room carpet, much to Mrs TheBoy's annoyance ;D, and they pair/depair perfectly, proving that a car and the rest of its interfaces are not required :)
-
Well, I plugged the CDC board into my currently depaired 2013, and live data on security state on CDC was ID N.OK Yet (basically CDC Safe). I told the 2013 it now had a CDC, and live data on CDC, security state was ID OK (ie, working). 2013 still depaired from anything.
Do I understand correctly then that you have managed to fix the fault on the 2013/CDC3 of CDC-SAFE by reprogramming using the live data? As that may help with another way in !!
The CDC board was in another 2013 belonging to another member, but showing CDC-SAFE.
When I fitted to my little rig, the live data showed it wasn't working (can't tell from screen due to a fault with screen panel itself).
So I reset the cdc board, via tech2, to be for NCDC series (a small reprog function), and told NCDC that it now had CDC, and as far as I can tell, its happy.
So assuming that CDC is not coded, it appears I have fixed a CDC-SAFE error via Tech2 by reseting its config on what type of HU it is connected to.
Obviously, this is just one, and by no means a scientific survey.
If anyone near Marks DTM or I has any unit in CDC-SAFE, we would love to attempt this method again.
-
The CDC board was in another 2013 belonging to another member, but showing CDC-SAFE.
When I fitted to my little rig, the live data showed it wasn't working (can't tell from screen due to a fault with screen panel itself).
So I reset the cdc board, via tech2, to be for NCDC series (a small reprog function), and told NCDC that it now had CDC, and as far as I can tell, its happy.
So assuming that CDC is not coded, it appears I have fixed a CDC-SAFE error via Tech2 by reseting its config on what type of HU it is connected to.
Obviously, this is just one, and by no means a scientific survey.
If anyone near Marks DTM or I has any unit in CDC-SAFE, we would love to attempt this method again.
So it did work then!
-
Well, I plugged the CDC board into my currently depaired 2013, and live data on security state on CDC was ID N.OK Yet (basically CDC Safe). I told the 2013 it now had a CDC, and live data on CDC, security state was ID OK (ie, working). 2013 still depaired from anything.
Do I understand correctly then that you have managed to fix the fault on the 2013/CDC3 of CDC-SAFE by reprogramming using the live data? As that may help with another way in !!
The CDC board was in another 2013 belonging to another member, but showing CDC-SAFE.
When I fitted to my little rig, the live data showed it wasn't working (can't tell from screen due to a fault with screen panel itself).
So I reset the cdc board, via tech2, to be for NCDC series (a small reprog function), and told NCDC that it now had CDC, and as far as I can tell, its happy.
So assuming that CDC is not coded, it appears I have fixed a CDC-SAFE error via Tech2 by reseting its config on what type of HU it is connected to.
Obviously, this is just one, and by no means a scientific survey.
If anyone near Marks DTM or I has any unit in CDC-SAFE, we would love to attempt this method again.
Thats quite interesting, as although I know for certain that CDC3 is unrelated to both the code and the majority of this excercise, it indicates the Tech2 is capable of overwriting data in more than one location on the CDC3 simultaneously. I suspect that the data is actually changed via the head unit connected to, and actually via the Tech2 directly to the CDC3.
Now that you have a CDC3 that was CDC-SAFE and now reactivated via Tech2 is there any way you can take a memory dump from the 8 pin 24LC64 on the vertical board, as wold be interesting to see if data simply re-written with original from the head unit, or modified via the tech2
This could give a further indication to the data out signals for the handshake.
-
If anyone near Marks DTM or I has any unit in CDC-SAFE, we would love to attempt this method again.
Thats quite easy to re-create that experiment, I can send you a simple memory dump for the CDC3 eeprom alone, that would flag the processor to give a CDC-SAFE error
-
I suspect that the data is actually changed via the head unit connected to, and actually via the Tech2 directly to the CDC3.
Sorry, should say
I suspect that the data is actually changed via the head unit connected to, and not actually via the Tech2 directly to the CDC3.
:-[
-
Tonights update...
Back to CDC, this is coded to the device ring.
However, if you DONT know the code, tell the display and radio its doesn't exist, pair the radio and display, then add cdc back in to ring. Looks like that works.
To depair, remove cdc from radio and display ring, then depair.
Forgetting to remove CDC from stereo or display config, and attempting pair/depair, will reduce its life by 1. I guess when all lives have been used, game over (but guessing its something that people such as Dave DND can reset).
-
Tonights update...
Back to CDC, this is coded to the device ring.
However, if you DONT know the code, tell the display and radio its doesn't exist, pair the radio and display, then add cdc back in to ring. Looks like that works.
To depair, remove cdc from radio and display ring, then depair.
Forgetting to remove CDC from stereo or display config, and attempting pair/depair, will reduce its life by 1. I guess when all lives have been used, game over (but guessing its something that people such as Dave DND can reset).
The CDC3 does not require a code when used with the NCDC head, (internal or external) even though there is data in the memory locations, so depairing and repairing with the correct and WORKING unit does seem to work using this method. However, I would not recommend trying this with the externally CODED CDC3 units connected to head units that require the need for the CDC3 code to be used (CCR600 etc), as you may open up a can of worms!!
But I have noticed by using this method that you are actually using the Tech2 to reset the CDC3, instead of its own internal programs and head unit communications and this then appears to be running a different data set to its initial program.
You have spotted the counter that has already decreased by 1, (and you may find that it keeps reducing on its own!! monitor the memory dump!! ) but this appears to now be coming from the head unit, not the changer, as it cannot appear to be reset - if the CDC3 dump is reset manually, it now defaults back to its decreased state, so the head unit has now been altered also. The only way I have found to reset that counter is to reload the previous head unit dump again manually. I have taken mine to -3 but hesitant to go much further as I`m not sure what else is altering and if it can be fully recovered.
but if you look at the rest of the memory data as a whole, including now the head unit dump, you have also effectively reset and updated PART of the system, (that appears to be dependant on the firmware of the Tech2) and you will see that the changer is now running with completely different data to the head unit.
Although a usefull experiment, it may be exceptionally difficult to recover and reset the data from the head unit if they were allowed to remain connected for any length of time, and a complete rebuild may follow. Until all data is understood, this is certainly not something we know how to do yet at this stage.
The problem with playing around with the CDC3 data, is that is was actually bugged in the first place, which is why the CDC-SAFE error is so prevalent, and to fix this requires a firmware upgrade and a few alterations to the memory dump, (but all on the vertical board).
I would be interested to see your CDC3 memory dump though, and I can point out where the code location is for you, so that you can at least play around with a known bit of data if that helps.
-
Dave DND - I wonder if I could get a dump off CDC to you, you could let me know the code, so I could try the original experiement of trying to learn a depaired code via cdc/cdc3 - assuming the code its paired with is the one thats stored in the cdc/cdc3
Downside of that plan, when I played with certain other units with small SM eproms, I had a 50% success rate if removing them without breaking pins or cooking chips - and in this case whats stored on chips is more important than the chip itself...
-
If struggling to remove the chips, do you want to send the vertical pcb to me, I can take readings and send back with a full memory dump printout as well ?
;)
-
If struggling to remove the chips, do you want to send the vertical pcb to me, I can take readings and send back with a full memory dump printout as well ?
;)
If you weren't at the extremes of the universe, I'd have a day off, bring the whole lot down, along with Tech2, and we could have a play ;D
-
Hold that thought for a future time, as my Brother lives in Milton Keynes, and I do often come over for a visit !!
8-)
-
Hold that thought for a future time, as my Brother lives in Milton Keynes, and I do often come over for a visit !!
8-)
Remember to bring your equipment ;D - I'm 25 miles from MK...
-
Hold that thought for a future time, as my Brother lives in Milton Keynes, and I do often come over for a visit !!
8-)
Remember to bring your equipment ;D - I'm 25 miles from MK...
i know how far you are, Inlaws used to live in Northampton, and I used to live in Stevenage, so know that part of the country well.
Doesn`t solve the immediate problem though, do you want to send that vertical pcb over to me then?
-
Hold that thought for a future time, as my Brother lives in Milton Keynes, and I do often come over for a visit !!
8-)
Remember to bring your equipment ;D - I'm 25 miles from MK...
i know how far you are, Inlaws used to live in Northampton, and I used to live in Stevenage, so know that part of the country well.
Doesn`t solve the immediate problem though, do you want to send that vertical pcb over to me then?
You'll be able to read off existing code - not that we yet know if this code is in any way related to the code it was all paired together with?
If it is the right code, it brings us a step forward to being able to depair any NCDC setup, by reading the easy to get vertical board...
-
Hold that thought for a future time, as my Brother lives in Milton Keynes, and I do often come over for a visit !!
8-)
Remember to bring your equipment ;D - I'm 25 miles from MK...
i know how far you are, Inlaws used to live in Northampton, and I used to live in Stevenage, so know that part of the country well.
Doesn`t solve the immediate problem though, do you want to send that vertical pcb over to me then?
You'll be able to read off existing code - not that we yet know if this code is in any way related to the code it was all paired together with?
If it is the right code, it brings us a step forward to being able to depair any NCDC setup, by reading the easy to get vertical board...
Correct, I can read off the code and other data, and I`ll send it back with a printout showing where the code location is, so should you want to play around in the future by altering codes, you know where to do it.
:y
-
Hold that thought for a future time, as my Brother lives in Milton Keynes, and I do often come over for a visit !!
8-)
Remember to bring your equipment ;D - I'm 25 miles from MK...
i know how far you are, Inlaws used to live in Northampton, and I used to live in Stevenage, so know that part of the country well.
Doesn`t solve the immediate problem though, do you want to send that vertical pcb over to me then?
You'll be able to read off existing code - not that we yet know if this code is in any way related to the code it was all paired together with?
If it is the right code, it brings us a step forward to being able to depair any NCDC setup, by reading the easy to get vertical board...
Correct, I can read off the code and other data, and I`ll send it back with a printout showing where the code location is, so should you want to play around in the future by altering codes, you know where to do it.
:y
PM sent. It would be good to get this part of the puzzle out of the way - Mrs TheBoy is getting somewhat cheesed off with bits of car radio scattered all over lounge floor, and she is under strict instructions not to touch/move anything ;D
-
Dave DND - how do you rate my chances of getting a good read off it when still in circuit? Just having a look, its the 24c64 in corner of board?
-
Dave DND - how do you rate my chances of getting a good read off it when still in circuit? Just having a look, its the 24c64 in corner of board?
Seemed to get a dump in circuit. Assuming not too much of the flash is used, it looks valid.
Emailed to address mentioned in 3rd post of thread.
;)
-
Dave DND - how do you rate my chances of getting a good read off it when still in circuit? Just having a look, its the 24c64 in corner of board?
Seemed to get a dump in circuit. Assuming not too much of the flash is used, it looks valid.
Emailed to address mentioned in 3rd post of thread.
;)
Dumps sent seems to appear valid - old version of CDC3 using an encrypted code - I`ve sent a replay back with code number, and also another dump for you to try out.
;)
-
Dave DND - how do you rate my chances of getting a good read off it when still in circuit? Just having a look, its the 24c64 in corner of board?
Seemed to get a dump in circuit. Assuming not too much of the flash is used, it looks valid.
Emailed to address mentioned in 3rd post of thread.
;)
Dumps sent seems to appear valid - old version of CDC3 using an encrypted code - I`ve sent a replay back with code number, and also another dump for you to try out.
;)
Trying out in a mo (the code, not new dump - that will have to wait for tomorrow :y
-
Dave DND - how do you rate my chances of getting a good read off it when still in circuit? Just having a look, its the 24c64 in corner of board?
Seemed to get a dump in circuit. Assuming not too much of the flash is used, it looks valid.
Emailed to address mentioned in 3rd post of thread.
;)
Dumps sent seems to appear valid - old version of CDC3 using an encrypted code - I`ve sent a replay back with code number, and also another dump for you to try out.
;)
Trying out in a mo (the code, not new dump - that will have to wait for tomorrow :y
If the code works, have a look at the error counter and see it if resets itself back from 6 - In theory it should do, but unsure when used with NCDC as this Shouldn`t really use the coded part of the dump.
-
I tried to pair it all together using that code, it failed, saying CDC hasn't been depaired from its old car. I think (but don't know for certain) that if you attempt to pair with correct code, it will code successfully (it does with screen).
The code attempts left has reduced, and the wait time has gone up to 1:20, but doubt it uses that.
-
So I guess we need to find where the pairing is stored in cdc :'(
-
Try the dump I sent, as I think I may have disabled the pairing !!
:-/
-
Try the dump I sent, as I think I may have disabled the pairing !!
:-/
I will try that tomorrow, a few too many beers to focus on small components tonight :-[
-
No worries, and remember if you also put back the original dump you sent me, the unit will revert to its previous state also.
Did the dump/CDC3 you sent originate from a NCDC setup though?
Or CCRT700 ?
-
No worries, and remember if you also put back the original dump you sent me, the unit will revert to its previous state also.
Did the dump/CDC3 you sent originate from a NCDC setup though?
Or CCRT700 ?
The dump I sent you originated from NCDx/ccr2008(vectra) series. The dump you sent me originated from ccr600/ccrt700 so didn't pair - similar error to if the CDC isn't plugged in.
I'm pouring over the dumps, and wondering if I change the part number on your dump to match the part number required for NCDx series... ...whats the worse that can happen, apart from it all smokes up ;D
Also, now got a problem with my CID being in a paired state, and having the hump talking to tech2, so need to fix that first :'( - it happened once before, seems it needs to be left disconnected for an hour or 2....
-
The dump I sent you originated from NCDx/ccr2008(vectra) series. The dump you sent me originated from ccr600/ccrt700 so didn't pair - similar error to if the CDC isn't plugged in.
Yes, the one I sent back was from an Unpaired CCRT700 that has had the code disabled - Usefull to know it wouldn`t work, didn`t think it would.
I'm pouring over the dumps, and wondering if I change the part number on your dump to match the part number required for NCDx series... ...whats the worse that can happen, apart from it all smokes up
Never tried that - I have only really plyed around with the original dumps and data, never tried to make a dump think it was something else though - Its not going to do anything worse than conflict with the head unit if it doesn`t work, no worse than the dump I sent previously - and you can always revert back to original dump again. If you think you can change the part number, certainly no harm in trying.
-
The dump I sent you originated from NCDx/ccr2008(vectra) series. The dump you sent me originated from ccr600/ccrt700 so didn't pair - similar error to if the CDC isn't plugged in.
Yes, the one I sent back was from an Unpaired CCRT700 that has had the code disabled - Usefull to know it wouldn`t work, didn`t think it would.
I'm pouring over the dumps, and wondering if I change the part number on your dump to match the part number required for NCDx series... ...whats the worse that can happen, apart from it all smokes up
Never tried that - I have only really plyed around with the original dumps and data, never tried to make a dump think it was something else though - Its not going to do anything worse than conflict with the head unit if it doesn`t work, no worse than the dump I sent previously - and you can always revert back to original dump again. If you think you can change the part number, certainly no harm in trying.
Unless you have an unpaired ncdc dump? I guess if you had, you would have sent it ;D
-
Unless you have an unpaired ncdc dump? I guess if you had, you would have sent it
::)
-
BTW CCR600 and CCRT700 use different dumps also, so it does look as though each scenario of CDC3/Pairing uses a different dump although keeps the code data in the same memory location.
-
BTW CCR600 and CCRT700 use different dumps also, so it does look as though each scenario of CDC3/Pairing uses a different dump although keeps the code data in the same memory location.
CCR600 and CCRT700 look to be same 'part' (I know they are all same part), with Tech2 setting the specific config. NCDR1x00/NCDC201x/CCRT2008(Vectra) seem to be same 'part', again with tech2 deciding which one is used.
-
So which chips do we think are storing the info on the NCDC head unit.
I have the following options:
NEC D78P058GC - An OTP Microcontroller - Outside bet being an OTP!
Microchip 24LC16(B) - 16K I2C Serial Prom - Gotta be a favourite and right next to the microcontroller!
There is then
1 off AM29LV200 - 2M Flash device associated with the GPS device (from motorola)
2 off AM29LV160 - 2M Flash device associated with the HD6417709 microcontroller
HD6417709 - RISC Microcontroller......this is asociated with the massive quantity of flash above!
-
So which chips do we think are storing the info on the NCDC head unit.
I have the following options:
NEC D78P058GC - An OTP Microcontroller - Outside bet being an OTP!
Microchip 24LC16(B) - 16K I2C Serial Prom - Gotta be a favourite and right next to the microcontroller!
There is then
1 off AM29LV200 - 2M Flash device associated with the GPS device (from motorola)
2 off AM29LV160 - 2M Flash device associated with the HD6417709 microcontroller
HD6417709 - RISC Microcontroller......this is asociated with the massive quantity of flash above!
Not looked at HU yet - trying to find existing code on cdc unit (then I can get code for my lot in MV6) - but the 2416 has to be favourite, seeing as thats what I'm attacking on the cdc unit. And can be prog'd in situ :y, which saves a lot of hassle ;D
-
Haven't looked that hard at CID yet.
Remember, HU and CID will need reprogramming if you don't know code. CDC will work, but remove from cdc from HU and cid config, pair, then add CDC back in.
-
From units I have here,
NCDC2013 with D78P058GC uses 24C64 smd + 24LC16 to store data
whilst
NCDC2015 with NEC HS9938-02 uses 24LC16 smd to store data
Both appear to be encrypted.
-
The dump I sent you originated from NCDx/ccr2008(vectra) series. The dump you sent me originated from ccr600/ccrt700 so didn't pair - similar error to if the CDC isn't plugged in.
Yes, the one I sent back was from an Unpaired CCRT700 that has had the code disabled - Usefull to know it wouldn`t work, didn`t think it would.
I'm pouring over the dumps, and wondering if I change the part number on your dump to match the part number required for NCDx series... ...whats the worse that can happen, apart from it all smokes up
Never tried that - I have only really plyed around with the original dumps and data, never tried to make a dump think it was something else though - Its not going to do anything worse than conflict with the head unit if it doesn`t work, no worse than the dump I sent previously - and you can always revert back to original dump again. If you think you can change the part number, certainly no harm in trying.
Part number alone doesn't send it to ncdc mode. Will have to try again. Again, soldering iron is not to be used tonight due to and outting with Stella ::)
-
So which chips do we think are storing the info on the NCDC head unit.
I have the following options:
NEC D78P058GC - An OTP Microcontroller - Outside bet being an OTP!
Microchip 24LC16(B) - 16K I2C Serial Prom - Gotta be a favourite and right next to the microcontroller!
There is then
1 off AM29LV200 - 2M Flash device associated with the GPS device (from motorola)
2 off AM29LV160 - 2M Flash device associated with the HD6417709 microcontroller
HD6417709 - RISC Microcontroller......this is asociated with the massive quantity of flash above!
I reckon CID is possibly on 93C56 (that sounds invalid - but both Mrs TheBoy and I reckon thats what it says). On middle board. I'll PM why I think its that chip if you're interested.
-
So which chips do we think are storing the info on the NCDC head unit.
I have the following options:
NEC D78P058GC - An OTP Microcontroller - Outside bet being an OTP!
Microchip 24LC16(B) - 16K I2C Serial Prom - Gotta be a favourite and right next to the microcontroller!
There is then
1 off AM29LV200 - 2M Flash device associated with the GPS device (from motorola)
2 off AM29LV160 - 2M Flash device associated with the HD6417709 microcontroller
HD6417709 - RISC Microcontroller......this is asociated with the massive quantity of flash above!
I reckon CID is possibly on 93C56 (that sounds invalid - but both Mrs TheBoy and I reckon thats what it says). On middle board. I'll PM why I think its that chip if you're interested.
Yes, 93C56 on middle board is correct :y
If it helps, it can usually be read / written to in circuit without any problems. I do tend to program as an ATMEL device instead of ST though when doing this
-
Should have my I2C programmer working this Pm.....so will start to draw some files.
-
Right, getting along nicely with CDC board that was paired to another unknown setup, and we didn't have the code. I now know how to put CDC board into delivery mode.
That means I have the following in delivery mode:
NCDC2013 (faulty)
CDC (board only, part of mech missing)
CID (with faulty screen)
I do not (yet) have a telematics in delivery mode.
-
Dave DND - Email sent, see if you can decode the code I paired this CDC with. If so, that may prove very useful.
-
Ok, just knocked a ponyprog up.....
(http://i23.photobucket.com/albums/b394/Marks_DTM_Calib/DSC00083-1.jpg)
....ready to go!
-
Ok, just knocked a ponyprog up.....
(http://i23.photobucket.com/albums/b394/Marks_DTM_Calib/DSC00083-1.jpg)
....ready to go!
I'm using mine so much, I should do it properly, rather than how it is (just component legs soldered together) - it was only a quick and dirty to do traffic master 'repairs'
-
Ok, just knocked a ponyprog up.....
(http://i23.photobucket.com/albums/b394/Marks_DTM_Calib/DSC00083-1.jpg)
....ready to go!
I'm using mine so much, I should do it properly, rather than how it is (just component legs soldered together) - it was only a quick and dirty to do traffic master 'repairs'
LOL I seem to remember that! ::) ;D
-
Ok, just knocked a ponyprog up.....
(http://i23.photobucket.com/albums/b394/Marks_DTM_Calib/DSC00083-1.jpg)
....ready to go!
I'm using mine so much, I should do it properly, rather than how it is (just component legs soldered together) - it was only a quick and dirty to do traffic master 'repairs'
LOL I seem to remember that! ::) ;D
The birds' nest!
Kevin
-
Ok, just knocked a ponyprog up.....
(http://i23.photobucket.com/albums/b394/Marks_DTM_Calib/DSC00083-1.jpg)
....ready to go!
I'm using mine so much, I should do it properly, rather than how it is (just component legs soldered together) - it was only a quick and dirty to do traffic master 'repairs'
LOL I seem to remember that! ::) ;D
The birds' nest!
Kevin
But it works, despite being crushed under a car jumpstarter (used to power network switch for a while until yet another adapter was acquired) ::)
-
Believe we have found where the code is possibly stored, but unsure, currently, how to decrypt it.
-
Believe we have found where the code is possibly stored, but unsure, currently, how to decrypt it.
I`m going to pass those dumps on to a few tecchie friends of mine to see if we can work out a decryption based on your data - I`ll also chase up a few friends within Siemens/Germany to see if we can make any ground there as well.
For anyone else playing around, only the dumps from the NCDC range of radio / CDC3 combination are applicable to this, and no matter what you know about other CDC3 combo`s, the data is completely irrelavent when used with NCDC. Thanks to TB, this has now been fully proven.
:-[
-
OK, desperately close to achieving my original aim - being able to get code for my setup in MV6 (code unknown) purely from info gleaned from CDC3.
I believe I can already do it for NCDC2013 type stereos now. Just need a dump from a CDC, so I can prove on another unit.
Volunteer time! ;)
-
OK, all the codes I have put on my test ncdc2013, I have been able to predict the contents of the flash chip in the cdc.
Hopefully, there is nothing specific about different headunits that cause a variation in the encryption.
-
Additionally, I have done lots of testing with partially paired systems, so I know how to recover from partially depaired systems, or replacing failed components if the original codes are known.
-
As TB said, a call to anyone else who can provide a dump or the quick loan of an NCDC set to have a quick play with please.
This is very nearly cracked I think, TB has covered a lot of ground today !!
Oh, and purely as a side issue, TB, the dump you sent for the 2222 pairing has the corrected data for fixing the CDC-SAFE error on the NCDC systems !!! It would appear that the two data bits causing the error on this particular combination are actually held within the code eeprom on the CDC !! Rewrite the chip with the clean dump and the error goes away.
:y
-
do i take one step forward or does everyone else take one step back? 2015 though?
-
do i take one step forward or does everyone else take one step back? 2015 though?
Dont understand ?
:-/
-
do i take one step forward or does everyone else take one step back? 2015 though?
Dont understand ?
:-/
I think he's volunteering a CDC2015 ..... :y :y :y :y
-
do i take one step forward or does everyone else take one step back? 2015 though?
Dont understand ?
:-/
I think he's volunteering a CDC2015 ..... :y :y :y :y
After all the hard work by TB, there are no more small steps forwards, only giant leaps forward !!
And as far as going backwards, I have done enough of that for all of us!
But access to a 2015 would be superb :)
-
They appear to be the same lump (I have one in the garage) with only the front panel and a few tech 2 options changed!
-
They appear to be the same lump (I have one in the garage) with only the front panel and a few tech 2 options changed!
Give TB a yell - I thinks thats really going to help !!
:y
-
do i take one step forward or does everyone else take one step back? 2015 though?
Dont understand ?
:-/
;D i am volunteering...? Cant do dumps but happy to take the car with 2015 to someone who can. jamie perhaps? Typically i was only up there last weekend.
-
i pm'd TB last week re rolling road day, so he has my number. Give us a bell if needed... Happy to help/interested to see what goes on.
-
TB you have a pm.
-
TB you have a pm.
Replied :'(
-
They appear to be the same lump (I have one in the garage) with only the front panel and a few tech 2 options changed!
Is that the one I delivered to you? Have you fixed it yet?
If you have, can I borrow for a while next time I see you, just what to do some more testing with it.
And next time you have one apart, can you see what the amp chip is on the back - my test one here has it missing, and slowly I would like to get it fully working.
-
[split] [link=http://www.omegaowners.com/forum/YaBB.pl?num=1224270359][splithere][/link][splithere_end]
-
My original intention of this thread - lost as it started out as PMs and another thread - was to be able to learn the code for the NCDR1500/GID/CDC3/Telematics, so I could depair, and add a colour screen, and repair.
With immense assistance from Dave DND and Marks DTM Calib, not to mention borrowing a CDC board from Tunnie, I have now achieved that goal, and my NCDR1500 setup has been depaired, and repaired with a code more appropriate for my car. Now I just need to fix the 2 faulty CIDs I have here (had to buy another faulty one, prepaired, but with known code, for testing). I have a 3rd faulty CID belonging to another member that will allow me to fix one of mine if we can agree a price ;D
To prove the process used to obtain the unknown code, I am waiting on somebody with the skills, knowledge and equipment to send me a dump of their cdc board, once he has fixed his reader ;D
-
I know that there are variants of CDC3 changer, and the Main PCB`s of the head units are also different.
What about the CID ?
Is that the same CID unit used across all radios in the Omega, or are there differences there also?
-
I know that there are variants of CDC3 changer, and the Main PCB`s of the head units are also different.
What about the CID ?
Is that the same CID unit used across all radios in the Omega, or are there differences there also?
My guess is the CDC boards are electronically the same for ALL CDC3s (different plugs soldered in different locations depending on whether its was destined for double din, or as seperate unit).
That original dump you sent me converted my NCDC cdc board to a CCR600 board by look of things. I converted back to NCDC board by putting my dump back on. Note, Tech2 cannot convert between these types!
For an NCDC cdc board, Tech2 allows you to config for NCDR (external unit), NCDC (internal), and CCR2008.
For CCR600 cdc3 board, Tech2 allows tou to config for CCR600 (and presumably ccr800), and ccrt700
As for the main headunit boards, again, I reckon they are identical at the software level between ncdr1100/ncdr1500/ncdc2013/ncdc2015 with tech2 config deciding that it is a telematics compatible unit (NCDR1500 or NCDC2015). Obviously the icons on the buttons vary, but thats cosmetic.
I had a chat with MDTM last night, eating into his valuable drinking time ;D, and I know he has started to look into the different revisions of the boards, but thinks its nothing major.
As for CIDs, not looked yet, but imagine its a similar setup, identical at software level (and thus hopefully identical dumps), with possibly different hardware revisions. I need to start ripping CIDs apart to try to fix a fault on them, so can compare the dumps :)
-
I know that there are variants of CDC3 changer, and the Main PCB`s of the head units are also different.
What about the CID ?
Is that the same CID unit used across all radios in the Omega, or are there differences there also?
Also, do you have many NCDC radios and screens to play with, or is it just customer stuff that comes in?
-
My original intention of this thread - lost as it started out as PMs and another thread - was to be able to learn the code for the NCDR1500/GID/CDC3/Telematics, so I could depair, and add a colour screen, and repair.
With immense assistance from Dave DND and Marks DTM Calib, not to mention borrowing a CDC board from Tunnie, I have now achieved that goal, and my NCDR1500 setup has been depaired, and repaired with a code more appropriate for my car. Now I just need to fix the 2 faulty CIDs I have here (had to buy another faulty one, prepaired, but with known code, for testing). I have a 3rd faulty CID belonging to another member that will allow me to fix one of mine if we can agree a price ;D
To prove the process used to obtain the unknown code, I am waiting on somebody with the skills, knowledge and equipment to send me a dump of their cdc board, once he has fixed his reader ;D
I should add, there is still much to be learnt, and although my original goal was met, I am intrigued to find out more.
As a minimum, I certainly would like to be able to have a process for depairing any component with an unknown code, be it via finding out the code in a similar manner, or by putting a depaired image on the unit (which will then need some kind of tech2 work afterwards). I guess Dave DND is best placed to answer which is the best road to go down there?
-
I came across this post, and would like to add that I have depaired a few NCDCs using this method, so I think the process is proven :y
-
Yes I think the NCDC decoding you have mastered is well proven now! ::) :y
Where did we get to with Telematics? Seems a long time now!
-
Yes I think the NCDC decoding you have mastered is well proven now! ::) :y
Where did we get to with Telematics? Seems a long time now!
Nowhere. CID stuff was next, but then I shagged all my spare CIDs :'(