yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] pdanders11:
[MENTION=2301266]aplusmiami[/MENTION] Is the Unit your pulling "old" like one of the orginals off the shelf vs mid-year or re-furbed when Kenwood would have time for a HW mod?

I found a "sloopy" solder job including a lifted/pulled pad on the USB OTG circuit. It's not well cleaned so I'm speculating (again) maybe they changed or removed something in the circuit the makes OTG flaky if not disable-able by the firmware.

I wonder when we update we get a new kernel for example but when we downgrade we keep the new kernel and downgrade android. This would give a board one upgrade opportunity for OTG to enable. Without the mod, maybe all the time.

I'm going to upload a pick and you or anyone who's pulled this board want to take a look, I'd be interested.

On another front I'm looking into FWDN. If I read about telechips else where everything is talking recover/brick repair via FWDN. From what I can tell it sounds like the equivalent of Samsung's ODIN. Telechips released a eval module at on time and FWDN was enabled via the BM pins. I'm also going to try that as I have one bricked board.

Overall I think like [MENTION=4446386]siralsmooth[/MENTION] has pointed out, there are documented vulnerabilities in Android 4.0.4 that were never fixed. Google would have to fix them not Kenwood. And Google would just update in the next pass of SW and not fix old SW. So I think we can find something out there. Since Chris mentioned it himself early on in this thread, there is a web View exploit that will let a app with no permissions give you shell access over TCP. The question is how to get the app on the kenwood. Just pointing out exploits are out there and not closed so I don't think we are as dire as some made it sound.

---------- Post added at 04:17 AM ---------- Previous post was at 04:02 AM ----------

so check this out on the bottom of the board.

Circled are 2 resistor (or I guess could be a cap ) pad. On the left is a 22K resister. But right to it right on my boards is another pad and I can see it was a re-work job. The even pulled the pad on this board.

Could be a mod from day one but I doubt it. Looks like a hand removed part after part placement. Would love to know what if anything was there and if what is on the right has always been 22K
[Android Head-Units] aplusmiami:
LCD

===================

1 - GND

2 - DATA + GRN

3 - DATA - WHITE

4 - NO CONNECTION

===================

Back of Radio

I get Unknown Device - This is on a Radio that has been rooted using Chris exploit.

I do not want to flash - I have another (not rooted) radio I will check in the morning.

Just to confirm you do not need the 5V from the PC

You need just a ground and the Data +/-
[Android Head-Units] pdanders11:
Holy Crap! Either this was the flukiest event ever or I just found the OTG RESET resistor!

Probably the former but I shorted the empty pad and it killed the OTG completely. No Unknown devices or nothing.

Took the short out and BAM Kenwood is back. This is on a PCB dated year. Going to try to push build.prop. If that works shorty it out on my other board.

Have no idea what this would do though.

---------- Post added at 05:10 AM ---------- Previous post was at 05:03 AM ----------

I may have had the wires crossed earlier. Honestly I keep swapping plus and minus as I scratch my head.

Completely understand. I don't want you to touch your rooted unit.

---------- Post added at 05:38 AM ---------- Previous post was at 05:10 AM ----------

Got build.prop pushed and USB debugging menu is there but OTG is "unknown" again. Trying second board.

Thoughts?

- will build.prop open wifi adb

- still not good with the GUI. how would I try to load new APK's without adb? others said they did it and got the error. Will build.prop elminate this?

- maybe i need to push ALOT more then build.prop. would love ssh or telnet

---------- Post added at 06:02 AM ---------- Previous post was at 05:38 AM ----------

2 for 2. Completely dead OTG ports for 1.5 days. Try cable after cable mod. Instead short pad (I don't have the skills to do much more then short a pad at with these size parts) and update and remove short and update and OTG is back. Need to figure out what that goes too. Not sure if the update with the short was required.

BTW shorting random pads is not recommended :)
[Android Head-Units] aplusmiami:
I've noticed also that this unit acts wacky. Sometimes I lose connection completely, then it magically appears as an unknown device. Might have to do with the 1.4 update to 1.5? The other unit has 1.4.. I will confirm this tonight if I get Linux gadget again. I will download the firmware for 1.4 to test the flash.
[Android Head-Units] pdanders11:
Yeah, it's bizarre. I find it interesting kenwood took the other connector off on new boards but left this one. Tells me they use that port for initial programming, test, or repair so I doubt it's "dead" but they did something to make it at weird under Software control.

So I have firmware 1.3 and 1.5. Don't see a reason to go newer but I've read there wad a 1.2 and you mention 1.4. I'd be interested in finding older firmware then 1.5.

I've verified build.prop update doesn't take adb over wifi of our offline mode. Bummer.

I think I need to write a script to push more then buil.prop. I think this would fall in line with what [MENTION=5389783]donaldta[/MENTION] gave some adb examples of. I just wish it was documented what he found remoting into Chris pc. There is talk of a script by Chris after this session. Did you get a copy of this by chance? I think it's fair game to share if so because temp root was discovered on XDA.

I just needed the adb commands to make android see the newly pushed apk. Unless android truly just tries to start every apk which doesn't seem right. Seems like there has to be a command to make the apk active. I found " adb start am ....." command which sound close but I have to find the cryptic apk names like com . android . junk and a activity name. This is what I'll be reading up on if there isn't a script available for whatever reason.

Thanks for helping out. It seems you have what you need with root but keep helping here. Appreciate it.
[Android Head-Units] aplusmiami:
I noticed a lot of the post have been removed. I will post the commands I documented later.
[Android Head-Units] pdanders11:
Thanks.

I've pushed apk 's into system/apps and I've tried adb install. Both seem to work but the launch icons aren't showing. Not sure if I'm missing a command or a simple gui sequence to pull the app to the one of the home screens.

I tried copying a pushed app over a stock app also but that didn't work. I'm missing something probably simple. Thinking of a android phone, I should just hold on the screen and it would pull up all apps and let me drag the pushed app to the desktop.
[Android Head-Units] aplusmiami:
Well I am stumped - My other radio all I get is unknown device. No linux gadget no Kenwood during flashing.
[Android Head-Units] pdanders11:
Is that resistor a few posts back missing? How old is the unit?

Sounds like how mine were behaving. I found a full schematic and spec for a newer telechips cpu. Will be differences but hopefully some insight. Out if town but will get back at it tonight.
[Android Head-Units] aplusmiami:
I'm stumped... both units got the Linux gadget at some point. I only messed with the one after that. I just tried another computer same results.. frustrated!
[Android Head-Units] aplusmiami:
There is only one resistor present on both of my boards.

---------- Post added at 02:35 AM ---------- Previous post was at 02:30 AM ----------

Tried a new cable - Still no go.. The only thing I can think is I somehow damaged the ports swapping wires.

What if we just start looking at the browser exploit?

Chris made me agree not to discuss much of what he did however he did post (it is still there) that their is a browser exploit used on older versions of android and then pushing some sort of Java Script to the radio. I think his post is on page 25 or something.
[Android Head-Units] aplusmiami:
I'm a bit confused? Which connector is removed on the board for you? CN???.

When you said you shorted the pad which one?

Do you currently get unknown device - ?

Can you ul a pic with the specific pad you shorted?
[Android Head-Units] aplusmiami:
build.prop

This is the build.prop file I used
[Android Head-Units] pdanders11:
Neither of my connectors are removed on the refurbs. CN102 is removed on a new board

It's in that picture. I'll go point it out. basically there are 2 resistors side by side. the on on the right I showed a ripped off pad but I was able to short across to the via still. I'll get a pic.

Have you done a clean firmware update without pushing a build.prop? I just did and adb came back in regular mode but of coarse no debugging mode. Next time or if you USB seems dead, try a clean flash of 1.3 and see what happens.
[Android Head-Units] aplusmiami:
I see the pads with the missing resistor. So you are saying you shorted this and USB started working again?

Currently I can not get Kenwood to show up at all in device manager during a flash update. I will try to downgrade 1.3 and see what happens.

During Radio boot up I USED to see Linux Gadget in device manager , Do you get this?
[Android Head-Units] pdanders11:
1 - yes, i shorted the missing resistor pads but can't rationalize in terms of why. I've been thinking aloud maybe too much but can't even BS a good reason for this on. Can't find where where trace comes from or goes to. Since it's sandwiched between boards doesn't help.

2 - i would try a clean unmodified upgrade/downgrade first. It's been so long so I had a unit unmodified, I forgot Kenwood should appear in Device Manager with clean firmware. As I just posted, the rebuild(s) and the build.prop update is doing something wierd when not done in both windows of a update. I got lucky and spaced out and let a clean update go through on accident and brought me full circle. ADB with un-altered Firmware and files should show a device in Windows (Kendwod) if the cable is good.

3 - Linux Gadget doesn't show until AFTER the build.prop is properly inplace. I have not seen it without a modified build.prop. I think you mentioned that earlier you weren't sure if it was before or after the build.prop. It it after.

What a journey to get back to where you guys were 3 months ago.

Side loaded apps are showing and everything until a storm warning chased us to the basement, I think I'm about to have Su update itself and have temp root.

I "think" I know where a resistor is to change boot mode to USB. The Telechips VTC drivers installed so I'm playing with that on the side to. Seems to have a watchdog as the unit turns off after 10 - 20 seconds.

This still may sound disappointing as going through OTG but I think exploiting from the inside out vs outside in is easier for me.
[Android Head-Units] aplusmiami:
I am trying to get back to where I was 3 months ago.

I got Linux Gadget after reversing DATA +/-

I got Kenwood during a flash update and PRK SW (Light Green) grounded

I can no longer get either of the two.

Please confirm your connection for CN902 for me:

TOUCHSCREEN

=============

1- Ground

2- Green

3- White

4- Ground

=============

RADIO BACK

How did you short the pad without removing the pcb?
[Android Head-Units] aplusmiami:
Side note: if the update file is a

update.zip = It will launch automatically

update.kw = launch from the settings -> software menu
[Android Head-Units] pdanders11:
Yes that is what I have. I have soldered the wires so this is correct.

So a clean flash didn't bring the usb ports back? Unit is in standby also right?

My PC likes to think the kenwood device is a Mass storage device and assigns it a driver so it was a little tricky to find. It didn't yellow exclamation a kenwood device. Instead of looking at device manager maybe try this program.

USBdeview

Google it. I can't paste from this dumb tablet.

Yes I had to remove the board. A bit of a pain. However I almost convinced the usb port is reliable but software is turning it on a and off. Maybe review the build.prop changes and remove them and push that to the unit. Maybe it's a Dos Unix problem or permissions.

---------- Post added at 02:52 PM ---------- Previous post was at 02:41 PM ----------

I'm guessing this is the exploit Chris mentions long ago.

http://www.rapid7.com/db/modules/exploit/android/browser/webview_addjavascriptinterface

I messed around a little with it using examples.

Your right in the end we need a wifi hack or a usb update mod

Do you know where code that scans the files are? Is it recovery on the radio or is it in the code in the update. It almost seems the unit does r have a traditional recovery. If just does a usb boot but I could be wrong.
[Android Head-Units] aplusmiami:
Well I am on Chris no fly list - Since I mentioned his "method", even though he outlined in his post previously I am not to have supposed to even vaguely mention it. So we can expect no help from him especially since he is banned now. He is over on Kenwood forums selling his root and looking for developers. More power to him.

I can't find my solder so I have to buy some tomorrow. I will try to short that pad tomorrow.

Other than that I am stuck at Unknown devices on both of my radios.
[Android Head-Units] pdanders11:
That's messed up. He mentioned it himself lol! I saw that post long before you or anyone mentioned "His Root" was web related. Sorry if I got you in trouble but he put it out there months ago. Google "Android exploits" it comes up #2. It's not a secret. It's just not a method anyone has had to use yet to my knowledge. Still easier methods with a USB port and Android has moved past 4.2 or whatever in the cell world and it's patched. Just now people are touching the exploit with sample code.

I guess I just shouldn't go there. The "My Root" thing still bugs me. Now we know it wasn't a exploit he found but one he implemented (which is still a challenge in itself). But geez................ I guess I shouldn't ask why he still reads hear if he doesn't want to work in XDA either.

Sorry about that but posting that link doesn't a whole lot. It's still difficult to implement.

---------- Post added at 05:26 AM ---------- Previous post was at 05:24 AM ----------

And here it is.
[Android Head-Units] radux.m.dan:
Hello everyone!

This is my first post here. You guys are doing a great job, keep up the good work!

I'm from Europe and I have a DNN9230DAB, this is the EU version of DNN990HD.

I want to try and help here, so last night I tried the java stuff on my device, I have FW 1.4.0. I can tell you that it worked perfect, I got a shell command line.

I've used some info I found on the internet, but I'm not able to add the link here as this is my first post. If you need I can add all the steps involved.

Now I need to figure out the next steps to root my device. I'll add the dmesg log and the mounted partitions.

Regards!
[Android Head-Units] radux.m.dan:
mount

mount

rootfs / rootfs ro,relatime 0 0

tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0

devpts /dev/pts devpts rw,relatime,mode=600 0 0

proc /proc proc rw,relatime 0 0

sysfs /sys sysfs rw,relatime 0 0

none /acct cgroup rw,relatime,cpuacct 0 0

tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0

tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0

none /dev/cpuctl cgroup rw,relatime,cpu 0 0

/dev/block/ndda2 /system ext4 ro,relatime,barrier=1,data=ordered 0 0

/dev/block/ndda3 /data ext4 rw,nosuid,nodev,relatime,errors=panic,barrier=1,nodelalloc,nomblk_io_submit 0 0

/dev/block/ndda5 /cache ext4 rw,nosuid,nodev,relatime,barrier=1,nodelalloc 0 0

/dev/block/ndda12 /.sysinfo ext4 rw,nosuid,nodev,relatime,barrier=1,nodelalloc 0 0

/dev/block/ndda13 /.garmin ext4 rw,nosuid,nodev,relatime,barrier=1,nodelalloc 0 0

/dev/block/mmcblk0p5 /mnt/sdcard1 vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0000,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0

/dev/block/mmcblk0p6 /mnt/sdcard2 ext4 rw,nosuid,nodev,relatime,barrier=1,data=ordered 0 0

tmpfs /tmp tmpfs rw,nosuid,nodev,relatime 0 0

tmpfs /systmp tmpfs rw,nosuid,nodev,relatime 0 0

/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0

/dev/block/mtdblock0 /ramdisk ext4 rw,relatime,barrier=1,data=ordered 0 0

/dev/block/vold/240:15 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

/dev/block/vold/240:15 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0

/dev/block/vold/8:0 /mnt/usb_sda1 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1023,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
[Android Head-Units] aplusmiami:
It would be nice to document the exploit procedure, step by step if you could. Welcome to the effort.
[Android Head-Units] radux.m.dan:
Hi!

I use Ubuntu and I took metasploit and installed it on my PC.

downloads.metasploit.com/data/releases/metasploit-latest-linux-x64-installer.run

1 step is to connect to the same WiFi your PC and the kenwood navi.

2. open a console in Linux and type msfconsole

3. Type, “use exploit /android/browser/webview_addjavascriptinterface”.

For the rest look on this site cyberarms.wordpress.com/2014/02/26/android-webview-exploit-tutorial-70-of-devices-vulnerable/

Today I was able to use busybox that is already installed and read some files with vi.

I hope I will be able to add the links with http in front.
[Android Head-Units] pdanders11:
fantastic!

I tried one exploit using this on the web without luck. It implied I had to run a permission-less apk.

I will try this now.

---------- Post added at 03:34 PM ---------- Previous post was at 02:37 PM ----------

Gotta go to work but one typo on the URL

use exploit /android/browser/webview_addjavascriptinterface

no space after exploit

use exploit/android/browser/webview_addjavascriptinterface

When i tried it, I did it through the web interface.

https://192.168.1.119:3790/

I see there is a change from what I tried in the web interface

For the most part, you are good to go. You can turn on SSL if you want, change the port or host address if you want. But one variable I did change was URIPATH. By default it is random, so I changed it to something easier to type in.

“Security” sounded reassuring.

Maybe that will get it to work

---------- Post added at 04:32 PM ---------- Previous post was at 03:34 PM ----------

I get reliably to this point

[*] Local IP: http://192.168.1.119:8080/Security

[*] Server started.

[*] 192.168.1.113 webview_addjavascriptinterface - Gathering target information.

[*] 192.168.1.113 webview_addjavascriptinterface - Sending response HTML.

[*] 192.168.1.113 webview_addjavascriptinterface - Serving armle exploit...

but at this point the kenwood browser seems to hang. One time it got passed it and it started the backdoor but the session crashed. Will need to play with it more.

Any tips?
[Android Head-Units] radux.m.dan:
Yes, it's not working 100%, but give it a few tries and you should be able to connect.

I use home button to turn off and on the device.
[Android Head-Units] aplusmiami:
I tried shorting the pads and all this does is remove unknown device from device manager. I even went as far as connecting some hookup wire directly to what we are calling the data plus or green wire and I get unknown device on one side of the pad. The other side of the pad I believe is ground. So by shorting it all we are doing is killing the USB port. I've tried this on to boards some still stuck with unknown device scratching my head. I guess the manufacturer has some sort of protection built into the unit. It's really bizarre I can't believe they've gone through this link to protect the unit. As a matter of fact I don't believe it.

It does however look like you guys have made some progress with the web exploit. I'm going to set up a VM running on unbuntu and try to follow along. Thanks for all your efforts.
[Android Head-Units] pdanders11:
Yes, while the short is in place NOTHING shows in device manager as you say and the port is completed dead. Despite this I went ahead and did a clean firmware update (thinking that at some point in time that short would reset whatever killed the port). After full flashing with the short, I removed it, and maybe flashed again a clean firmware build and mysteriously the ports came back on 2 boards.

like I said, I have no rationalization for this other then it was what happened. It could have been some freak thing too. I honestly was hoping it was some sort of a override in the USB circuitry. I didn't expect what I saw. Looking at the spec of a newer chip they can turn Pheripheral mode off in Software what they are doing is really had to know.

I can show your where the FWDN resistor is if you want. This is telechips lowest level programming mode. The board only boots a small amount of code so it is unlikely a software method to kill the port would be implemented in FWDN mode since the whole point of this mode is to program over USB with the VTC drivers (I think)
[Android Head-Units] aplusmiami:
I am attempting to do a firmware upgrade with the pads shorted. I'll post the results probably by the end of this message.

Whatever is disabling the port may be receiving an error thus bypassing disabling the port, just a theory.

Are you shorting the unoccupied pads or the resistor next to it. What are you referring to when you're talking about the FWDN resistor. Is this the resistor adjacent to the empty pads? If you could upload an image showing the pads you are shorting and the FWDN resistor.

---------- Post added at 05:18 AM ---------- Previous post was at 04:50 AM ----------

Ok no go - Left the pad shorted throughout the update process and no good. Only get Unknown Devices.

I'll wait for you to show me what you are shorting before messing around anymore.

I will hopefully have time to get a Ubuntu box up tomorrow. Start messing with the Web based exploit.