ea/bosch_headunit_root

Documentation and code for rooting and extending a Bosch car head unit (lcn2kai)

bosch_headunit_root's Issues

Change radio frequency step

Is not an issue just a question. I have a similar head unit in Nissan Rogue and now this car is in Europe. How do you think is possible to use root access by ssh change the radio frequency step to 100 kHz? I will be very grateful for the answer.

Regarding the CPU and the board itself

I believe it's NaviEngine https://elinux.org/NaviEngine
And the CPU was NEC uPD35001

Hi, I need to change the region

I have an American version of Nissan rogue 2014, with the roots, can I change the region Europe? If you change the region, is it possible that the multimedia will have a choice of languages? Sorry for the stupid questions

Script confirmed working for 2014 Rogue

2014 Rogue - USA
Software: D407
Hardware: 031

rootfs script appears to work and writes it_worked file to usb drive. I am currently waiting for a network adapter to test further.

it_worked:
Linux (none) 2.6.34.13-02022-g0e24498 #1 SMP PREEMPT Wed Aug 6 08:56:05 IST 2014 armv6l GNU/Linux

qemu emulation

Bosch unit is based on NEC's NaviEngine platform and there are a few references online about OpenSolaris being ported to ARM , for NaviEngine specifically. What's more, the existing docs mention a Qemu patch that adds NaviEngine as a supported machine.

Some internet archive spelunking reveals the patch was named qemu-0.9.1-arm-ne1-solaris.patch.bz2 but I was unable to locate a copy. ARM port of OpenSolaris is available at https://github.com/alhazred/onarm/

Try to locate the patch, or otherwise test qemu support.

Map data

Hi there,

Thanks for the writeup; it's made for a very interesting read today.

I was wondering if anyone has attempted to reverse engineer any of the map data that comes with certain models.

Some context: I bought a 2018 Nissan Pulsar (Tekna trim) which comes with the following head unit:

The firmware version is D554 (accessing the service menu is slightly different - I followed this video).

Note the SD card slot on the top right. Mine came with a "V5" map data SD card, similar to the following:

The SD card contains a folder called "CRYPTNAV" which contains around 15,800 files, roughly 5.7GB in total. Most of the files are binary formats - some are known file types such as SQLite but most appear to be proprietary. Some plain text files exist such as XML, CFG, and TXT files.

Specifically I'm interested in decoding what I assume are icon/graphics files used by the navigation system. The files are contained within a folder called "3D_PICT". There appear to be four versions of each file. For example, the file name "JUG00378" appears as:

• JUG00378.phd
• JUG00378.phn
• JUG00378.pnd
• JUG00378.pnn

My first guess would be that the final "d" and "n" in the file extensions could stand for "day" and "night", i.e. a different colour depending on the display mode of the navigation system. Perhaps the "h" in .phd / .phn is "high [res]" as these always appear to be larger than the .pn* files.

Looking at the files in a hex editor quickly reveals they're using PNG format, however the chunk data appears to be partially compressed/encrypted.

For example, a typical PNG IHDR chunk contains the chunk length (13 bytes), chunk name (IHDR), chunk data (width, height, etc.), and CRC. In JUG00378.pnn, however, despite indicating the IHDR chunk is 13 bytes, only 10 bytes of data follows until the next chunk name is reached. There is also a custom file header before the PNG header which appears to contain encrypted/compressed data.

Apologies this is so rambly - just thought I'd share what I've observed so far and wondering if anyone has had any success in decoding any map data.

rtos interactions - the GM/Chevy MyLink HMI 2.5 devices are similar...

However despite having the reboot disabled, any time I try to do anything with any of the OSAL lib related functions, the HMI reboots.

Here's my version of the lib...any thoughts?

https://send.vis.ee/download/8edb9373f02a95f1/#qC-WyEipNmdMYdcgrvLwww

File system support

Hi.

"ext2" doesn't seem to work on my unit.

So, is there a different approach? For example, a file system?

My system vfat works.

And ntfs is mounted in a state that can only be read.

Thank you.

LCN2

"If anybody happens to know what it stands for, I'd like to know."

Low Cost Navi _ver_2 kai (Japanese for revised. like Dragon ball z kai)

Start a wiki or make additional docs?

Trying to decide if it would be easier to just start a wiki to document reversing progress , or just create new markdown docs in existing repo...
Github wiki's are technically just another repository so we'd have to deal with pull requests there too. Leaning towards just keeping everything in this repository as majority of it is just writeups and documents anyway.

USB device enumeration question

Hi.

Thanks for sharing the good content!

What hardware did you use when testing the Umap2 tool?

Maybe, FaceDancer21(https://int3.cc/products/facedancer21)?

I use the "GreatFET One" tool, but that command doesn't work.

Found Continuity

On one of my units, I was probing Tx Rx around the board, found continuity to the harness connector. Marked out in the picture according to the colour of wire you used. Looks like the physical connector has those pins really short so they don't actually plug into the vehicles harness.

other radio models

Hello,
I am interested in this project. I was wondering if this method works on other radio frameworks such as versa note 2015 model or not?
It's audio system is similar to this
https://www.youtube.com/watch?v=46cw2_ow3qI

Also can we develop some UI applications for the embeded os on such systems?

infiniti q50

Hey Nice work.

I myself have a 2016 Q50, my unit looks a bit different but I am going to try this & i will report back.

great work

Figure out TK Device access

Both linux and rtos side expose each other's file systems through kernel drivers called RFS/RFS2 which stands for Remote FS as far as i can tell. It's a relatively simple virt FS driver that's built ontop of virtio and provides basic FS functionality.

Most interestingly, RTOS devices are exposed through it in /dev/media/rfs/ some of which have quite fun sounding names (such cas candesc which seems to be a CAN device). Now, reversing on the RTOS side reveal a relatively simple IOCTL based interface to these devices. BUT! The RFS implementation doesn't support IOCTLs. Reading/writing to some of the devices is very easy because they work with regular read/write (like errmem for example) , but others don't do anything (like said candesc...).

Wishful thinking: Close this issue when you figure out how to talk to any of the non-cooperative devices!

how i can run it on my nissan qashqai 2014 j11

i have so many questions about the code can you explain how to do it with a video?

How to access terminal as seen in Readme.md

At the beginning of the Readme, it displays an image of the headunit running a terminal. How was this done? Was this the result of changing the boot prams? I could not find a reference to it in any of the docs. Thanks!

Confirm operation in my Bosh

Just to confirm the operation, at the moment only testing, in the unit mounted on my 2018 Nissan X-Trail T32 (EU).
Software: F106, Hardware: 034.
This is the content of it_worked:

Linux (none) 2.6.34.13-02254-g839a100 #1 SMP PREEMPT Tue Nov 24 15:35:26 IST 2015 armv6l GNU/Linux

So I suppose the transition to the real root phase should work.
But even more interesting will be the possibility, for example, to implement features that are currently not endured, for example, reading audio files in FLAC format, support for extFAT and many other things.
Two years have already passed since this hack, but I don't see anyone developing anything, but I remain hopeful.
It would obviously take some good souls to get their hands on it.
Thanks!

2015 Nissan Qashqai

First of all, thank you so much for sharing. This is great!
I can confirm, this is working with a 2015 Nissan Qashqai (software D302, hardware 031).

figure out IOSC

Linux and RTOS communicate with each other over an interface called IOSC. OSAL library seems to implement an abstraction layer above it. We should reverse engineer users of libosal to figure out how
it's supposed to be used so additional utilities can be written to get more interesting data from RTOS.