New Z2 "bypass/back door" something to check

[vap11554]

sorry beachdoc i dont mean to critisize but i see somany people putting so much time in a fix which is not a pemenant fix.myself included.i have been trying every concept to mechanically bypass this with no luck in my opinion its software and untill we figure out how to manipulate the software we are not there yet.i really did not mean to bash you and i appologize if i did ,all i meant was we should be looking at the software route instead of playing with something that isent fullproof.

[Beachdoc]

Vap,

No harm and thanks for understanding. I too think the perm fix is in the software/OS. I wonder if unlocking my Z2 HDD and looking at the image if there's a callibration file, or system check file to manipulate. I'm in for my donating my image file if someone else wants to contribute.

 

I wonder if the callibrations are stored in the flashmem and kept by a constant voltage or written on the HDD as it learns. One might try to disconnect the negative lead for a few minutes then reconnect and see if the callibrations stay when booted. Would that be a useful idea?

[vap11554]

i have run without vss wire conected and it learns at first,when you connect the vss wire it only seems to help it in speed of auto .it still has to cal. for direction,left.rt turning.that is why with or without the wire the unit knows your moving and shuts down vid.we need to find the script whitch is telling it to disable and remove this line or change to enable

[AEXEP]

Since I'm in the market for a AVIC-Z2 or similar I've been following a few of these bypass threads for a few days now. While the majority of the posts have been looking for some external physical bypass a few have indicated that the solution may be in the software itself.

 

To lend some credibility to that (potentially), I'd like to point all of you to a couple of links that might spark a conversation or two...

 

First;

http://msdn2.microsoft.com/en-us/library/ms858633.aspx

 

Using Windows Automotive

Electronic Driver Distraction Control

 

In the Windows Automotive version 4.2 environment, the OEM may be interested in minimizing distraction to the driver while the vehicle is in operation.

 

The OEM can implement support for an Electronic Driver Distraction Control (EDDC) that is used to notify EDDC-aware applications when the vehicle is in operation. This section provides information on how an OEM can implement this.

 

Messages delivering EDDC information can be binary in nature, meaning that the OEM-designated hardware interface should provide a Yes/No state that defines whether the vehicle is in operation. The OEM-designated hardware interface can come from any number of vehicle systems, such as emergency brake on/off, gearshift selection, or speed pulse from the speedometer.

 

Once the hardware interface provides the binary information, the EDDC driver posts a message for all applications that are listening for it. EDDC-aware applications can register to receive EDDC messages by calling functions on an EDDC control. Then, EDDC-aware applications can receive and respond to EDDC messages by adjusting their functionality.

 

EDDC-aware applications can also retrieve EDDC state information at any time by using an EDDC control.

 

With EDDC, Windows Automotive enables OEMs and application developers to work together at a system level to minimize distractions while a vehicle is in operation.

 

In this Section

EDDC Notification of State

Applications and EDDC

EDDC Hardware Interface

Building an EDDC Control

Building an EDDC Application

Writing an EDDC Driver

 

Followed by;

http://msdn2.microsoft.com/en-us/library/ms858638.aspx

 

Using Windows Automotive

EDDC Hardware Interface

 

The OEM is solely responsible for designating the EDDC hardware interface. This provides the OEM with the flexibility to decide which types of situations should represent an In Operation state.

 

In general, the hardware interface should be tied to some system component that would signify that the vehicle is being operated. For example, the interface may be tied to the parking brake, transmission, or other vehicle system. The OEM should select one specific vehicle system component to determine EDDC state for the hardware device. EDDC state can be expressed as a binary value (i.e. In Operation/Not In Operation).

 

Now it would not be a stretch to have the EDDC state tied to the integrated NAV such that when the car is moving (depending upon the detail or granularity of the GPS reciever) at some predetermined MPH/KPH that the EDDC state changes and certain so-called distracting features, like video are disabled as a result.

 

Now because the application(s) in the Z2 may be EDDC aware, the only way I can think of going after this is by looking for and modifying the EDDC driver such that it always returns the value indicating that the vehicle is NOT in operation regardless of the actual state of operation, no matter how many times that EDDC function is called.

 

So who has and is willing to upload the Z2 image, and my guess would be that it's not on the HD but on some flash or SD card in the unit itself...

 

This may be the first implementation of this particular feature, but it would not surprise me if other manufacturers of similar NAV integrated units did the same....

[Beachdoc]

It seems odd that my system still doesn't shut off the video after 200 miles, it calibrates everything, and the dynamics work. I can't explain why. It has no VSS input or e-brake input. The diff. is my system isn't affected by the change in GPS position or int. gyros no matter how many miles I drive. I still think I did something diff on the initial calibration that told it not to look further for these things.

 

However, the soln is going to be in the HDD/OS. If it writes a file on the HDD to determine what it should be looking for then that should be much easier to find than trying to access the internal OS. If we check whether the calibrations are the same after disconnecting the battery then reconnecting, shouldn't that indicate whether it's an HDD file or the internal OS?

[AEXEP]

I'm doubtful that its a file that is written to disk, I suspect that what ever that EDDC driver is using to determine operational vs. non-operational state of the vehicle may not be as fully binary as Pioneer might of hoped.

 

Again, that EDDC driver is contantly monitoring the state of something, what that something is I can't tell you. Once that something reaches a certain threshold, the driver sets a variable from a binary 0 to a 1. Any other software that monitors the EDDC state will then change its operation accordingly.

 

Now is it possible that some shim is monitoring several physical/analog components and reporting the back to the EDDC driver which then announces to all other applications the state of the vehicle in binary? Sure its possible and could explain some of the variability in the implementation of the backdoor. Converting Analog inuts to a single Binary input can be a tricky thing and subject to error...

 

But we won't know until we get a good look at that flash and the HD and can analyze the OS in excrutiaing detail...

[Beachdoc]

I'm still willing to donate my image or vice versa to anyone interested. Someone with a Z2 would be the best comparison.

[action]

Hmmm... I wonder if there isn't something to all this?

 

It seems to me that the Z1 EDDC driver must have had some logic like:

"If ( gyros say vehicle is moving OR gps says vehicle is moving OR parking brake is off ) AND bypass wire isn't grounded THEN send out a "We're moving" signal to the listening applications.

 

The new EDDC likely has the same logic minus the bypass wire part.

 

If you could pull the EDDC driver off the Z1 and replace the Z2's with it, maybe the old bypass would work again since it would be looking for the bypass wire.

 

I'm just not sure if you can simply change a driver without reinstalling it.

 

Food for thought...

 

Edit: Whoops, I said parking brake "on" instead of "off"

[AEXEP]

OK that's possible but there's probably more to it, maybe. Then again it could be just that simple...

 

Here's some more links based on what I shared previously...

 

http://msdn2.microsoft.com/en-us/library/ms858650.aspx

 

The OEM is solely responsible for designating the EDDC hardware interface. This provides the OEM with the flexibility to decide which types of situations should represent an In Operation state.

 

In general, the hardware interface should be tied to some system component that would signify that the vehicle is being operated. For example, the interface may be tied to the parking brake, transmission, or other vehicle system. The OEM should select one specific vehicle system component to determine EDDC state for the hardware device. EDDC state can be expressed as a binary value (i.e. In Operation/Not In Operation).

 

Although the MSDN article suggests and OEM should select one specific system to monitor, it does not categorically state that the OEM is limited to one and only one vehicle system component to monitor.

 

As far as the code for the driver or simply writing over the Z2 driver component with the Z1 driver component,

 

http://msdn2.microsoft.com/en-us/library/ms858654.aspx

 

An OEM can build an EDDC driver that interfaces to platform-specific hardware and enables an automotive platform to detect EDDC state changes and to provide notifications to applications.

 

The EDDC driver must include both a model device driver (MDD) layer and a platform dependent driver (PDD) layer. For additional information on this, see Driver Code Structure in the Windows CE .NET documentation.

 

NOTE Code samples in this topic are targeted to a specific device and will vary depending on the type of hardware that your platform is based on.

 

From what I've been reading, and as far as I've been able to fathom based on what I've read. It appears that the Z1 and Z2 are based on similar if not the identical hardware platform. If that is the case then it could be as simple as overwriting one .DLL with another, but then again that could just be the tip of the iceberg.

 

Time and some ingenuity will eventually work this bypass out...

[action]

Yeah, I was basing my theory that the Z1 and Z2 are, internally, identical. Again, I'm not sure what the effects of simply overwriting the .DLL would be. I don't have much experience (read: any experience) writing .DLLs and haven't even written in low-level code since high school (never mind how long ago! ).

[AEXEP]

Hopefully someone with the right skill set and the capability will pick up this ball and run with it... Any takers?

 

Quite honestly this bypass or more accurately the lack of a bypass is what is driving me toward the Kenwood DNX7100... (much to the surprise of my local retailer who tried to temp me with a AVIC D3 - Javier you listening?)

 

Well that and the ability to play video off of a USB HD, without an iPod...

[titos]

well evey dll file i tried to replace on the z2 harddrive wit the z1 prevents the z2 from booting so i gotta find exactly what dll file is responsible for the bypass then play with the script on that 1 file to get it to work but i have been working by myself on this and theres alot of files that look to be the bypass but still cant get ti to work but we will find it one way or another and also on a side note i am a local shop owner and let me tell you the kenwood your looking at suck compared to the z2 just be patient and the bypass will come

[AEXEP]

If you look over some of the Microsoft Automotive links I shared I think you'll quickly come to the conclusion that you are probably not dealing with just one DLL but an entire messaging and monitoring subsystem of the OS.

 

I doubt its going to be as simple as replacing one file. If I were a betting man I'd bet on one of two scenarios.

 

1) A group of files representing the entire EDDC subsystem.

2) Something similar to a registry setting that provides the bypass.

 

Now from one of the posts I read it appears that the European Z2 units do not implement EDDC. If that is the case I would expend some effort on getting a copy of that image as a baseline and begin looking at differences. While I expect they'll be a whole bunch, it'll at least be a start. Otherwise we'll be playing around with this for a good long time and more than likely without too much success....

 

If I were a betting man.... Then again there is always the brute force approach.

 

Quite honestly if only Pioneer Legal would write up a disclaimer absolving the company of any responsibility, shifting the responsibility of a potential distraction to the owner then as a result providing the software bypass. We'd be done with this nonsense and everybody would be happy.

 

Doubt that would happen anytine soon...

[murzik]

well evey dll file i tried to replace on the z2 harddrive wit the z1 prevents the z2 from booting so i gotta find exactly what dll file is responsible for the bypass then play with the script on that 1 file to get it to work but i have been working by myself on this and theres alot of files that look to be the bypass but still cant get ti to work but we will find it one way or another and also on a side note i am a local shop owner and let me tell you the kenwood your looking at suck compared to the z2 just be patient and the bypass will come

 

Did you try to swap whole prg0 folder?

[vap11554]

ok i got a good one.

while driving and parking break grounded i reset unit.it came back on and had vid with no error message all vid ok and all controls open to use.the map was in the wrong place and it took about 10 min. for it to find itself.when it did vid still worked and functions still open i drove for about 10 more min. and map was accurate and still had vid,which says it may be something else telling it to sut down.the nav knew the car was moving and my unit told me i was moving at 48mph with no vss wire in the hardware screen