no - i wish, this would be lots easier.
I am trying to reverse this. Seems like hte only thing that exists are decryption routines in NPCryptDec::ScanLine(char *,ulong,bool *) of NPCommonLib.dll
Unfortunately, I dont have IDA pro (just using crappy free/demo) version, and im just a novice at ARM instructions.
There definately seems to be something going on inside of some of those subs where I see lots of EOR (XOR), AND, shifting, etc. If i could figure out what its doing that would be good too.
Any progress yet?
I am thinking of creating an app that uses the dll to decode. Only difficult part would be resolving the parameters needed for openfile and scanline.
If there is someone who knows how to reverse engineer the dll that would be lots easier...
NPCommonLib.dll has scanline. Inside scanline there is a sub function read. Inside read there is a lot of shifting going on. I think it is in there.
sorry - no progress here...
I did spend some time looking at whats happening in scanline. It seems that it takes the first and second 32-bit dword pairs and does quite a bit of shifting/xor/anding, with the 2 words against each other, etc. It's quite extensive. I started to try to reimplement in perl, but gave up after the first function.
There are like 1000+ instructions with this and some loops. I think somebody could just write a ce .exe that calls this dll functions to pass in and then break it in a debugger to see what the output is.. Of course you would need to generate a header file 
- dont have IDA Pro to do this...
Of course, hexrays decompiler would be good as well - but dont have an extra 1000 euro to spend for this 
at this point i'm suspecting TEA (maybe 10x cycles?), but havent really try to run it through...
oh well.
I thought i would be slick and try a different attack, that is instead of going in through the front door, peek in the side window (to borrow some Bruce Schneier tactic) hehe
The idea was to shuffle/delete a few of the 20h long crypted lines in order to exploit the ECHO lines near the front. Basically it works - I am able to see the payload commands..
Ahh but sadly, they are not what they seemed they would be. I thought for sure we would see the usage of IMGCOPY etc to replace files in flash, but no - it's just copy commands to APL folder - everything we already know about
Oh well. I'm giving up on the decryption. I learned quite a bit and ready to move on to the nag screen challenge.
Well that sucks..
Still interrested in the mount command.
Scripting isnt the way to go then.
I'm interrested in the service manual.
If you look there you see a possibility to boot from external sd card. You can find it in the wiring diagram there is a little table there.
Another thing is the jtag connector. I am 90% sure that that is a way to unbrick.
We can then safely modify and test all prg files.
The point is the avic has a rtck wire. Adaptive clock. I dont know which (cheap) reader support that kind of jtag.
The avic has 2 jtag connectors. One directly on the nand or something and one on the cpu
Well that sucks..
Still interrested in the mount command.
Scripting isnt the way to go then.
I'm interrested in the service manual.
If you look there you see a possibility to boot from external sd card. You can find it in the wiring diagram there is a little table there.
Another thing is the jtag connector. I am 90% sure that that is a way to unbrick.
We can then safely modify and test all prg files.
The point is the avic has a rtck wire. Adaptive clock. I dont know which (cheap) reader support that kind of jtag.
The avic has 2 jtag connectors. One directly on the nand or something and one on the cpu
Hello,
Can you plese provide the jtag pins?