Jump to content
AVIC411.com

NEX runs Android, and other useless info


Recommended Posts

  • Replies 52
  • Created
  • Last Reply

Top Posters In This Topic

I'm beginning to wonder if I could fix the sort order problem in the music app..... it would be somewhat of a bitch to do from .smali (maybe more of one than its worth) but.....

 

Come on, if we're going by how much this stuff is worth doing now ... :)

Link to post
Share on other sites

Oh no, none of that has a dollar amount.  Being both a coder and electronics dude (I have surface-mount rework gear, do my own boards for some projects, etc) I often take on something "just 'cause" :D

 

I'd be very interested in a non-destructive way to dump the firmware (without opening the case) and even more interesting (if I manage to hack it) to reload it.  I have a tablet here that I almost-never use and it would be very interesting to grab the APK files involved and attempt to run them on that -- it would make for a very nice debugging environment as there's no challenge getting into ADB on that one.... :)

Link to post
Share on other sites
  • 7 months later...

Hi guys! I already have the apk / odex files disassembled to .smali, I can share them if anyone else wants to look at them

 

Sofakng, yes, I have some background in EE, glad you like the blog posts! :)

 

I have a crafted "update" that you can apply using one of the test modes that can patch the PLCaution nag screen out. It also offers a couple different ways of backing up your internal SD card to external USB or SD; you can use a built-in EasyRecovery mode to re-image the internal SD without opening up the case (or you can use the image to restore the internal card manually if that doesn't work and you can open the thing up.

 

You can also use the image to reverse-engineer the thing.

 

The thing is, in order to get the modified system to boot, I have to turn off Warp!!, which makes the system take longer to boot (26 seconds vs 13 seconds); I'm working on that right now (but that's a whole other task).

 

gEDv1Lv.jpg

 

JaKU847.jpg

 

9ICwx9E.jpg

 

 

@bushing - where you able to get Warp! to turn off? I am really curious about using the method you discovered to patch some other items on the unit. Would you mind supplying an update?

It seems like the progress just cut out a few months back. 

 

Looking forward to hearing back. :)

Link to post
Share on other sites
  • 1 month later...

Hey guys, is the set on/off button you are looking for is this one ?

It looks like this is the same exact screen posted earlier.

 

Anyway just to confirm the SPH-DA120 model is quite similar to the NEX5/6/7/8 series .... Firmware is even named NEX5000 and it does include a 4GB SD card inside ...

Didn't unlocked mine yet (not sure I can recover the password yet) ...

 

Will follow this theard anyway.

 

Oh, and for those who wants to build/rebuild apk, this kitchen is very nice !! http://forum.xda-developers.com/showthread.php?t=1736409

Link to post
Share on other sites
Fantastic work by Bushing, thanks! 

 

SPH-DA120 and 5000NEX seem to be very similar software wise. A firmware update came out for both late last year:



 

I've got a SPH-DA120 so I'm going to be focusing on that (wrong forum, I know).

 

This firmware zip contains a bunch of stuff, notably two file types in a few directories:

 



$ tree AVIC5000NEX
AVIC5000NEX/
├── BLUETOOTH
│   ├── PJ140BTHBTL.PRG
│   ├── PJ140BTHSAF.PRG
│   └── PJ140BTHUDP.PRG
├── BOOT
│   └── PJ140BOT.PRG
├── HIBENDIR
│   └── HIBENDIR.PRG
├── HIBENDIR.VER
├── PJ140BOT.VER
├── PJ140BT.VER
├── PJ140BTL.VER
├── PJ140DAT.VER
├── PJ140ERY.VER
├── PJ140OPN
│   └── PJ140OPN.PRG
├── PJ140OPN.VER
├── PJ140PLT.VER
├── PJ140REC.VER
├── PLATFORM
│   └── PJ140PLT.PRG
├── RECOVERY
│   └── PJ140REC.PRG
├── RECOVERYEASY
│   └── PJ140ERY.PRG
├── SNAPSHOT
│   └── SNAPSHOT.PRG
├── SNAPSHOT.VER
└── USERDATA
    └── PJ140DAT.PRG
 
9 directories, 21 files


 

This is from the SPH-DA120, 5000NEX is similar but the images have different contents.

 

VER files appear to be pointers to PRG files for the different functions or subsystems. 

Turns out the PLATFORM & USERDATA PRG files are just EXT volumes with a header, can discard the first 512 bytes to get a mountable image.

 

e.g. using DD.



dd if=PLATFORM/PJ140PLT.PRG of=PLATFORM/PJ140PLT.img bs=512 skip=1


 

From there you can mount the EXT images, inside we've got some stuff:

 



$ tree app
app
├── Av.apk
├── Av.odex
├── DataLinkInfoCollector.apk
├── DataLinkInfoCollector.odex
├── DrmProvider.apk
├── DrmProvider.odex
├── FusedLocation.apk
├── FusedLocation.odex
├── JupiterHome.apk
├── JupiterHome.odex
├── LatinIME.apk
├── LatinIME.odex
├── Launcher.apk
├── Launcher.odex
├── MediaInfoProvider.apk
├── MediaInfoProvider.odex
├── MediaProvider.apk
├── MediaProvider.odex
├── MixTrax.apk
├── MixTrax.odex
├── MixtraxProvider.apk
├── MixtraxProvider.odex
├── Mode.apk
├── Mode.odex
├── Notepadv3.apk
├── Notepadv3.odex
├── SettingsDevelopment.apk
├── SettingsDevelopment.odex
├── SettingsProvider.apk
├── SettingsProvider.odex
├── SystemUI.apk
├── SystemUI.odex
├── SystemView.apk
├── SystemView.odex
├── TestMode.apk
├── TestMode.odex
├── UIService.apk
└── UIService.odex
 
0 directories, 38 files


 

I've patched my Av.odex, JupiterHome.odex and SystemView.odex to always return true for InfoManager::hasConfirmedPLCaution() (as Bushing did) and repacked the platform image.

 

However I don't have access to my unit right now so I can't tell whether I can actually update the firmware.

 

I'm unsure what kind of signing there is to ensure the integrity of the update.

I also need to check on how to mitigate a bad flash, as that's a very real possibility!

 

Link to post
Share on other sites

Quick update. 

 

I got the head unit and managed to bypass the SD card password to take an image - just opening it up and swapping the powered SD card into a computer to then read the data off - the HU unlocks the card then I whip it out (powered) and the card stays in an unlocked state.

 

I then started information gathering in the various the filesystem images and discovered how to access several of the TESTMODE's

 

I've bricked and recovered my unit about 5 times today, the final time it's stuck ironically on a programming screen (but not responding to touchscreen input) and unless I can thinking of something out of left field I'm going to have to follow in bushing's footsteps and get JTAG on the device to reset the BSP boot mode back to normal.

 

I have not found a non-rooting way of getting ADB console or an access point for /dev/ttymcx0 (that'd be really nice right now).

Link to post
Share on other sites

Yep, I've got several SD backups. However the mode I'm in is the one in Bushing's photo:

 

gEDv1Lv.jpg

 

To get here I inserted a USB drive containing a specially crafted TESTMODE_N.KEY, the system automatically picks it up and it flips a bit in the NOR flash ROM to boot to the recovery partition then reboots. So if you boot with any SD card it boots to the recovery partition.

This persists past reboots and SD card changes so the only way to get out is to flip that bit again - (I can't get out the same way I got in either!)

 

The issue I've got is my touchscreen doesn't work in this mode so I can't change inputs. I'm currently working on the theory that there's another method of controlling it, maybe via the wired remote port.

 

Tellingly Pioneer's parts website lists a "SERVICE IF UNIT" for these head units, I'm guessing IF means interface.

Link to post
Share on other sites

rjoc, have you tried TESTMODE_A.KEY, TESTMODE_S.KEY, TESTMODE_N.KEY keys? I have content for this files, but can't enter testmode using this files

 

I found how to access three of the TESTMODE_N functions:
'copy device', 'easy recovery' and 'mode change'.
 
I assumed (wrongly) that 'copy device' took from internal to external, turns out it's the opposite, which makes a lot of sense in the context of servicing. Upside it has made future re-images far easier to deploy.
 
'easy recovery' changes the BootMode in the BSP to boot from recovery partitions. (It appears you can't get out of this mode with just a touch screen)
 
Not sure what 'mode change' does; it appears to change update and sub-update flags in BSP but not sure the implications of this.
 
TESTMODE_S.KEY: adds the text "Test Mode" to the screen as an overlay and seems to boot normally - it appears that this enables some inputs that aren't otherwise present, didn't spend much time looking at this.
 
TESTMODE_A.KEY: I can't get in, I believe the keys I have are wrong or another condition is not met. I believe this to be the service application for testing subsystems and connected interfaces.
 
TESTMODE_R: currently can't trigger, it's disabled in init and I haven't found how to change Launch Modes yet.
Unsure how this differs from the easy recovery mode in TESTMODE_N.
 
I'm reluctant to post my TESTMODE KEY files publically because it's super easy to brick your HU with these!
 
How come you can't enter test mode?
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...



×
×
  • Create New...