Steinar H. Gunderson wrote:Well maybe really maybe you could get the HEX source if you try really hard.. But then.. Hex source to readable code is really hard..
By “HEX source”, I assume you mean machine code? A disassembler will turn it into assembly code easily enough.There is software that does a good job.. But never 100%.. So getting it back to C/C++ for read-able code will not be easy at all.....
I assume you're talking about Hex-Rays? (That's the only really good decompiler, at any rate. There's other stuff like Hopper that claims to be “decompilers”, but Hex-Rays is a totally different league.) That works with x86, PowerPC and ARM only, so not applicable here.I think it will take more time then start from scratch honestly..
As someone who's done a fair bit of software reverse-engineering, I'm pretty sure this isn't the case; monkey-patching in one bugfix is vastly less work than making a program from scratch. But I agree Blackmagic should just fix it themselves, so I don't plan to make an attempt. (For all I know, the firmware could be encrypted and/or signed, making it impossible to flash modified firmware.)
Well - HexRays is my day job ( broadcast was my day job - but is now just a hobby )
The results with HexRays are hugely variable - it depends on what metadata you have available ( symbols / hardware documentation ). It also depends on the cpu type and how well supported that is in the HexRays plugin ( x86/Arm well supported - PowerPC support just introduced - anything else you'll have to manually convert the disassembly to pseudocode ).
I would say that patching such a simple function would be the easiest - but back to source may be the most useful.
Back to compileable sourcecode is definitely possible - the decision is whether it is the most efficient solution and if it is legal in your particular country / circumstances.