i really hope u guys figure this out. i know nothing about this stuff or what any of that stuff is above. i wish i did because i would help out in a heart beat. sorry to say i am no help but you guys would help out a hell of alot of people by getting this thing cracked. good luck guys.
Hmmm... Kinda looks like 'C' (programming language).
Edit: And the 'asm' statements look like assembler.
Hmmm... Kinda looks like 'C' (programming language).
Edit: And the 'asm' statements look like assembler.
You can use C to write assembly language. In fact the 8086 embedded processors (which is what intel uses) are largely programmed using C. I have quite a bit of experience in this field. I do not have an avic z1 or z2, but if you guys need a file looked at, or some code you need help with, let me know I would be more than happy to help out.
Maybe the assembler statements are there because this is source generated from a decompiler and the decompiler didn't know what to put in those places, so it just left the original machine code (in assembler).
Beep1: you actually program in assembly? A lot? 
You don't, perchance, have thick glasses and a pocket protector, do you? 
It's been years since I've done any C programming, and even longer for assembler (back in highschool). So I humbly bow out of the "avic411.com resident geek" race. It's all yours, buddy! 
Beep1: you actually program in assembly? A lot? You don't, perchance, have thick glasses and a pocket protector, do you?
I have taken a bit of a break from assembly, but I specialized in it in college. I took several advanced embedded classes. Aside from college, I worked on several projects wih embedded hardware. Mainly the intel 8086 embedded microprocessor and assembly language. I programmed with both assembly language itself (mainly MASM 32) and C programming.
The point is, most of the programming you write in assembly, you can write the same code in C. It is also a lot faster, and more powerful. Its easier to follow the logic as well. If you look at the C code there, you will see normal C programming logic, mixed with a bunch of code and registers you would see in assembly (such as the eax register).
And no, smartass, I am not one of those guys whos never seen the light of day or a womans touch. J/K, i really don't take any offense to criticism.
But, the truth is, you would never expect me to even know how to work on a pc. I come from a blue collar family and have a construction backround. I just have an interest in engineering and happen to be good at it.
ltl2007, looks like you are really motivated to figure this one out!
Before anyone decides to re-compile an exe file, it is better to try to get a picture of what is going on.
You mentioned, "statechangebypkbstatus"
It sounds like this means State Changed By ParKing Brake Status. What do you think?
What do you think the other one means? "drivingstatusbyinterlockchangedevent"
What is an interlock changed event?
It looks like you found a bunch of ISRs or something.
DrivingStateByPkbChangedEvent - It looks at the parking brake
DrivingStateBySpeedChangedEvent - The VSS signal maybe?
DrivingStateByZeroChangedEvent - ??
DrivingStateBySpeedDelayChangedEvent - ??
DrivingStateByInterLockChangedEvent - ??
DrivingStateChangedEventBase
PKBConfByInterlockChangedEvent
SkyStateChangedEvent - GPS Status No Fix, 2D Fix, 3D Fix - could be a catalyst for other events.
The interlock changed event sounds the most intriguing. Do you see this word interlock appear in any other files on the hard drive? Do you see this word "interlock" appear in any of the log files? Do you see it appear in the user preference file?
Does anyone here know a way to change the region settng for the Z1/Z2? The european unit seems to be bypassed by messing with the parking brake signal. So, is there a way to change the region? My car radio goes into an OEM programming mode by powering it up while holding down the power button and the input button at the same time for three seconds. Does anyone know if you can do something similar to the Z1/Z2 to get to the OEM settings?
It would be good to try to prioritize how to do this bypass.
1. Try to find a way to change something like an interlock setting via user controls - setting region, or some other OEM setting.
2. Try to edit the preference file on the hard drive. Maybe there is a line in there like, "SetInterlock=false". If that is the case, change it to "SetInterlock=true". That will only work on a user preference file, not a .dll file, or a .exe file.
3. If the first two fail, then try to change the .exe file. It looks like you have found the right area to do it by looking at ISRs. To do this, you can't just edit the file like one of those posters did. It isn't a text file. You have to recompile the code before you try it. It is a great score for our side that they left the symbols in the code!
It is very unlikely that the hack will be in a .dll file. A lockout of this type should be found in the application, not in a library.
The point is, most of the programming you write in assembly, you can write the same code in C.
I'd agree with you there, which is why I'm suggesting that it is the result of the disasembler.
You specialized in it in college? When did you have time for girls then?
Well, now that we've beaten that dead horse... Those of you working on this do know that this goes completely against the pioneer software license ("You shall not copy, reverse engineer, translate, port, modify or make derivative works of the Software.")? Not that I think that any of you are actually concerned about this, just thought I'd point it out.
hey guys. right on with what you guys are saying. There are a bunch of other lines as well. i will try to get maybe a text file or a pdf posted on a couple things. there are a bunch of things in strating to figure out with how the OS for the Z2 works. especially that all the changestate and doaction commands are only in 3 dll's. im going to try swapping the same dll's from a Z1 and see what happens!!
for anybody out there that needs/wants this, here is a breakdown of all the files on a Z2.
I wasn't suggesting that the bypass could be done in a dll or an exe. I was suggesting that the dll may hold the answer as to where it was looking. Like in a registry setting somewhere or even perhaps a file that is easily changed like a text file that is used on boot like an ini file. I too do a lot of code. Mine is mainly in logic. I program PLCs, DCSs and such for Chemical plant control systems. But I have had my fair share of programming in vb as well. Programming is programming you just have to learn the language. Typically it isn't too difficult to follow.
Hey guys. I downloaded the Z1 files in the PRG0 and PRG1 folders, and except for a few DSM files, the files are identical in name and quantity. they are not the same in size. If indeed there is a registry file or boot INI then most likely on the flash memory, like i was saying so long ago. I decompiled all the apps in the folders mentioned above, and they are different. Im going to try and swap them in my Z2 and see if it does anything
When I inserted a drive with the Z2 image into my Z1 unit the screen said "Updating program do not turn off power" Updating 1 of 2 then 2 of 2. While this was occuring the whole time I was hoping that it wouldn't wipe out the possibility of the bypass with the Z1 program. The Z2 program worked great many streets nearby that were not on the Z1 program were found using the Z2 program I didn't have time to check out any other possible updates from Z1 to Z2. I then inserted my Z1 HDD and the screen said "updating program please wait" update 1 of 1. I then had my Z1 reinstalled WITH the bypass. For this reason I don't believe it's on the flash memory unless the flash is updated with the HDD when they are changed and updating. I then reinserted the Z2 HDD and again got " updating program please wait" but only updating 1 of 1. the Z2 again acting as a Z2 no bypass. Now the next question is will the Z2 unit bypass with the Z1 HDD? It should 
HenryJ, no need to crosspost everything.
Yeah! most of us have no lives and read everything anyway! 
henryj, im going to swap exe's one by one tomorrow and see which one is the one causing the issue. or maybe two or more. hopefully its as simple as replacing an exe. i will let you guys know tomorrow. Also, when you were swapping drives, did the Z1 bypass work when the Z2 drive was installed?
ltl2007, No, the bypass or lack of bypass followed the drives/software. Z1 had bypass----Z2 no bypass in a Z1 unit.
henry, thanks for the info. im workin on swapping files right now. i have my fingers crossed!!
What if the bypass isn't a hardware bypass but maybe as simple as combination of keys pressed to access a hidden menu?
Could be something like holding down two buttons for 10 seconds, or something like that.
Has anyone tried this?
What if the bypass isn't a hardware bypass but maybe as simple as combination of keys pressed to access a hidden menu?
Could be something like holding down two buttons for 10 seconds, or something like that.
Has anyone tried this?
That would be pretty hard to figure out, and unlikely. We've already narrowed down the interlock being controled by the software, and usually these things have a solution that doesn't need to be done every time like pushing buttons. I mean, without insider knowledge that's pretty much impossible to know the buttons, how long to hold them, and when.
ok well i messed around with the dll's and exe's and all i got was either a no boot, an error, or constant restarts. im going to open a few Dll's in C++ and see what i can do. i think i found the line that we need to edit. ive attatched a screenshot, its the hilighted line. anybody else out there know C++ really well?
The HmiManager.exe file in the PRG1/APL folder is what I think controlled the bypass on the Z1, and when I replace that file the Z2 gets constant reboots. I can replace almost any other .exe and the unit will work, which makes me believe Pioneer made sure that we couldn't just swap that one file. I wish I had some programming skills, hopefully you guys will get it soon. Thanks for the hard work!
YzRacer, did you try replacing the HMIManager dll along with the HMIManager exe, the dlls from z1 to z2 although the same size appear to be different. They may need to be matched?
What if the bypass isn't a hardware bypass but maybe as simple as combination of keys pressed to access a hidden menu?
Could be something like holding down two buttons for 10 seconds, or something like that.
Has anyone tried this?
That would be pretty hard to figure out, and unlikely. We've already narrowed down the interlock being controled by the software, and usually these things have a solution that doesn't need to be done every time like pushing buttons. I mean, without insider knowledge that's pretty much impossible to know the buttons, how long to hold them, and when.
I would not say impossible. If someone can figure out that you need to pulse the Illumination signal at x seconds for y amount of times, then this doesn't seem impossible either. Just a thought though. Not being able to bypass is what is holding me back from upgrading my Z1 to the Z2.
Your effort is commendable, but you all are really headded down a dead end road. Your efforts will not pay off doing what you are doing.
Here is one suggestion... If you don't know anything about programming, it is better to ask questions than to act foolishly.
First. Do any of you know what a .dll is? It stands for dynamically linked library. It is a set of common calls that can be used by multiple programs (the .exe files). They are loaded by the program at runtime instead of at compile time by static libraries. They save disk space, and make the program more modular - that is an array of programs can now have a similar functionality, or a similar look and feel without a lot of added effort.
Second. You can't just open a few .dlls in C++, edit them, save them, and put them back on the hard drive. It doesn't work that way. How do you know that you are looking at C++ code anyway? I don't know the syntax of your disassembler, but you look for C++ "mangled" names (due to the c++ ability to do overloaded methods and such).
The disassembler may or may not work for what you are doing. It may or may not know about statically linked global variables, or vector tables and such. That means the code may not have the right offset and data and code may overlap each other. You may also be running a processor that is a variant of what runs on a PC, it may have a few different opcodes that the assembler may not know about. Because of those issues, you may not be able to edit a few instructions and then recompile and have it still run.
The more sure fired way is to use the disassembler to look at the code, then recompile the instructions you want by hand, and then use a hex editor on the .exe file to change those specific opcodes and operands indexed a specific number of bytes into the file. You use a hex editor because the bytes are not readable characters. How do you type the character 0x07 for instance? If you go that way, you can only change opcodes and operands in such that they take the same number of byes as the old opcodes and operands. You may need to pad with NOP opcodes. This isn't an easy process. I haven't seen your disassembler so far dissasemble any code, it is just showing you symbols. You can't edit the stuff you are looking at because you aren't looking at any code thus far.
The other impediment is lack of knowledge of environment. The GPS is most likely an NMEA stream on a serial port. What address is that port? Is it on the chip, or is it on an external chip? What is the chip select for it? What is the address range for the memory? How do you set those chip selects? How do you access the hard drive, or the file system? What variant of the intel processor is there? What ports does it have built in? Are there any differences in instruction set? You need to know that stuff if you are going to be able to recompile a .exe file. If the chip is an embedded variant, you might need a cross compiler. What compiler are you using? Are you using visual source studio, or a different IDE? Are you using gcc? if youa are using gcc, what backend are you using?
Basically, you aren't setup to do any changing of the code.
It would be more prudent to do a bit more investigation before you try to change the code.
Someone said there were log files in the unit. Why not try to do stuff that locks and unlocks the DVD playback, and then look at what was put in the log files? That is a much better place to start. Turn on the DVD player, let out the parking brake. Bypass the brake, play the DVD player, then drive < 5mph. Bypass the brake control, play the DVD player, drive > mph. Do the same as above, this time mess with the vss wire. Do a bunch of scenarios with different things bypassed, and then look at what the log file says.
The european version apparently doesn't have this problem. Do you think they wrote a separate version of the software just for that market? I don't. I'm guessing it is just the preference file change or something. Why not look at that avenue FIRST. Doing that is within your capabilities. Changing the code will require a steep learning curve.
Right now, it looks like the easiest way to bypassthe Z2 to try to get the european version.
party pooper