cant you just bypass the encryption algorithm and find the branch where it will accept the new firmware or not, and crack from there? i dunno, might not be as simple as that
Well, if this was an x86 based app, I'd have had this ripped apart, and fully customizable by now. But unfortunately there are a few problems with something that would otherwise be trivial.
Without point of entry, I can't calculate memory offsets. This is a problem for 2 things.
1. Jump offsets can't be calculated.
2. I have no idea what chunk of code is looking at what sections of strings.
As soon as I can get memory offsets figured out, then all the byte to byte comparisons will be more useful.
i was trying to take the challenge of dissambling it. but i stopped in very early of the process. attached is what i got so far from blackfin datasheet (programming manual iirc), i dont know what good it is to anybody out there. sharing anyway.
Well, you basically were doing what I've been doing for the past week and a bit. Byte Code by painstaking Byte Code... I've yet to definitely identify what they used to compile and link it. If this is actually doing stragiht injection in the processor then entry won't be presented as the code itself is initializing volatile memory space and doing things on the fly without the need for executable header table addressing. This processor in my understanding is fully capable of doing just that. I don't think Rigol intended this to be this difficult, but the fact that auto_key_lock algorithm has been around for a good 6 years, I suspect they may have done more than we give them credit for.
I don't have the funds to dump out for a usb blackfin emulator to natively run the code base on. But since I also don't know with absolute surety how the code is getting from the flash memory to the processor, I don't know what's doing the injection. My understanding is it needs to be controlled with a PROM, but I'm still frantically reading through white papers trying to grasp as much as I can. There may still actually be a boot loader there that's wrapping the kernel. This obfuscation is what's making it very difficult to calculate offsets.
Normally yeah, it would just be a jump to bypass... flip a Jump if equal... to a Jump if not equal. I've done more than my fair share of reverses and hacks over the years. But this is taking the cake as this a completely foreign environment for me, and there's really not that much information on something that's very likely completely proprietary. A lot of the toolchains are just barely out of alpha and reaching Release Candiate Stage despite these processors being around for a few years.
I have a couple of focuses I'm going to keep plugging away at.
1. Identify a loader... and it's size... this will give earliest offset to code that I can then use for 2.
2. Write a quick program to scan the file with brute force range of suspected memory entries for a given string. The file isn't that large and I'm pretty sure most of it happens within the first 1.5 megs of the file.
3. Focus on byte code breakdowns of anything that hits those addresses instead of mass decompilation of the entire firmware package, which at present is basically impossible... but still plausible doable. I'm one to hold to slim to nil, it's still something favourable...
I'll keep you all updated. I have some other development issues with some other things I'm struggling with in overlap...