Print

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

[TheBoy]

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  .  Thats Plan B.

Plans C,D,E still need to be thought up, and, like Dave DND, I am open to suggestions

[TheBoy]

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

[VXL V6]

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?

[Kevin Wood]

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

[Marks DTM Calib]

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!

[Kevin Wood]

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

[Marks DTM Calib]

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

[Marks DTM Calib]

Ow yes


I have a working CID

and a paired and working NCDC/GID.

[Dave DND]

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.

[zirk]

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

[Marks DTM Calib]

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.

[zirk]

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)?

[Kevin Wood]

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

[Marks DTM Calib]

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

[Dave DND]

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.