Jump to content
AVIC411.com

advanced puzzles: TESTMODE.KEY & ScriptExec.ini


Recommended Posts

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..

Link to post
Share on other sites
  • Replies 31
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to post
Share on other sites

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 ?

Link to post
Share on other sites

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

Link to post
Share on other sites

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..

Link to post
Share on other sites

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/

Link to post
Share on other sites

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 ;)

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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 ;)

Link to post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...



×
×
  • Create New...