pionara Posted September 24, 2012 Author Report Share Posted September 24, 2012 another interesting command: KEYWAIT [uP, DOWN, LEFT, RIGHT, ANY, CANCEL] I tried KEYWAIT ANY... it waits for any keypress there is also RESET which reboots. Condi, you could use this after removing/renaming TESTMODE.KEY on the USB/SD card seems like DBGOUT [ON,OFF] - but setting this on didnt do anything, looking in the code, this might have something to do with serial port debugger (I would drrrroooll to get my hands on serial debugging tools... we would seeeeeriously be in the awsome) GOTO label where label like "MYLABEL:" there is MENU command, and then in code, there are some either params, or something else: ScriptMenuItem, MenuTitle, MenuControl, ScriptExecFilePath Not sure how those are passed to MENU. Maybe it's a file? Maybe its part of the arglist to menu, or somethign else? There is SETEXEC with something called ScriptFile. Again, tried pointing it to another script or executable.. nothign happened that I could see.. Quote Link to post Share on other sites
condiczek Posted September 24, 2012 Report Share Posted September 24, 2012 There is SETEXEC with something called ScriptFile. Again, tried pointing it to another script or executable.. nothign happened that I could see.. It somehow works. In first ScriptExec.ini: SETEXEC otherone.ini in root of sd I created otherone.ini with some ECHO. First script done. then on every reboot it will run otherone.ini! Not once, on every reboot. Quote Link to post Share on other sites
pionara Posted September 24, 2012 Author Report Share Posted September 24, 2012 oh, interesting.. maybe i didnt notice that one. I was thinking it acted like an include file. Does it get permanently stuck that way, or just when testmode.key is active in SCRIPT mode? (If only we could find a way to launch an .exe somehow. Would make things much easier to do a hackmode). Hrmm, maybe the "vars" that I see like ScriptFile, ScriptMenuItem, MenuTitle, MenuControl, ScriptExecFilePath, etc are stored in nvram or something.In fact, there are some command about "BACK...." When I look at NPCommonLib.dll, there are several classes/methods dealing with BackupFile manipulation. I suspect maybe there is an nvram or file stored on a hidden partition with these? On a side note, I really, really want to see what is inside of the pioneer scriptexec.ini. So I got the bright idea that I could see what the script is doing if we turn ECHO ON. of modding testmode.exe at the point where it judges ECHO ON vs ECHO OFF vs ECHO SOMETHINGELSE. I patched ECHO OFF to act like ECHO ON. I have a modded testmode, but the trick is to replace it so that it gets launched when unit reboots. I think NEventWatcher.exe is the one that intercepts USB\TESTMODE.KEY or SD\TESTMODE.KEY and reboots/init's testmode.exe. I tried using mortscript to copy my patched testmode.exe to \Windows, but alas, even on softreboot, it is wiped out which is typical if it OS is loaded into RAM each start. I saw in another thread some guys working on patching testmode in the ROM (EU090PLT.PRG). Has anybody verified that they are able to repack/add files to this and safely reflash via dumpromx ? Quote Link to post Share on other sites
condiczek Posted September 24, 2012 Report Share Posted September 24, 2012 I saw in another thread some guys working on patching testmode in the ROM (EU090PLT.PRG). Has anybody verified that they are able to repack/add files to this and safely reflash via dumpromx ? yes on russian forum some user made modified firmware with patched testmode for copy/paste. he also wrote a lot about structure of .prg file - header, body, crc etc. and we got some info here also Quote Link to post Share on other sites
pionara Posted September 25, 2012 Author Report Share Posted September 25, 2012 yeah i started my own thread on this so the big minds can discuss. I dont think that was exactly right. You can see what I have so far: http://avic411.com/index.php?/topic/35271-eu090pltprg-platform-file/ My next trick will be to (safely) repack and reflash. Quote Link to post Share on other sites
Melvin v/d berg Posted September 25, 2012 Report Share Posted September 25, 2012 Access to the windows dir should be possible with the MOUNT command I think.. Now about decrypting the ScriptExec.ini: The exact string of testmode.key is: 006SCRIPT005NX0070000200.201002030.1122334400000ì There are two parts in here. First 20100203 which is a date 2010-02-03. Second is 112233440000 The two strings are sepparated by 0. which is in hex 3018. testmode.key always end with ì which is EC in hex. From this I think the key is 11223344, 1122334400 or 112233440000. Now about the encryption technology: In testmode.exe there is an external class (after a long search) NPCryptDec or CryptDec. This class has the following functions: OpenFile(filename?,NPCryptKeyCode), CloseFile() and ScanLine(char *, bool *). This class is NOT in testmode.exe but in NPCommonLib.dll. Now I only need to find the algorithm in NPCommonLib.. Hope it is a basic algorithm and not homebrew one. There are also some funny menu items in testmode I found in IDA: GPS BIOS secret menu API TEST secret menu Could be usefull.. Quote Link to post Share on other sites
condiczek Posted September 25, 2012 Report Share Posted September 25, 2012 niceeeee we are getting closer and closer.. keep up the good work! Quote Link to post Share on other sites
pionara Posted September 25, 2012 Author Report Share Posted September 25, 2012 Hi Melvin, Thanks for your post - I went back and looked at the hex a second time. It appers that there are some non-printables in the 20 char "field" that perl's chr doesnt print properly. Sends a zero instead of the non-printable. In fact looking at that string again, the pre-decoded hex is 2C, so either a comma if unshifted, or 0x18 (which is ^X ??). Im wondering if it is interpreted as a separator. If thats the case then the value of the field would be more like: 0,201002030,1122334400 I'm not sure if it would include the separator? fields in the 020 length or what. it's a bit of a mystery! If so, then maybe a final "null" field of 000 I suspect the last byte 00 may be unshifted, and just null string terminator of TESTMODE.KEY here is the base64 of that ScriptExec.ini in question: GbKruRDtRGrUhFkAG3aqbCjRjYRnhSYaS4M/H6EJ32pIs+Nrw54GwmmQrrjLwnSRyiMvs5XHShMLhx1LQLFgDIbTCKzgwdFpm3UqspwnFMKU7EmAktBaeqq/NPPF+hf0S5anails04iJkIAahsG/PYN3I4FdCotwFJDEtaRW72o5ZjqxTYFRaJyGCkNCnyAyN81ZjuybGFQ9ub7ysbOhlXKCSeLvHdOOZ1qM7tS2XENpybFTufclbkweV9Hlxuut1ORI4jhbdXWB0E55GlWU4MbfydHm0iXMimbKC7pr6kp3Yy5rqATfLgaTZ01krHhQ7DdNDi7bMjkm6JcCjl6nDuZCdxr60nj2jbAQ/KUtd/XbRyLjaCZscqrCJUzz8cFZeH4oliEnOEb99V0+8zosLRSdA4rvwr4lYmeL61C58fQ3grzScSAacrWi/EqoJX6lamkKJWSWGv2FWmBD3AUaRWX91i6s6NgBDKtQqQIov/jr/cmPy3Q6XCIZwEY3H7wp9qtkk4Kl+qy0BIQrBErqRMsaeXcz0cAHuntqs16me/xKeWSVyLSNqREEPaOjqFFfhtxbv9TSdFgiVMSPLGuozPipZQ9fzCRpYND4PyW9EQ6BNZMY8OGT9cv25v+MVwW0N3E5Zk9GY+pqHF7KFiNnVY3URD9FmhGnfMweIzBUb+//rN0oTuJ5oM8T0K1i0Br3G03PnMQKJJMqzjlwT0G3DbTm3A/KwFgEgxip1QbfZ2c2bKJjl85GZJbMZ717sEpjFHniCh1xuq6QtSF3PBpN/qiOJsCdBTkr5senultTemlSqN/O++sUVJS23QgLEaALYh762uoBnfj+LCmnA4CMxoWykGJwycxqo2kKVoexHmBGR3+wXaFRLYriEQnfNpxcLjNucxeLH5TZeo6gCh2ljEn7PW3EKtpxx2fZYKVQObMqOlBiikfn1ZGMSnSonCIAn2HlgfsLIUA4cLw7+WFbHyEx5aYMxmEwCn8j08+2cnTci9GlGK7aa3wQ132o22FjuPifwnZTxwCQCoxXwYEU8scT6YhgAre2rZaI+TakdY8sE4FhpxPiJf3/41bcGn2s2GOUo1PMKnHKdrIEmBtTEfTP87smq+hNAB0IWAIuQ88X7ki1DdDQ3Tep0ZtN1RBGsxmfQDjZzGJAZTuDJCoLZvGHM0JLIYmbdJPes9pjJWVTTEitJkFKgfSx7BNOpGlTDNANEjadvrWCW1Qs8y6PwiYRktaoXO24VaqOOWSlOp/GGfNUbOhEw8XMi3lW8rSrztsS/b6corONsuQo6+xmZq5sCHPM5ntGkk/wuSrbfDiHsd4KSCSsPU/PRNoZ2+s+VtRwaNgaEpg8cJYe7Upzng== using this tool, for example, getting nothing: http://www.tools4noobs.com/online_tools/decrypt/ Quote Link to post Share on other sites
pionara Posted September 25, 2012 Author Report Share Posted September 25, 2012 ok, i am getting somewhere. this is definately NOT encrypted. just simple shifting or something. the 020 before the field is in hex (duh!) not decimal, so it's 32h. I incremented one value in the encryption field at a time, and I noticed once every 32 chars in the output of the script a group of chars get "modified". If I increment once more, it shifts again, but it's somewhat strange -trying to figure out the exact logic, but it's a loop every 32 bytes. Somehow the key field contributes to this. edit: ok a couple of observations, but still stumped. Seems like only this part of the "key" affects the decoding of the: 0,201002030,11223344 If i change just one hex in this by one, it appears to shift one (or more?) chars in the output, but in a repeating pattern of every 32 bytes. As far as the "encoded" ScriptExec.ini, from what I can tell, every 8 bytes seems to be a block corresponding to an 8 char block of ascii. Unfortunately here, I get some odd results. When I increment or decrement any one byte in the group, the output of the whole group changes, sometimes with more than 8 chars being output. There does not seem to be a 1-to-1 relationship between the input and output bytes, and there does not seem to be a pattern to the shifting, but instead the whole output group is changed drastically with a change to one input bit. This leads me to believe that there may be some functions applied to these. Then it seems somehow the "key" is an input to a function against group of 32 bytes, where only certain positional changes are made. Still very much a puzzle at this point... Update for tonight: Making glacial progress. seems like the "key" field in testmode.key is just bitwise OR'd byte for byte against whatever is output from the algorithm that each group of 32 bytes generated from ScriptExec.ini, and that is taken as the ascii output. On a hunch, trying to turn off enough bits in the "key field" that still allows some display (ECHO) comands through, but gives me a "clean" enough window to observe bit flipping outcome on ScriptExec.ini. Oh, and I think the actual OR "key" mask in hex might be: 30 18 32 30 31 30 30 32 30 33 30 18 31 31 32 32 33 33 34 34 30 30 or at least the first part of that. I was able to truncate everything after the last two "zeroes" (raw value 44h) in testmode.key, and the script would execute and decrypt normally. As far as poking on on ScriptExec.ini, to make things easier, I just truncated the file to ~100h (256 bytes). (So I get enough lines with ECHO but dont hit the CLS and other commands in there.) The first part of the output text should be: <<CAUTION!!>> You are solely responsible for any file changes. Once changes are made, returning to the original file is not possible. The application may not be able to start after changes are made, and our company is not responsible for any problems due to these changes. There are definately a few "invisible" lines prior to these, however I'm sure each of these lines is just prefixed with an "ECHO " - this should help us home in on this. in that text for example, here are two sample blocks (from "solely responsible" text section): AABF34F3 C5FA17F4 -> "lely res" 4B96A76A 296CD388 -> "ponsible" Man - I need some bitshifting experts to help here Quote Link to post Share on other sites
Melvin v/d berg Posted September 26, 2012 Report Share Posted September 26, 2012 Pionara, Do you have some tool to encrypt scriptexec from the key in the testmode.key? Quote Link to post Share on other sites
pionara Posted September 26, 2012 Author Report Share Posted September 26, 2012 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. Quote Link to post Share on other sites
Melvin v/d berg Posted October 3, 2012 Report Share Posted October 3, 2012 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. Quote Link to post Share on other sites
pionara Posted October 3, 2012 Author Report Share Posted October 3, 2012 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 Quote Link to post Share on other sites
pionara Posted October 5, 2012 Author Report Share Posted October 5, 2012 at this point i'm suspecting TEA (maybe 10x cycles?), but havent really try to run it through... http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm Quote Link to post Share on other sites
pionara Posted October 9, 2012 Author Report Share Posted October 9, 2012 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. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.