TTT

I am confident that it can be done.

OK and I also wanted my 500th post to be on my favorite running topic here.

 

Anyone notice this? Though not specifically for the C6, seems like they might have some useful info.

http://www.coastaletech.com/GMLOCKPICK.htm

 

Wouldn't that be interesting if it was that easy?!?!?!?!

 

I sent these guys an email a while back asking about their product for Corvettes. No reply from them yet.

 

Sorry to say, if you guys haven't found this magic PIN yet, there probably isn't one.

Mike

 

Rome wasn't built in a day.

 

Or a year... apparently.

Mike

 

Just talked to them and they do not have the product for our cars. They said they didn't know when, if ever they would have it available.

 

 

To be fair, I can count the number of our members actively working on this project on one hand -- with a few fingers to spare. All of us have jobs, a life, families, and all the other concerns of daily living.

I see enough code in my daily job that I really don't want to come home and work on it as a project. Being that it's machine code, I'm pretty far out of my element -- that was the only programming class I had trouble with in college and I just barely passed it. Not to be bitter, but I'm not encouraged to work on it when everyone else seems to have the attitude of, "let me know when you find something".

So, yes, it's taken a year to find "something" and progress is slow. It took us six months just to find the three codes I did find. I'm confident there are others, because after digging through at least a half dozen different loading.kwi files, ours is the only one I can extract valid codes from -- but that doesn't stop other forums from finding codes that work in their systems. There's a lot of good information in this thread, but I see few people making a serious attempt to build on what SonarTech, myself, Buffy, and a few others have discovered.

What I'm trying to say is, if you aren't actively helping, I don't think it's fair to criticize the rest of us for taking too long to make progress.

 

I called this company today. Ship them your head unit, 1 day turn around $300.00 The only problem is that they are out of stock for 8 weeks
http://avelectronic.com/products.htm

 

Folk,

So there were a couple of codes mentioned earlier in the thread that had some effect. Specifically 660, 9448 and 295660.

I grabbed NAVUpdateFiles.zip from earlier in the thread and did a quick search for all 6 digits numerics stored within the LOADING.KWI and I've output them below for posterity. 9448 and 295660 show up here.. 660 doesn't.. so it's at least partial confirmation of the method.

This method should grab any numeric that's stored in the binary and is used for comparison (i.e., compare user input to that of a code list). What it wouldn't catch is if that comparison method included a rolling code. In other words, if the Denso engineers designed the system such that the appropriate code as based on the date/time/etc.

That could be figured out also, with IDA pro.. but that's beyond the scope of my caring.

Anyway, for posterity, here is a list of the 47 unique numerics in the LOADING.KWI I found of which there are 2 that are apparently verified.

Enjoy:

strings LOADING.KWI | egrep '^[0-9]{1,6}$'|sort | uniq
0033
0066
0080
0405
0514
0519
0618
07070
08080
0920
1001
11100
1412
1620
1791
1922
2222
295660
3060
3122
323333
3311
33311
3333
333333
3337
4108
4154
4441
4443
4554
5555
6666
66665
666666
70070
7774
7777
81791
8660
8888
89448
9311
93393
93939
9448
9999

-jbl

 

Ok, I've just tried all of the codes, none work beside the ones we already know.
When you type any of the code, you just go back to the menu. Unless one of these do something and just go back to the main screen without displaying antything.

Guess we'll have to look further...

 

I wasn't trying to criticize anyone. I was only pointing out that you guys may be doing a lot of work for nothing. It is possible that there is no code to do these things, and the more time that passes without a solution, the more likely that is.

Mike

 

Been a while, and I don't expect anyone to have read the entire thread, but this has already been tried. Both on the loading.kwi file and the binaries we extracted. That's how I found the three codes we know today (660, 9448, 295660 and 1791 all occur several times in the loading.kwi file and almost always right next to each other).

However, using this method on any other loading.kwi file I've found so far turns up no working numbers, not even ones previously known.

Ida Pro is beyond the scope of my knowledge, but I can give my copy to anyone that can use it along all loading.kwi files I currently have.

 

re: Ida pro. I've a licensed copy sitting here to my left; unfortunately I'm guessing that I don't have the right CPU model that's used in this Denso unit.

I've not looked hard to see what CPU is being used yet though.... then the reality is that LOADING.KWI more than likely has a couple of portions to it.. i.e., compressed and uncompressed data... it's highly likely that there is something like a tar hidden in there somewhere.

The quickest way I can think of to determine that would be something that byte-walked the file and did a comparison at each offset to a known good (i.e., full) /etc/magic (unix-ism, used by the 'file' command).

With that said, I'd -really- like to disable the inability to use NAV whilst moving... best case, I've got a passenger in the car that can use it.. worst case, I'm being a dumbass trying to program it myself whilst doing 80mph. I think I should have the right to make that call.

Perhaps sometime I'll dig into that.. but without the ability to run the code on a unit and break into it with a debugger, it'd be fairly difficult to randomly find the right bits to twiddle with or without IDA Pro.

anyway....

-jbl

 

Hmmmm... Ok. I'd read, or at least glossed over, the thread. Guess I missed how those codes were found.... figured I'd try to toss in .02c of usefulness.

-jbl

 

einTier, I'm not quite familiar with Ida Pro but I have worked with dissamblers before and I have programmed in assembler. It's been a while though, so it might take some time for me to get all this back but I'm willing to give it a try.
Can't guarantee that I can come up with something interesting (or even with anything at all), but if you can give a copy of Ida Pro and sum up to me what you've done so far, I can try to jump in.

I guess the way to go would be to see how and when in the code it switches between "input enabled mode" and "greyed mode" and see if there is some sort of test on top of the speed check. Then look for what other element is being tested there and see if there is a way to change that element somewhere else in the code.
Seems easy as it's said, but I know that coud be a hell of a task to figure it out through thousands of line of code, especially in assembler.

If the ability to input destinations while moving is not built in the current code, then we'll have to program a patch to add it. Now that would be even more complicated to do and probably too complicated (for me at least).

 

Now you're going to make me dig through the thread. Buffy wrote a KWI converter and pulled out a couple of files. We also have the .gc0 file that wrote the mp3 software in. Sonar Tech in the Cadillac forums actually took his nav apart and took pictures. It's different, but these systems probably all use similar processors -- the code is too similar across so many different nav systems the original SDK can't be much more than a "building block" style of software development. If I have some extra time (unlikely in the next few weeks) and feel brave (likely) I can try to do the same.

 

Well, the system seems to disable any (most) inputs when it detects movement above ~1mph. More than likely the right thing to do would be just to add a nop (no operation) to the function that does that checking.

However, hacks like that are best performed when one can debug live against target hardware. I've been pondering on the right method to attack this problem....

-jbl