Thanks Tamas. I'll check out. On Aug 13, 2015 4:01 PM, "Tamas Rudnai" wrote: > I am reversing software daily basis (malware analysis), but for that we > have easy access to the software, which is not always the case for > firmware. If you have firmware updates as on files, it makes everything s= o > much simpler, but I guess that is not a big news for you :-) > > If you have the firmware, one of the industrial standard for reversing is > IDA Pro -- but that is not very cheap... Few years back I have put a very > simple PIC disassembler together in (khhhhmmm) Perl script. I have put so= me > very basic program flow analysis in there to be able to track down which > program memory pages and memory banks which was not very well done by oth= er > software by that time. But still, this was only helping to translate the > machine code back to assembly language, no library recognition or C code > decompiler and anything fancy in it. > > Anyways, I guess if the circuit still works it would be still easier to > analyze its signals and behavior and just do the forward engineering base= d > on that. the only exception I would say if you only need to tweak some > settings here and there and no need recompilation, just few patching of > data bytes, replacing a string etc. > > For me reversing a Windows executable is somewhat simpler than a PIC > firmware, even though the code is 100 fold bigger - simply because you ha= ve > APIs and symbols and IDA Pro will find common libraries compiled into the > code so you do not need to deal with that. So after few minutes of playin= g > with the code you will have a general idea what kind of application is > that. Does it connect to the internet? Does it open or create files and > registry keys? Does it use cryptographic libraries etc? These are very ea= sy > unless the code is obfuscated, but that is another story. Compared to thi= s > with a PIC disassembly you probably will have no luxury of automatic C > library determination or RTOS if used any and you need to know the hardwa= re > first to be able to tell what this or that port is connected to and what > PWM driver or the I2C is going to do. > > Tamas > > > > On Wed, Aug 12, 2015 at 8:50 PM, Peter Q. wrote: > > > Hi again, sorry for inconvenience. > > Bob, you're right. > > "When you are > > attempting to fix a broken something, you are doing the ultimate revers= e > > engineering, figuring out how it SHOULD have worked. We all approve of > > that." > > > > Randy, thanks I'm looking for... Glitching > > David, Firmware and/or Hardware. > > > > Actually I'm looking for new resources of Electronics reverse > engineering > > nowadays, because I'm attempting to fix a broken something so what are > the > > best techniques? > > I don't do illegal things. > > > > Thanks. > > -- > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > > View/change your membership options at > > http://mailman.mit.edu/mailman/listinfo/piclist > > > > > > -- > int main() { char *a,*s,*q; printf(s=3D"int main() { char *a,*s,*q; > printf(s=3D%s%s%s, q=3D%s%s%s%s,s,q,q,a=3D%s%s%s%s,q,q,q,a,a,q); }", > q=3D"\"",s,q,q,a=3D"\\",q,q,q,a,a,q); } > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .