MSC26 and MSC16

[14roiron]

Last month when I looked at this repo, my lamp was not supported. Now It is the case, But in the mean time, I was trying to reverse the libMSC26/ LibMSC16 (but it seems that the one required for my lamp is MSC26A.) I do have the code now, as on my app, it is called in a circular manner:

final byte[] advData = getAdvData(b, bArr); //libMSC16
        final byte[] advData1 = getAdvData1(b2, bArr2); //libMSC26
        final byte[] advData2 = getAdvData2(b2, bArr2);//libMSC26A
        this.currentPos = 0;
        removeMessages();
        Timer timer = new Timer();
        this.mTimer = timer;
        timer.schedule(new TimerTask() {
            public void run() {
                int access$300 = BLERequest.this.currentPos % 3;
                if (access$300 == 0) {
                    BLERequest.this.mBeaconTransmitter.startAdvertising(advData2);
                } else if (access$300 != 1) {
                    BLERequest.this.mBeaconTransmitter.startAdvertising(advData1);
                } else {
                    BLERequest.this.mBeaconTransmitter.startAdvertising(advData);
                }
                BLERequest.access$308(BLERequest.this);
                if (BLERequest.this.currentPos >= 60) {
                    BLERequest.this.removeMessages();
                }
            }
        }, 0, 120);

I also have the frida script that I used to dynamically verify the app. Would that be helpful for the project, do you know the difference between these? I guess different versions?

Thanks for the update! 14Roiron

[aronsky]

Hi, the current code generates messages based on the MSC26A algorithm. If you need MSC26A, it should just work.

The app does indeed generate messages using all 3 algorithms and sends all 3 consecutively (the communication with the lamp is one-way, so the app doesn't really know what type of message the lamp expects). However, rewriting the algorithm was a PITA, so I only did it for for MSC26A for now (as that's what I needed for my driver).

I actually used a combination of decompilers (mostly Ghidra) and AI (assembly to C converters) to generate the code - that's why it looks so sh*tty and the variable names mostly match register names :) So if you need to do the same for MSC16 or MSC26, you can try that approach (and if ARM64 gives you trouble, you can try ARMv7, it might yield more ineligible results).

[14roiron]

Hello, Sorry I was not clear, I have them here: https://gist.github.com/14roiron/57dae33a9b18ad101384b3615fbdcb49 Do you think it will be worth it to include them in your code? I did the same as you, ghidra+GPT4. I also use a lot Frida, to be able to verify the code

[aronsky]

Oh, absolutely. But I think it would be better to set the algorithm using a configuration option, instead of transmitting all 3 types of messages as the app does. After all, unlike the app, a user of this repo has the privilege of knowing what kind of LED driver they are working with.