Bimmerfest BMW banner

1 - 20 of 49 Posts

·
Registered
Joined
·
935 Posts
Discussion Starter #1 (Edited)
I think that we should do a collaborative effort to hack the MMI, of the e65 but the procedures should also be relevant for the similar CCC to gain root access to the backbone of the systems to possible write our own custom firmware updates to add features, languages or what ever we want.

So let me hear what you think about this idea

Sent from my SM-G955F using Bimmerfest mobile app
 

·
Registered
Joined
·
935 Posts
Discussion Starter #2
Well I have started by converting the update file from winkfp (which contains a huge portion of the code in the flash memory in the mmi) from the bmw version of Intel hex to a regular .bin file much easier to worke with.

I then have moved the file to a kali linux virtual machine and looked at it with binwalk to see that it was an Zlib compressed file.
20181223_163912.jpeg
So I then cut the file to the appropriate size and managed to find a program called zdrop.exe that was able to extract the data afterwards and only then were I able to somewhat read the contents of the file
20181223_165245.jpeg
but we're not done there

After that I ran the file through binwalk again and we can now see this instead which is more or less a list of what can be found in the update file.
20181223_165555.jpeg

I have after that split up the file some more to have a look at the contents for example this is a part of the kernel 20181223_170112.jpeg

So this is basically where I'm at right now and we'll see wher I'll go from here. Maybe I'm going to look more closely at the kernel in ida pro to see if I can find something.

Sent from my SM-G955F using Bimmerfest mobile app
 

·
Registered
Joined
·
935 Posts
Discussion Starter #4 (Edited)
Why would you not mount the bin file - could make access to the FS alot easier?
Which bin file mounted in what? Let me just say that I am a total noob at this type of stuff. I'm learning as I go. I just follow the work patterns I find on the internet and try to apply them on this So all help whit this would be great for the community :)

Sent from my SM-G955F using Bimmerfest mobile app
 

·
Registered
Joined
·
935 Posts
Discussion Starter #6
I have now ordered a "buss pirate" which have jtag and uart capabilities so that I hopefully will be able to dump the internal flash memory with of both the front MMI and rear MMI with the jtag interface on the renesas SH7709A main processor. I will upload the files when I have them at hand. Hopefully it won't be to much of a hassle extracting it.
And then the real reversing can begin.

I have also been working on finding and learning how to use a good simulator/Emulator for for the system so that testing can be done much quicker without having to load the new software in the flash every time.

I have found a simulator debugger for superH family for High-performance Embedded Workshop
https://www.renesas.com/kr/en/produ...ls/simulator/hew-simulator-for-sh-family.html

Which is the manufacturers own free tool that should be able to do the trick if I can just figure out how to use it properly and install all necessary components of the program.



Sent from my SM-G955F using Bimmerfest mobile app
 

·
Registered
Joined
·
935 Posts
Discussion Starter #7
Just found some interesting strings while decompileing the winkfp update file in IDA pro.

First I found the "Call function start application to initiate startup !!!" Which is if I'm correct where it is starting to boot the GUI
View attachment 839269

View attachment 839271

Then I found a function call to get root which is probably what is needed to initiate a software update "openDialog: UsedComponent p2 (m_pCtDialogTop->getRoot())"
View attachment 839273

Sent from my SM-G955F using Bimmerfest mobile app
 

·
Registered
Joined
·
935 Posts
Discussion Starter #8
I've later learned that these strings probably isn't anything more than debugging information (which usually should be somewhat stripped from the final release version) and that we probably would need a symbols table to go with that so that the debugger can know where all the functions and subroutines start and end or something along those lines in order to actually use the debugging facilities of this software/ system. Bummer...

But this info can probably somewhat show what the nearby code is.

Another thing that would yield progress would be if we could figure out what compiler was used to compile this software and what language (eg C++) the source was written in. I haven't really found any real clues yet but I am suspecting C++ due to the .cpp file paths left in the debugging info and probably some cross compiler due to the fact that this is an embedded system. Or possibly GNU compiler. More research is needed as usual.

2nd big step would be to get hold of some source code. The kernel might be somewhat possible so that we have something to comparewith. It is

VxWorks 5.3.1
BSP version: 1.019328
Wind kernel 2.5
Creation date: June 1 2007

So at least we have something to go by.


I have also seen some things related to a shell. But I have no idea how to access it when we have no way of inputting anything other than the idrive controller. And there is also some things speaking of network connection. So it would be awesome if we could ssh into it but then again how? From what I know only the Navigation computer can do that through the TCU module.
Unless it's about the CAN/MOST network?


Sent from my SM-G955F using Bimmerfest mobile app
 

·
Registered
Joined
·
935 Posts
Discussion Starter #9
Please check this link out from time to time for updates as I will upload all files, pictures, documents, binary dumps, program tools and other things along the way there for anyone who wants to look into it.

https://drive.google.com/folderview?id=1ue6Z0G95_-nF3svesaC4yThRse6rIdwk


I also took out the main 8.8" MMI today as the weather allowed me. And then disassembled it just to see that it is more or less exactly the same internals as the rear. In preparation for when I am going to dump the flash memory.
All the pictures of this, the rear and a front early pre facelift one can be found in the google drive link 20190216_125534.jpeg 20181218_185737.jpeg

Sent from my SM-G955F using Bimmerfest mobile app
 

·
Registered
Joined
·
935 Posts
Discussion Starter #10
I have gotten my hands on a wind river development tool called Tornado 2.2 which could be the exact same version used to develop, write and debug the VxWorks os running inside the idrive. And I have been able to play around in the shell and seen many commands in action which can be seen in the winkfp update file and tried to write some basic code and compiled some code and debugger it.

BMW might actually have used an even earlier version of Tornado but more research is needed there and this one is the only one I was able to find. And this is for ARM CPUs I think but anyway

Just some basic stuff. But I think all the stuff is there so if anyone ski***314;led use this they could probably write new software for the idrive as I have seen a lot of source code and guides on how to use it.

I have uploaded 2 files from Tornado 2.2 which lots of the strings found in the update file can also be seen.
https://drive.google.com/folderview?id=18vlGiGXrSSHXek0yk8HTYrmQZfuKKO-M

One file called userLib.c Snapchat-365936688.jpeg 20190217_223130.jpeg Screenshot_20190217-232702_Drive.jpeg

Sent from my SM-G955F using Bimmerfest mobile app
 

·
Registered
Joined
·
935 Posts
Discussion Starter #11
Well I recieved the Bus pirate yesterday and think I have hooked it all up correctly although I don't know if the mmi needs to be powered up for the jtag interface to work.
So this will be scary. 20190219_103246.jpeg Screenshot_20190219-095408_Drive.jpeg 20190219_115256.jpeg 20190219_115248.jpeg

Sent from my SM-G955F using Bimmerfest mobile app
 

·
Registered
Joined
·
935 Posts
Discussion Starter #12
Well the Jtag interface haven't worked yet as I am still trying to write all configuration files for it in openocd.

I was looking through Tool32 for a way to dump the flash memory but hanen't tried any of the jobs that looks prommising.
I dod however stumble across this
$00 all ECU
$01 PowerOn
$02 ClearMemory
$04 routineLocalIdentifier (selfTest)
$05 PowerDown
$06 ClearDTCShadowMemory
$07 RequestForAuthentication
$08 ReleaseAuthentication
$09 CheckSignature
$0A CheckProgrammingStatus
$10 StartDiagnosticSession
$11 ECUReset
$14 ClearDiagnosticInformation
$17 ReadStatusOfDiagnosticTroubleCodes
$18 ReadDiagnosticTroubleCodesByStatus
$1A ReadECUIdentification
$20 StopDiagnosticSession
$21 readDataByLocalIdentifier
$22 ReadDataByCommonIdentifier
$23 ReadMemoryByAddress
$28 DisableNormalMessageTransmission
$29 EnableNormalMessageTransmission
$2E WriteDataByCommonIdentifier
$31 StartRoutineByLocalIdentifier
$34 RequestDownload
$36 TransferData
$37 RequestTransferExit
$3B WriteDataByLocalIdentifier
$3E TesterPresent
$3D WriteMemoryByAddress
$80 ECUIdentificationDataTable
$85 ControlDTCSetting
$87 physicalECUHardwareNumber (PECUHN) oder alternativ
$89 SystemSupplierECUSerialNumber
$90 Vehicle Identification Number
$91 VehicleManufacturerECUHardware*Number
$9B Vehicle Manufacturer Coding Index
$A0 routineLocalIdentifier
$A1 routineLocalIdentifier
$A2 recordLocalIdentifier
$A3 recordLocalIdentifier
$1000 TestStamp
$2000 dtcShadowMemory
$2001 - $20FF dtcShadowMemoryEntry
$2500 PRBHW*B
$2501 Zeiten
$2502 HWREF
$2504 DREF
$2506 MaximaleBlockLaenge
$3000 - $3EFF CodingDataSet
$3001 CodingDataSet für Sprachpaket

$3FFF ChangeIndexOfCodingData
wich I think we can call somewhat of a Memory MAP. I think that those addresses correspond to the spesific function found there. Although hard to confirm since the only part of the memory i have is the coding memory but it correspond exactly to this $3000 - $3EFF Coding Data Set and the exact location where the coding data for the language pakage can be found = $3001 Coding Data Set für Sprachpaket. so it seems prommising.

i was also able to disassemble the .prg files that tool32 use with a software i found on the net but hav not found anything remarkable yet.
 

·
Registered
Joined
·
935 Posts
Discussion Starter #13
I tried all of the lesen jobs but didn't really get any useful information from it. Although I haven't been able to figure out the arguments section. What to input there. Also I don't know if I have bricked the front idrive now since it went black after a minute or two (might be due to inactivity or that the most ring is broken) but was still responding to the computer until I emptied the battery which haven't been changed (or the car started) for half a year now.

20190306_164857.jpeg 20190306_164918.jpeg 20190306_164940.jpeg 20190306_164958.jpeg 20190306_165018.jpeg 20190306_165030.jpeg 20190306_165043.jpeg 20190306_165056.jpeg 20190306_165327.jpeg 20190306_165528.jpeg

If the Jtag interface cannot be figured out I'll probably have to get one of those universal programmers and desolder the physical flash memory from the board to dump the memory. But I hope not as I am afraid I will break it somehow.

Please if someone here has one of those universal programmers let me know.
 

·
Registered
Joined
·
935 Posts
Discussion Starter #14
Well a major setback. I broke my rear mmi trying to power up the SH7709A by bypassing the built in power supply and powering up the SH7709A and Xilinx FPGA directly.
20190313_093132.jpeg
20190313_094455.jpeg

Because when you supply 12v to the standard power input it just powers up half the board (most controller and ST10F269-T3 cpu) and sets the ST10 in a waiting state which watches for the right can/most message to start supplying power and start up the other half of the board. Which is why it is necessary to bypass that function. And thanks to Stuartjohn24 for helping me reverse engineer the board. I have also gotten a lot of help with the jtag from this other dedicated guy!

Anyway I am now forced to buy another rear mmi for my car... but hopefully the SH7709A is still ok and only the fpga being fried so I can still use it for jtag after the power to the FPGA has been cut off.
 

·
Registered
Joined
·
935 Posts
Discussion Starter #15 (Edited)
iDrive


- Control Display


The Control Display consists of:
• the metal casing with integral electronic module,
• the LCD display
• and the screen cowl with glass front.


Control Display


Index Description
1. Metal casing
2. LCD display
3. Screen cowl



A 16-bit processor is responsible for communication (gateway function) between the MOST and System K-CAN bus systems. It also performs the tasks of diagnosis processing and illumination dimming. A 32-bit processor with 16 MB of RAM and a 16 MB graphics memory is responsible for display output and user guidance. The Control Display is equipped with a Flash memory module. This means that software can be downloaded/updated via the diagnosis interface at any time. The text and character sets for the language-specific elements of the user interface (country coded) are stored in the Flash memory. The size of the LCD display is 8.8 inches (diagonal). A 6.5-inch display is planned as a future option. The complete Control Display assembly is fixed to the dashboard by three screws.

The LCD display plus the screen cowl and glass cover form a detachable unit.
On the rear of the metal casing there are cooling fins. Next to them is a 5-ampere fuse. This protects the Control Display against damage from excessive current.



Brightness control

Two cathode ray tubes built into the display casing are used for the screen backlighting. There is also a photoelectric cell on the front of the LCD to the right of the screen for detecting the ambient light so that the screen brightness can be adjusted accordingly. The screen brightness also responds to manual adjustment of the instrument lighting dimmer control. To that end, the Control Display analyses a data message from the light module (LM).



Photoelectric cell in LCD display unit



Pin assignment

The Control Display has a 12-pin and a 14-pin connector. The 14-pin connector incorporates the connections for the MOST (fibre-optic) and System K-CAN bus systems.

The 12-pin connector provides the RGB-format (RGB = red, green, blue) video input. The Control Display is capable of digitising analogue video signals and displaying them on the LCD screen in full-screen or split-screen mode.




Control Display connectors


Index Description

1. 14-pin connector
2. 12-pin connector
 

·
Registered
Joined
·
935 Posts
Discussion Starter #16
I can now confirm the tools and coding languages used to develop for both the e65 and e60 from one of the developers of the systems. So for the programming language C ++ is used (MS-Visual C ++ and GCC).

The debuggers are the Visual-C ++ debugger and in-house tools.

Development of software components / bug fixes for a car multimedia system (BMW E65 MMI).*My main task is the elimination of reported errors, as well as the implementation of custom software extensions.*This also includes the search / testing directly at the customer.*As programming language C ++ is used (MS-Visual C ++ and GCC).

The debuggers are the Visual-C ++ debugger and in-house tools.*The source management software was Perforce.*Furthermore I worked with different tools for test and analysis (MOST Optical Analyzer professional, CANoe, etc.)

System environment and tools
C ++, Tornado, CAN, MOST
11/2002 -03/2003
Embedded software development in the automotive sector*
Harman / Becker Automotive Systems GmbH*
Software Engineer*
Project description

Car Multimedia System: Development of software components for verification and backup of configuration and diagnostic data stored in the EEPROM.*
Troubleshooting and repair of internal drives (CD-Drive via I2C bus).

System environment and tools
Hitachi SH7709, ST10, VxWorks, Tornado, CAN, MOST, I2C bus
05/2002 -11/2002
Embedded software development in the automotive sector*
Harman / Becker Automotive Systems GmbH*
Software Engineer*
Project description

The device to be developed was a high-end multimedia system which was to be installed in the new BMW 5 Series.

The technical basis was an embedded controller system consisting of Hitachi SH3 and ST10.*CAN and MOST were used as fieldbus.

My main task was the software commissioning of the different hardware sample series (A, B1, B2, C1, ....).*For this purpose, the BSP (Board Support Package) from VxWorks and several boot loaders had to be adapted to the changed hardware.

If necessary, adjustments were also made to the globally used software framework and to adapt various simulation programs.*Other tasks included testing the individual software checkpoints, providing test systems to the teams, and assisting with the integration of various software components of the development teams involved.*As programming language mainly C ++ was used (MS-Visual C ++ and GCC).

The BSP and bootloaders used C and assembler.*The debuggers included the Tornado debugger, CodeScape Professional and a number of in-house tools.*MKS was used as source management software.Furthermore, I worked with various tools and devices for flashing (DASH, Oasis, ...) and testing (MOST Optical Analyzer, etc.).

System environment and tools
Hitachi SH7709, ST10, VxWorks, Tornado, CAN, MOST, I2C bus
Skickat från min SM-G955F via Tapatalk
 

·
Registered
Joined
·
935 Posts
Discussion Starter #17
And from another former developer.

August 2003 - May 2006*
Fa: Automotive*
Development of a vehicle multimedia infotainment system (MMI) with*
navigation for a German car manufacturer with connection to CAN and*
MOST bus*
Subproject management / team leader (Function Project Leader, FPL) of the Debug Team*
- Creation and maintenance of a task list / project plan for the Debug Team
- Control resources of the debugging team*
- Carefully analyze assigned problems*
- Detect system*problems*-*
Close collaboration with software architecture to identify*
* design*issues*-*
Develop and implement proposed solutions for*
* design and implementation*
- Communicate and collaborate with other software parts / teams, as well as*
* system testing and implementation Software verification*
- Reporting to the overall project management*
- Ensuring infrastructure for the debugging*
team -*Integrating the*team into the development environment*
-*Examine*critical points / bottlenecks in the system*
- Analyzing security-relevant source code (buffer overflow, etc.)
- Development of problem solutions together with the other teams*
- Provision of debugging possibilities and test tools
- Development of measures to increase system stability (avoidance of*
* reboots / resets)*
- System analyzes / system performance with WindView*
- CAN / MOST bus tests with CANoe, Canalyzer and OptoLyzer4MOST*
- MOST stress tests Unlock Tests*
- Activating the MMU for SH3 Processor*
- Exception Traces Exception*
Analysis - Rational ClearQuest Problem Reporting Analysis*
- Customer On-Site Troubleshooting*
- Source Code / Design Reviews for All Software Parts (Design:*
* Rhapsody*Design*)
- Source code analysis and monitoring of source code quality with PCLint*
- Problem*analysis Interaction*software / hardware in close cooperation*
* with hardware development team*
- Signal level*
measurement*in critical system conditions*- Analysis of trace / log files*
- Protocol*analysis*Communication to the radio module via RS232*
- Protocol*analysis*Communication to the navigation*module*About I2C*
- Forensic*
Analysis*Using FLASH Images*- Detecting and Analyzing Compiler*Problems*
- Test*

Rides*and General Testing*Development Environment: WindRiver Tornado on Windows NT and Windows XP, Target: VxWorks for*
SH7709 (SH3) SuperH RISC Engine, and ST7
Tools: Rhapsody, Rational ClearCase, Rational ClearQuest, Microsoft Project,*
WindRiver Tornado (gcc, gdb, gnu-tools), OptoLyzer4Most, CANalyzer, CANoe*
Programming Languages: C / C ++, Assembler, (XML)*
Skickat från min SM-G955F via Tapatalk
 

·
Registered
Joined
·
935 Posts
Discussion Starter #18
I recieved my new rear MMI at the price of 57euro and it is from week 27 year 2007


And the hardware is exactly the same as my old one except a slight different color on the pcb and some numbering differing.


I installed it in my car and it worked perfectly except needing some coding which was a breeze because I had a copy of the coding from my old unit.
This new one had for example dab enabled which I don't have yet since it is unclear whether or not Sweden will adopt dab or not although it is available for a few select radio stations in my city as a test. The MMI is from a UK 760Li when looking it up and I think it's running the last update of the idrive system. So now I can fully dedicate my old one for testing and development.


Skickat från min SM-G955F via Tapatalk
 

·
Registered
Joined
·
935 Posts
Discussion Starter #19
Today I ordered a front MMI that I found for 25euro. It is a pre facelift unit part number 6929474. My plan for this is to try and make a guide on how to flash the latest facelift firmware (which should theoretically be possible) on it and then use it for testing of custome firmware releases. For a start I will start with something that should be simple that is changing the name of the "CDC" option in the entertainment menu to "iPod" and if it works release it to the people that has the iPod interface installed Instead of the CDC. Because despite the fact that you enabled an option in the coding called iPod it doesn't change the menu name.

And if that is successful I will attempt a complete translation of the language used in the idrive to swedish. There are other companies that claim to be able to do this to other languages at least so it should be possible but we'll see.

And then probably use it for further development of the hacking of the system functions to add our own ones and. Which will be severely more difficult as it will most likely require a total redevelopment/ rewrite of the software in order to gain full control over the source code and drivers for the MOST bus units.

Skickat från min SM-G955F via Tapatalk
 

·
Registered
Joined
·
935 Posts
Discussion Starter #20
Well yesterday I bricked yet another Rear MMI unit when I mindlessly coded the Hardware Variant from HW_Variante_Fond to HW_VARIANTE_BASIS (the 16:9 front mmi).

This is a hidden coding option available at address 3000 and has 3 options:
HW_Variante_Basis (1hex)
HW_Variante_High (2hex)
HW_Variante_Fond (4hex)



The front MMI can be changed without any problems between the basis and high version but it should not and can not be changed to the Fond variant as this has a slight different hardware and outputs the picture to the LCD in a different way. Likewise the rear mmi CANNOT be changed to either the basis or high version. This will put it in a unresponsive state from which you are not able to recover with any conventional tools at least. There may be a chance that it can be flashed with an OPS unit but I doubt it.

So I took this unfortunate opportunity and ordered one of those universal programmers so I can change it back that way but this will require me to desolder the flash chips so this can go really bad. At least we will get the full mmi memory dump now to work with until the Jtag interface has been figured out. Hopefully I will be able to resurrect it this way so I don't have to order yet another MMI.



Anyway here's some pictures and videos from when I changed my front high version to the basis version.

https://youtu.be/N4GKZahba-4
https://youtu.be/Lyspw0Lnf2o

This is the error I get after changing my rear mmi.
I understand why this coding option is hidden from us so use this finding at your own risk!!!!

Skickat från min SM-G955F via Tapatalk
 
1 - 20 of 49 Posts
Top