yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] golgothagecko:
Has anyone tried...

Hi,

I unzipped the latest Kenwood firmware updates. In that file structure there is a /system/app folder which holds all the .apk files. Has anyone tried embedding different apks in there and then uploading that firmware to the unit?
[Android Head-Units] ScottyMCSE:
I have no issues whatsoever with my 990. The only issue I have is a firmware issue since the last update. The SD card slot stopped working. Kenwood and I are working on this problem right now. Other than that, no problems at all. I also have the backup camera working with no problems. Everything works including Bluetooth.
[Android Head-Units] kwarwick:
Wifi connection problems?

OK, this is starting to drive me a little bonkers.

I setup my DNN990HD to connect to my Nexus 4's Wifi tethering which is configured with WPA/WPA2 authentication. The Kenwood unit can only connect correctly the first time but if it gets disconnected anytime after it will fail at attempts to reconnect. It will keep cycling around trying to connect, failing, (often with an authentication error) and tries again. If I power cycle the Kenwood it will connect successfully immediately after it boots up again. I've deleted and recreated the Wifi configs on both ends and no matter what I do this problem persists. If I turn off the WPA/WPA2 authentication on the Nexus 4's tethering config the Kenwood can connect over and over again without issues, but obviously having my phone broadcasting an open hotspot is not a viable solution.

So this sounds like a WPA/WPA2 authentication problem on the Kenwood side... except that I can connect-disconnect-reconnect without issue to my home Wifi configured with WPA2 whilst parked in the driveway.

So then it seems like something wrong with the Wifi tethering of the Nexus 4... except that it works fine for other devices that tether through it... including another Android tablet. WTF, right?

I read about other devices running Android 4.0.4 experiencing similar Wifi authentication problems when using WPA/WPA2, but no one actually has a solution from what I've been able find.

So at this point I'm mostly wondering if anyone else has experienced this problem and perhaps found a work-around?
[Android Head-Units] spongebobmoviept:
i did extract and try to inject a few .apks into the update buit the update fails
[Android Head-Units] swyner:
Anyone having any luck with cracking this? I would love to have some more options on this unit!!! Developers WANTED!!!!
[Android Head-Units] siralsmooth:
While I'm no developer, just from dissecting the update file, it appears to use a script to kick it into recovery from the update file itself, which means there's no recovery embedded on the unit itself, which sucks. Another thing I noticed in one of the files is that per the verification checks, there is what I believe MD5 checksums for all the files being updated, which explains why just adding APK files doesn't work. The only other though I had would be to replace the settings.apk with a standard one from an AOSP rom, maybe then we can adjust a few other things.

As for gaining root and other apps, I think a custom update hacked from the kenwood update will be needed to access a recovery console, or maybe even boot CWM from the update? If we can get the update to boot to CWM, we're golden.
[Android Head-Units] kwarwick:
I too was thinking along the lines of replacing the Settings.apk in the update with a non-neutered version so that we can turn the Unknown sources checkbox on in Security. I wonder if that's all we would need or have Kenwood perhaps disabled that feature completely in the Kernel or something?

I found the following in the MANIFEST.MF file:

Name: system/app/Settings.apk

SHA1-Digest: 2R8P8JhUG6SmdxFxP16FMz5R3A4=

I'm wondering how hard it would be to replace the Settings.apk in this update with a copy of Settings.apk from a pure 4.0.4 android install, calculate the correct SHA1 fingerprint for it, and update this file?
[Android Head-Units] swyner:
Sounds promising. I am not a developer either but don't mind tinkering around with this stuff (on phones usually). Would love to help if I can guys...
[Android Head-Units] Flame Red:
I had a similar issue on my Galaxy Note 2. When I tried to oair it with WPA/WPA2 required it would cycle as you desribed. If I paired it with Opened it would pair and work. I found that once it was paired under Opened I could cha MNge the phone back to Wpa required and it paired fine even after reboots.
[Android Head-Units] pdanders11:
JTAG Rez

Hello. I don't want to sidetrack the root effort but this may come in handy if a unit gets bricked here and there. I have no idea what if any risk there is in Chris's root.

Today I have establish JTAG communications with the processor via the unused 20 pin connector on the bottom of the board. Right now I'm reading the Flash on a bootlooped unit as my test subject. If I can pull the NAND from the bad card, I will switch over to a new HU and dump the flash on it and try to move it to the boot looped board. Still playing with a lot of the JTAG tool options as this is obviously is not directly supported but there is nothing to keep me from using the tools generically.

Still very early in testing but some progress on JTAG.....
[Android Head-Units] chris.davis925:
nice! I tried to interface via JTAG and was unable to. Can you upload pictures of the connections with labels?
[Android Head-Units] justmpm:
Hi Everyone,

I did a little thread cleaning. Please be aware that donations are donations but selling is something else. Asking for "donations" up front for development is against xda rules, so please report it to the moderators when you come across it.

Thanks!
[Android Head-Units] funkytrone:
Public Release

Any date on when the procedure to acquire root will be released to the public? :D
[Android Head-Units] pdanders11:
Can anyone who has gotten "Kenwood" to show up over the USB 2 Go port help clarify the voltage on pin one of that JSF connector?

If I read the thread right pin one is USB power on the boards that OTG works on.

I can't get in via OTG and on my board and pin 1 does not want to see 5 Volts. USB power sees a heavy load on this line and I see the line hanging around 1.2V and dumping some major heat in the wire if not over currenting the USB port. So either I've mis-read that pin one is 5Volts or this is the mod Kenwood did to disable the port. I just haven't been hooking up this wire and getting "unknown device" but maybe thats not right. I downgraded to 1.3 and up to 1.5 and saw no "Kenwood" port.

Some thought and theories

- Driving 5 volts into a modern digital board is odd. 3.3 is probably the max VCC a part runs at nowadays so needing 5 volts seems odd. Maybe this pin needs 1.2Volts?

- could this pin be driving the Telechip OTG power/control pins (luckily through current limiting resistors and USB power limits) OTG core power is 1.2 per spec and protection diodes could latch the 5V at 1.2 plus a diode drop thus drawing high currents and dumping a lot of power/heat

- probing around on my board pin 1 on the OTG connector measures a short to a 0 ohm resistor at each USB cable connector connected to I believe the shield (Ipod, USB, wireless connectors). Essentially a short to ground. I wonder if these 0 ohm R's are installed on the boards with work OTG? The 0 ohm on the wide/dual USB is on the top right at the connector visible if removing the heatsink. The single USB 0 ohm R is on the bottom of the board.

- pin one seems to lead to biasing 2 R's on the processor. Maybe OTG ID Enable and R tune?

Hearing OTG works on some boards and not others with he same firmware says hardware mod. If some people are truly tying to pin 1 to 5 volts with no drop, this may help lead to the OTG mod by Kenwood.
[Android Head-Units] pdanders11:
on this pictures on thread 148 I see the 0 ohm on top.

http://xdaforums.com/showpost.php?p=50160524&postcount=148

[MENTION=2301266]aplusmiami[/MENTION], can you help me out?
[Android Head-Units] siralsmooth:
Just wanted to thank the mod for stating what I, and I'm sure others, have been thinking. While I don't have issues with donating to the cause, charging for a root exploit, or jailbreak, just seems a bit pimpy, and isn't what XDA is all about.
[Android Head-Units] pdanders11:
serial port

I've also found a serial port on the test connector where JTAG is. 115200 TTL

It just has some boot stuff and I can't figure out if the RX to the CPU is hooked up or if I don't know (if there is) a key combo to stop boot. Is this like u-boot? would trying to crack this interface help us get in to root the device?

I'll get the JTAG and serial info out shortly. I was hesitant with the direction this thread was going before the Mods cleaned it up.
[Android Head-Units] aplusmiami:
Not sure why we are still messing with the USB ports, I thought these eventually cause the unit to lose root after a few reboots. Are we still trying exploit this through the USB connector on the board?

The web exploit seems to be working. I think it is up to Chris what to do with it since he came up with it.

In any case, I still have the unit on my bench and can take whatever measurements you want. Please post the specific test points in a pic so we can continue documenting.
[Android Head-Units] pdanders11:
I would just like to understand the initial root that was established on the unit.

Here is my understanding of gaining adb access which I assume leads to gaining temp root.

1 - Hook up the JSF USB connector to a PC. An unknown device will appear Linux CD Gadget should appear

2 - start a firmware update

3 - sometime during the update a new USB device "Kenwood" should appear in windows

4 - push the the updated build.prop

5 - have adb at least temporarily

I'm stuck on 3. Really #2 no that I re-read your post. I get no VID or PID over USB for the "Gadget" driver to attach too but I do see a unknown device. You swapped the wires to fix this but it doesn't for me. The USB Power and Ground just behave odd on my boards so I'm starting there.

So I'm on firmware 1.3 and update to 1.5 as you did and "Kenwood" never shows up during the update. Reading between the lines it sounds like Kenwood started blocking this exploit. Being a HW guy, I see same Firmware, same PWB, same layout, so Kenwood must have made a HW change to "break" the OTG interface. Maybe I'm naive but it only seems like a handful of hardware mods that Kenwood could have made to break the OTG interface with old firmware.

In the picture can you tell me on your unit that displays "Kenwood" during updates

1 - is the 0 ohm on the left circle installed

2 - in the middle circle, can you measure the resistance of these R's and tell me the voltage with and without your USB connection made.

3 - So on the CN902 connector, I would just like to verify you are applying USB 5 volts to this connector and you measure 5 volts. I get a high current draw and USB power drop to 1.2V

Just wondering if the resistors in the middle circle are pins on the CPU. I find a path from CN902 pin to these R's and I'm wondering if they changed these R's or the voltage to these R's to break OTG.

- OTG_ID

- OTG_REXT

I appreciate your time to help me play catch up.
[Android Head-Units] aplusmiami:
I had to dig everything up but here is an image of my results (Attached)

Interesting thing - I now longer get Linux Gadget - I get Unknown Device -

This may or may not be because of Chris root?

I do not want to attempt the flash because I do not want to lose root.

I have another unit in my wife car that is stock. I am going to give her this rooted unit and i will try to see If I can get the Kenwood in Device Manager Again. I think what Chris previously said is correct - Kenwood/JVC has really locked down these devices and possibly implemented intrusion prevention?

Also i see two spots on the board where it looks like there should be some components there? Maybe this is an additional port? I have them pointed out in the drawing - Hope this helps. A Public root or at least more information on how to set it up might encourage more development on this unit.

Android seems to be the direction all the major mfg's are going in... So sharing the knowledge in these early stages is the key to opening the door to development. Look at cellphones and the tablets... Hell I just brought back to life a old Asus tablet that once was dead with info from here.
[Android Head-Units] aplusmiami:
NC = No Connection CO= Connected
[Android Head-Units] pdanders11:
Thank you. I will review when I get home.

But on the otg connector you show 0 volts connected and not connected for pins 1 and 4. So are you not applying USB power to the otg connector ?

---------- Post added at 07:15 PM ---------- Previous post was at 07:02 PM ----------

Just fyi but on the other forum Chris has stated he is not releasing root.

So we need to get back to work.

Anything you can provide to get temp root that was jointly accomplished in XDA, would be helpful. I'd like to look at the partition table and dd the nand before doing much more in JTAG.

Other crazy ideas in my head is changing the boot mode to sata. Boot mode appears to be strapping resistors. If I dd the image and move it to a sata drive and change boot to sata maybe I can get out of dealing with raw band.
[Android Head-Units] aplusmiami:
Yes 5V is there but the not when the unit is plugged in. I still get unknown device with or without ground and 5v.

Chris probably does not want public the holes he has found since Kenwood probably has guys monitoring these forums and will attempt to plug the hole. From what I heard 1.5 is it - there will be no more updates from Kenwood on this device - at least that's what a Kenwood dealer told me he heard. They want to push the 991HD.

Hopefully you and chris can work together on a hardware exploit that makes it easier to root these units.
[Android Head-Units] pdanders11:
I'm 99% sure power doesn't go to this connector.

The outer pins are

Ground and OTG ID or shield.

Hence my issue driving to drive 5 volts into low impedance / ground. Any idea if you were using a un-powered hub?

Could you just take your USB cable with nothing connected and measure the resistance between 1 and 4 on the JSF? Long shot but if this is the OTG ID pin 1 and 4 can pin shorted or multiple resistances are accepted. Did you have to add a resistor to the cable? Or did you start with a 5 pin USB cable?

I appreciate the info and going back through the thread am impressed how well you documented your findings. I'm finding I'm re-hashing somethings and I apologize for that.
[Android Head-Units] pdanders11:
Nevermind.

Yes, 1 and 4 should be shorted and USE GOOD USB CABLE AND HUB. Signal integrity on USB is tight! No USB power to the Kenwood connector!

Also i was able to push and pull via ADB during the update. Do Not pull the USB stick at anytime as indicated earlier in the thread.

After pushing the build.prop then I see File-CD gadget :)
[Android Head-Units] pdanders11:
I have to go to work and I apologize to those who have "been here, done that" but I have most likely re-invented the wheel with some new notes I missed or wasn't posted.

1 - No USB power to USB OTG connector

2 - good cable pin 1 is GND, pin 2 USB White, pin 3 is USB Green, Pin 4 is ID (short to ground)

3 - if you just get unknown device at least on 1.5 or earlier firmware, check your cable. You should get a VID and PID in Device Manger

4 - as previously stated, during update, "Kendwood" device appears. hack or force google adb drivers to override and push the update build.prop. I did it early in the install. timing may be important as there may be a race condition with the update but I got luck on try one

5 - after the update KenWood/ADB shows up on every boot. Thanks [MENTION=5389783]donaldta[/MENTION] for the build.prop lines to add and all the other info

6 - as many probably know poking in the update.zip "su" is already installed.

7 - standard stuff from here. Mount system rw and start adb push and pull

--------------------------

This is where I'm at. I adb installed ES File Explorer and returned with "Success". Not sure how to launch it yet. I assume I'm looking at the kenwood gui and not the true android desktop so I don't "think" I should be surprised I don't see it on the home screen.

I'm not really familiar GUI interface with the unit but Android plus Idatalink to Ford sync plus garmin maps was enough to put one on a bench and play with it. So what I can do on my own vs needing help will be spotty.
[Android Head-Units] docmo:
After Chris's root, sideloaded apps appear in kenwood launcher 4th page in the app drawer. Hopefully it's there for you.
[Android Head-Units] pdanders11:
I guess I should state i'm starting from scratch with the info in this thread up through OTG adb. Other then what is in this thread and distributed in this thread, I am using nothing of Chris'. I didn't pay for Chris's root nor will I. Other then a return pm asking for $100 to beta test his root there has been no interaction.

On the other forum, Chris has said he left XDA and will not make his root available here.

I'm doing this on my own with the help of XDA members.

I want to verify some things myself and move towards a free root.

---------- Post added at 08:19 PM ---------- Previous post was at 08:03 PM ----------

So dumb question .

Difference between su and root? I have su. What makes it root?

So per this thread after multiple reboots my build.prop will just revert back to not having adb etc. Any idea how many reboots? Any idea if this is a random check by software or does the unit connect to Kenwood over Wi-Fi and trips flag ?

Where is the new image pulled from ? Is there a golden partition?

I want to see if there is a golden partition and see what trips the rebuild. Maybe mod the golden partition or block Kenwood IPs via the host file after doing some wire shark.

I won't lie, I find some info Chris provided as fishy or leaving out important details. I may be wrong but I'll let you know everything I find.
[Android Head-Units] funkytrone:
Share Rooting Technique

It does not make much sense to only share the technique to root this radio with those who donated and not release to the public. If it is to prevent those at Kenwood from patching the radio to prevent obtaining root through this exploit they can either just figure out how it was done, if they are monitoring this thread they will know there is a way, or, for all anyone knows, they could be one of the people who paid Chris to root learn his technique. Anytime someone releases an exploit there is always risk of that exploit being patched. Exploits, hacks, and all other sort of awesomeness would never be shared out of fear that the next patch will render the exploit useless.

I greatly appreciate the continuing efforts to find another means to root this radio, in the meantime, could someone else perhaps share the technique they obtained from Chris since he decided to mysteriously not share it and :confused: apparently quit XDA forums. I'm baffled why the guy went through all the effort to figure this out, profit, and then not share with anyone else. Sharing is kind of what makes XDA amazing.
[Android Head-Units] pdanders11:
So I put a relay on 12 Volts accessory to the radio. Have a PC toggle the relay off for 2 minutes leave it on for 10 minutes.

Still no build.prop overwrite after 2 hours. So roughly 10 cycles.

Is Kenwood wiping changes or is dirty car power causing random corrupting of NAND and the system is just rebuilding itself. Cars are known for terrible power (cranking down to 10 Volts and charging upwards of 14 volts). Not something a decent bench supply would exhibit.

---------- Post added at 01:30 AM ---------- Previous post was at 01:01 AM ----------

Doesn't Parking SW = GND mean the car is in park and safe to play with the radio? And Parking break open = limited control of display?

Or do I have this backwards.

Or did Kenwood implement adb the opposite which is a little clever. I have to disconnect PARK SW from Ground to for ADB to come up on power up. It seems like it checks it at boot only . Or it's just my crappy USB cable. :)
[Android Head-Units] aplusmiami:
There was definitely 5V on my cable plugged directly into the PC. Probably the Mobo has some sort of short protection?

---------- Post added at 05:08 AM ---------- Previous post was at 05:04 AM ----------

from what I remember the parking brake has to be grounded and you should see the kenwood appear under device manager during a flash update. change that to a adb driver and you should now be talking to the device. Only problem is I have not been able to replicate this since temp rooting my radio and subsequently applying Chris's Web based exploit, which seems to stick.
[Android Head-Units] siralsmooth:
Damn, super shady. Figure out root, charge for it to "beta test" (wtf) and then disappear? Now I really want to see someone else figure this out. One thing I will say, having worked for dealers of Kenwood excelon for the last decade, I've only seen a warranty claim denied for physical abuse, never for a software issue. Hell, the older units had a bootloader that would eventually damage the eeprom if not updated in time. So don't let the thought of bricking your unit stop you. If my boss would let me take a unit to mess with I'd devote more time to figuring out root, but we tend to sell out quite often. Not to mention, the new 991 model is out now. So good luck with this.
[Android Head-Units] aplusmiami:
Not defending Chris but I am sure he helped a lot. No where is it written that you must share your knowledge he individually came up with. Maybe he plans to sell the exploit and if so he just can't do it here. I didn't have a problem with him asking for money. We where off trying to figure out a way in through hardware while he went the browser route. So he obviously found a previous android browser exploit and made it with for him.
[Android Head-Units] pdanders11:
I'll respectfully disagree. He gained much knowledge from the forums from people like [MENTION=5389783]donaldta[/MENTION]. Without this forum, he would not have root today. Therefore he should follow the rules. I see it plain and simple.

You can't release nothing and ask/require money first. If nothing else release the files even encrypted with no instuctions and say here is what you need for root. Then people can to what they want. Try to figure out his stuff or donate for the stuff and contact him for install help. Still sneaky but I think it's better then what he did.

Like I said I am finding conflicting info, also, which leaves a even worse taste in my mouth but lets move on. If you want to change the rules talk to EDA. Debating it here just distracts us.

---------- Post added at 09:40 PM ---------- Previous post was at 09:36 PM ----------

EEPROM, interesting. In the serial log I think I remember seeing a firmware update count. I've lost ADB over USB after it was solid for a day but i accidently dropped a updated usb stick in.

I see there is a store/recall settings in the unit. Wonders if that goes to NAND or if there is a EEPROM. Maybe they are counting firmware updates and killing OTG after x updates.
[Android Head-Units] aplusmiami:
Yes lets move on... I agree. I will have my virgin unit out of the car sometime tomorrow. If I can get some time I will get it all hooked up on my bench.
[Android Head-Units] siralsmooth:
The restore and recall setting is for audio and video settings. Eq settings, crossover, backup camera, video in and out, etc. It does write the settings, so its probably writing them to some sort of eeprom. This has been a function on kenwood video units for years. Also worth mentioning, older video units, 4 plus years old ran on some sort of linux, from what i could discern from the updates files. The newer models, in the last 3 years, run a windows CE core. There was a bug that exposed a hole to get into the main OS, but it was quickly fixed, before i found out about it.

---------- Post added at 10:05 PM ---------- Previous post was at 09:45 PM ----------

Any chance this would work?

http://xdaforums.com/showthread.php?t=1886460

If you could push a modified build prop through during the update to enable adb and unknown sources, this might do the trick.