M+ computer internals + info

reffahcs · February 8

https://community.native-instruments.com/discussion/comment/209897#Comment_209897

Surely that department has been defunded by now and outsourced to a private corporation 🤣🤣😭😭😭… at anyrate…

Thank you very much for the feedback and glad you were able to follow. Always happy to explain more, but I usually don't because I don't like feeling like I'm talking down to people.

Cheers

-Tim

LostInFoundation · February 8

https://community.native-instruments.com/discussion/comment/209900#Comment_209900

Surely that department has been defunded by now and outsourced to a private corporation 🤣🤣😭😭😭… at anyrate…

You are right, I musk say…😏

Andy Wt · February 8

@reffahcs i suspect that gaining access to screen output will not give any advantage because it will only show login prompt. Same prompt probably could be accessed via USB UART on M+ carrier board located near M2 PIEe connector. But it requires soldering some RC circuitry and connector itself. I know nothing about dev kit but i believe similar UART circuitry is already present there so its probably worth trying connecting to it.

Speaking about username/password - eMMC dump maybe could theoretically help here 😉 Or maybe with working screen output its possible to boot OS into some kind of single user mode which doesnt require logging in.

Also maybe there exist some compatible eMMC chip which could be installed into chip socket which will allow to just copy content from original eMMC ant other sources multiple times but soldering socket itself only once.

Disclaimer: all info above is pure theoretical and potentially quite old, so i could be mistaken in every word.

D-One · February 10

I kind of doubt that a lil' bit, I suspect they have a practical way of snooping around for debugging purposes.. IK the M+ scans the root of the SD for files and those files can have codes that activate features, run scripts, etc, dont ask me how I know… NI has used this to fix things in the past, Reaktor issues if I am not mistaken.

Another reason is that Maschine SW has a 'developer mode' that enables things like mirroring the HW screens on a detachable window on the computer for example, among other things… I know this because of all my snooping around in the Lua Scripts (there's many references to dev mode) and NI once sort of accidentally leaked a picture of it… But i dont know if it can be activated somehow (hex edit an if statement?) or if it's a separate branch that requires it's own build but it might point to having practical ways of debugging.

reffahcs · February 10

Definitely worth it. I think I'm going to do it. We have a eMMC flash reader at work, if I have the correct size socket for the eMMC I will try to dump it. Alternatively it may be that there are test points on the board that route to the eMMC socket, because it's basically an SD card, you end up not actually needed very many connections to read it.

Yeah hard to say D-One, could be something super simple like a combination of buttons held during power on, a file with a password, or a cryptographic key/token that Is strategically placed on the SD card, or the craziest thing I've seen is a physical dongle that is attached to the device during boot. It was basically an empty dongle that just had a small eeprom inside that just told a radio it was in debug mode.

The irony of it all is that if we dumped the eMMC, we could probably find out how to enable developer mode so we wouldn't need to dump the eMMC lol

reffahcs · February 12

Well as a last ditch effort to not have to chip off the eMMC, I thought I would try and boot the dev board from a USB drive containing Linux and then use the CLI mdtools to dump the eMMC from within Linux.

Well… that didn't go over to well lol. Never mind the fact that I still can't actually see the boot screen. The BIOS status code, show us a rather ominous sign…. 0xA8 Setup Verifying Password… which means the BIOS is password protected. I was hoping it was 0xAb Setup Input Wait, but I quickly realized it would have been a lower-case b to differentiate between a b and an 8.

So basically this means you can't modify the BIOS settings, or boot from a different device. I did try a few different passwords and actually got back the correct 0xD8 Invalid Password code, so pretty confident that we're dealing with a protected BIOS.

I suppose there's hope that the BIOS is set to boot from a valid thumb drive if one is present, so maybe still worth a short. However, given how much effort NI has put into locking this down, I highly doubt they would have done that.

reffahcs · February 13

Well it worked…. but highly disappointing. I'm still looking through the contents but so far looks like they just jammed everything responsible for actually running the M+ in a single C++ binary, Lua scripts and PNG's and all. Some minor supporting files and a few shell scripts, but nothing major. They do be loving their pengwolf though lol.

Here's the basic layout of the eMMC. Two GPT's, a small EFI partition, rootfs, recovery, ni, home and a swap partition. The ni is around 20GB, rootfs is about 8.6GB, home and recovery are both about 1GB, and there's about 500MB of swap space.

More to follow….

LostInFoundation · February 13

https://community.native-instruments.com/discussion/comment/210836#Comment_210836

Wait…wasn’t your goal to see that pengwolf in such an awful graphic?

reffahcs · February 16

So the biggest reason that it's kinda disappointing is as I mentioned, NI shoved everything, EVERYTHING into a single binary file. It's almost like they somehow managed to cram a real file system inside the binary lol.

So every function, music playback, updates, Lua scripts, graphics. It's all inside of a single monolithic file, that's a whopping 90MB, which is pretty huge. Imagine if you opened your Windows computer and instead of Calculator, Outlook, Word, Excel, Powerpoint etc… there was just a single file called Windows.exe. That's pretty much what we have here.

It's also written in C++ which is not fun to reverse engineer. The object oriented nature of C++ makes it exponentially more challenging than C.

I'm used to dealing with embedded systems that have two or three core binaries that typically make extensive use of supporting (smaller single function) binaries and shell scripts. So I'm not very optimistic that I'll really be able to get anywhere with this.

The other issue with the images/icons and Lua scripts being int he binary is that it makes it much more difficult. On the MK3 keyboard for example, it was super simple to change the wallpaper because it's just a BMP file in a folder on the file system. When it's inside of the file though, if I wanted to update a Lua script I would be constrained to the size of the existing Lua script, there's no way to make it larger because doing so would mess up the offsets for the rest of the file. That's not to say it can't be done, but it's not as easy if they were external Lua scripts that existed in some directory.

Cheers

LostInFoundation · February 16

And then they say that it’s not easy even for them to add some basic things…

Now we know why 😏

Andy Wt · February 16

Is it possible to boot into bare OS? Just shell prompt, without any NI software, if i want to play snake just for fun

Andy Wt · February 16

Could it be that this monolithic file just loads into RAM as an partition with fast and easy accessible file system? Just for performance reasons, something like ramfs

reffahcs · February 16

It does appear that there are some different debugging/service modes available, but currently I haven't figured out how to enable them.

I'm not sure if there's a way to get the Maschine+ to but without the software launching, short of compiling your own version of Linux and flashing it to your Msachine+ but then you'd be lacking any drivers, so it would not be very fun since nothing would work.

It could be it's done for speed purposes. I was talking to a friend of mine this morning and their initial thought is that perhaps it's done for compatibility issues with other systems that may share the same code base.