Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dave DND]

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?

 :-/

[TheBoy]

Split off to a new thread.

Your request sounds appropriate to me, esp considering it will always need specialist equipment and skills.

[Dave DND]

For those wanting to share memory dumps with me, please use this address to send them to.

technical@dndservices.co.uk

 8-)

[Marks DTM Calib]

So then Mr TB.....I guess the next step is to start pulling some dumps from these various units we have floating around!

[Andy B]

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!  

[Dave DND]

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  

[Dave DND]

Not got a clue!  :-? :-? :-? It all went waaay waaay over my head!  

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?   :-/

[Andy B]

......
did that make sense?   :-/

Perectly clear that time!        

[TheBoy]

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 .  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.

[TheBoy]

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 .  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 . Possibly.  

[Dave DND]

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.

 

[TheBoy]

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  :-/

[TheBoy]

Can the various PROMs be read in situ (by soldering wires from my pony prog (), or need to be removed first?

[Dave DND]

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.

 

[Dave DND]

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.