edit:

here is "super" aka developer testmode. Be careful. You use at your own risk.

supertestmode.zip

original post:

So I spent some time in IDA trying to understand how the unit reads testmode.key.

From another post, it seems that there are some variations of testmode.key.

One variation launches Testmode.exe in "service" mode. (which on latest software seems to have copy feature disabled.)

Looking inside of testmode.exe there appears to be a variation of testmode called "developer" mode.

Looking at the other TESTMODE.KEY that was on the condi hackmode thread, there is a version that triggers a "scripting" mode which is run through an encrypted? file called ScriptExec.ini.

A couple of goals:

1. understand how ScriptExec.ini is deobfuscated/decrypted.

2. understand TESTMODE.KEY and if we can launch TestMode.exe in "developer" mode?

So looking at TestMode.exe in IDA, I see reference to some basic scripting commands which I suspect are encrypted in ScriptExec.ini.

Some of the commands I see available look like:

EXIST

MKDIR

COPY

REMOVE

FORMAT

//

ECHO

CLS

SLEEP

TIMER

TIME

KEYWAIT

RESET

MOUNT

VERDISP

TYPE

COLOR

ERROR

LOGSAVE

LOGERASE

MENU

GOTO

COMP

IMGOPEN

IMGCLOSE

IMGFLG

IMGCOPY

IMGERASE

IMGSEEK

ACTIVATEDEVICE

DEACTIVATEDEVICE

GETVER

BACKREAD

BACKWRITE

BACKERASE

BACKDISP

ASTSTOP

MOVIUPDATE

CIDCHECK

SETEXEC

DBGOUT

I have stared at a sample of ScriptExec.ini that supposedly copies 7z.dll to flash?. I have tried rotate, shift, and xor the bytes but nothing stands out. It could be recursively xor'ed or maybe it really is encrypted? (Judging from the rest of pioneer code, i just find that to unbelievable.) I dont see any ascii patterns or anything like arm instructions in it.

Only thing that seems interesting is that it is exactly 1024 (0x400) bytes.

Anyhow - opening the discussion on this one.

-------

Now on to TESTMODE.KEY which i had a little bit? more success with experimentation.

I started playing with bytes in the TESTMODE.KEY that was provide by condi's hackmode (which just goes into regular? "service" testmode.

Couple of observations from poking on the file, in no particular order:

1. When I was playing around with bytes, only messing with the 3rd byte in the word would seem to invalidate.

2. I actually changed the first byte in each word to anything without breaking it. I have so far changed the first bytes in each word to FF.

3. Of the "important" 3rd byte in each word, 0x44 seems to be the lowest byte int he range (and has a frequent occurrance). 0x6c seems to be the highest.

4. i could truncate the file from 164 down to 78 bytes and the file still be valid. I could also add random words, like FF 00 60 00 to the end and it did not invalidate.

5. tried trimming some words off the front, but that made it stop working

Here is where I left off.

0000000: ff00 4400 ff00 4400 ff00 4a00 ff00 6200 ..D...D...J...b.
0000010: ff00 6300 ff00 6600 ff00 6100 ff00 5500 ..c...f...a...U.
0000020: ff00 6000 ff00 4400 ff00 4400 ff00 4900 ..`...D...D...I.
0000030: ff00 6200 ff00 6c00 ff00 4400 ff00 4400 ..b...l...D...D.
0000040: ff00 4b00 ff00 4400 ff00 4400 ff00 4400 ..K...D...D...D.
0000050: ff00 4400 ff00 4400 ff00 4b00 ff00 6700 ..D...D...K...g.
0000060: ff00 5900 ff00 6600 ff00 6a00 ff00 5d00 ..Y...f...j...].
0000070: ff00 5700 ff00 5900 ff00 6000		 ..W...Y...`.

So opening this up to a puzzle contest. ;0

sweet.. i think i just figured it out.

the range on the chars the were only a few apart (like an alphabet) - looked suspiciously like a shift cipher.... it is ... by 14 hex (20 chars)

if i shift down 14h, here is what I get:

006NORMAL005NX007000007SERVICE

Looks like there are a few things embedded into that string.

006 = number of digits in NORMAL

005 = number of digits in NX007 (platform ID)

there is a 000 im not sure about.. maybe a null field

007 = number of digits in SERVICE... guessing this is the "service" vs "developer" mode of testmode ....

Looking at TestMode.exe in IDA already seeing some interesting possibilities....

.data:00107568 aProduct	 unicode 0, <PRODUCT>,0 ; DATA XREF: sub_14750+24o
.data:00107568										 ; .text:off_14DA8o
.data:00107578 aScript		 unicode 0, <SCRIPT>,0
.data:00107586				 ALIGN 4
.data:00107588 aDirect		 unicode 0, <DIRECT>,0
.data:00107596				 ALIGN 4
.data:00107598 aAuto		 unicode 0, <AUTO>,0
.data:001075A2				 ALIGN 4
.data:001075A4 aNormal		 unicode 0, <NORMAL>,0
.data:001075B2				 ALIGN 4
.data:001075B4 aNandup		 unicode 0, <NANDUP>,0
.data:001075C2				 ALIGN 4
.data:001075C4 aAll_0		 unicode 0, <ALL>,0
.data:001075CC a09light	 unicode 0, <09LIGHT>,0
.data:001075DC aNx007		 unicode 0, <NX007>,0

.data:00107F08 aTechnical	 unicode 0, <TECHNICAL>,0 ; DATA XREF: sub_167D4+18o
.data:00107F08										 ; sub_167D4:off_1698Co
.data:00107F1C aService	 unicode 0, <SERVICE>,0
.data:00107F2C aMantest	 unicode 0, <MANTEST>,0

I'll be trying this out very soon .....

bingo - im in "Developer mode" which has a boatload of other test function (many probably VERY DANGEROUS).

Great thing is copy is enabled.....

006NORMAL005NX007000009TECHNICAL

note to self: need to make a perl script to encode/decode these TESTMODE.KEYs

awsome....

I just decoded the TESTMODE.KEY that was posted in condi's hackmode thread that came with the ScriptExec.ini:

./decodekey.pl "Rewriting Script/TESTMODE.KEY"

006SCRIPT005NX00700002002010020301122334400000�

looks like that last field is 020 chars:

02010020301122334400

I'm guessing thats a decryption/encryption (or obfuscation) key for ScriptExec.ini plus some extra zeros?

Now to figure out how they are doing encryption...

code to decode the TESTMODE.KEY... Working on extending this to encode it as well...

#!/usr/bin/perl
my $filename = (shift);
open(my $fh, $filename) or die $!;
binmode($fh);
my $cnt = 0;
while ( read($fh, my $byte, 1) )
{
if ($cnt % 4 == 2)
{
$byte = ord($byte) - 0x14;
print chr($byte);
}
$cnt++;
}
print "\n";close $fh;

holy shit. thats just fantastic!!! pionara - fckin GREAT job!

thinking further - we could replace 'handicaped' dlls from windows and get working all the win ce apps without changing references to other dlls

so many possibilities... monday morning im going to get my avic disassembled from car, and gonna put it in home for testing

#!/usr/bin/perl
my $filename = (shift);
open(my $fh, $filename) or die $!;
binmode($fh);
my $cnt = 0;
while ( read($fh, my $byte, 1) )
{
$byte = ord($byte) + 0x14;
$hexx = $hexx . chr($byte);
}
$cnt++;

$hexx =~ s/(.)/'FF00'.sprintf("%x",ord($1)).'00'/eg;

open FILE, ">!ENCODED_testmode.key" or die $!;
printf FILE pack 'H*', $hexx;
close FILE;

print "\n\n\nEncoded TESTMODE.KEY: \n\n------------------------------------------------------------------------------\n";
open(BINN, "!ENCODED_testmode.key");
print <BINN>;
print "\n------------------------------------------------------------------------------\n\n(saved in '!ENCODED_testmode.key' file)\n";

close $fh;

I've updated ENCODE code, now it saves binary file correctly from hex data.

Pionara please check it out. Its still not perfect - adds some data in few last characters in the end of the file, you have to cut it out.

Don't know the reason. But the base of the encoded key should be correct

thanks condi - here is what i came up with:

usage is ./encodekey.pl INPUTFILE OUTPUTFILE

where INPUTFILE is a simple ascii text file with the string you want to encode, and output file is like TESTMODE.KEY

#!/usr/bin/perl
# testmode.key encoder by pionara
my $infile = shift;
my $outfile = shift;
open(my $ifh, $infile) or die $!;
open(my $ofh, ">", $outfile) or die $!;
binmode($ofh);

while ( read($ifh, my $byte, 1) )
{
my $sb = ord($byte) + 0x14;
print $ofh chr(0xFF), chr(0x00), chr($sb), chr(0x00);
}
close $ifh;
close $ofh;

i have a newline in the input text file, and it encodes it, but the unit still launches in to developer testmode just fine when i feed it 006NORMAL005NX007000009TECHNICAL

Also, my x930bt launches testmode from USB just fine, including USB uSD card reader...

just checked your final script, work just fine on f30bt with old v3.00 testmode PLT. "for developer"

gonna keep on testing the new possibilities..

looks like that last field is 020 chars:

02010020301122334400

 

I'm guessing thats a decryption/encryption (or obfuscation) key for ScriptExec.ini plus some extra zeros?

Now to figure out how they are doing encryption...

Maybe Alberti Cipher's 20 character Latin alphabet? lol

Man I wish it were that easy. Doesnt really "look" like a shift-cipher that I can see, plus it's perfectly aligned at 1 kbyte which looks like some block cipher like 64-bit probably.

I suspect they are using something simple like RC2 or DES, but I cant really tell, and I dont see where they might be using some windows crypt api.

When I do a bit of digging there are some interesting crypto functions down inside of private subs in NPCryptDec::ScanLine(char *,ulong,bool *) of NPCommonLib.dll

there are a few subs in there where they are doing lots of shifting, ORing, XORing, etc. Definately crypto-like stuff, but lots of it. Just doesnt feel like they would have re-invented the wheel for such a trivial thing, so I would highly suspect they just copied and pasted some crypto boilerplate code without any modification. (Well, let me say, hope-so!)

Nice work guys.

so more cool stuff...

I passed 000 to the field which i suspect is the decryption key. Seems like the unit doesnt attempt to decrypt ScriptExec.ini, and just executes the script as plaintext.

So with this in testmode.key: 006SCRIPT005NX007000000000

Here is the script i was playing around with:

ECHO ON
ECHO PIONARA WUZ HEREZ
// COMMENTS??
// DBGOUT USB (errors w/ no arg, file path, or device...)
TIME
// TYPE USER\SYSTEM\SECURITY\PASSWORD.DAT
COPY USER\SYSTEM\SECURITY\PASSWORD.DAT USB\EXISTINGFILE.TXT
COPY -c USER\SYSTEM\SECURITY\PASSWORD.DAT USB\NEWFILE.TXT
MKDIR USB\NEWDIR
// this doesnt seem to be working?
COPY -r USER\PRG1\APL\* USB\NEWDIR
// NOT SURE WHAT SETEXEC DOES... doesnt seem to have an effect
SETEXEC USB\TOOLS\EXPLORER.EXE
REMOVE USB\TESTMODE.KEY
ECHO BEFORE SLEEPING FOR 9 SECS
SLEEP 9000
RESET

Here is what I got:

Also seems that some commands (like COPY) can take certain flags:

-rc

-r

-c

-err

-exe

-exp

-size

-data

-w

-more

-str

-n

-f

For example with copy, it will error if the file doesnt exist. seems like -c may allow creation if it doesn exist. I expected -r to be recursive? allowing for a recursive dir copy, but sadly, I havent figured out to copy entire folder structures yet... but im sure we will figure it out with a bit of experimentation.

When I hit a bad syntax usage of a command, I got a red screen with the command error (although sadly it doesnt give me any usage hints -- cmon pioneer!!!)

I think we will really really need to see the decrypted ScriptExec.ini that came from pioneer for the 7z.dll to see how they are adding/replacing stuff in the rom/nand area

Bewarned! there are some very dangerous looking commands there.. I would advise you not to play around with this unless you really know what you are doing.

ok, so duh - in order to do a recursive copy if the target files/dirs dont exist, you need -rc. A few syntaxes that I can see so far:

COPY src dst

COPY -r src dst

COPY -c src dst

COPY -rc src dst

(r is recursive, c is create if not existing)

REMOVE file

REMOVE -r dir

MKDIR dir

TYPE file

TYPE -more file

COMP ? ? ?

COMP -size ? ? ?

COMP -data ? ? ?

EXIST ? #

Comp - compare?

Setexec - maybe a command to execute another script inside existing one?

Have you tried to copy for example Explorer.exe to Windows with - rc?

You are the maaan!

Now i can make condi hackmode fully automatic installation !

edit:

got script ready, gonna test it today evening, avic is now being disassembled

edit2:

avic in my car, but on the front seat

tried to write some file to windows dir, unfortunatelly there is probably some extra function for it..

TST_ScriptCmdBase.cpp :> if we could see details of that error, maybe there would be some hints.

the full answer is in (unfortunatelly encrypted) script from 7z patch...

right - as far as I can tell in this scripted mode, the only "root" folders you can copy to/from are USB\ SD\ USER\ and NDATA\

I suspect that pioneer script may be using one of the other commands like IMGOPEN IMGCOPY IMGCLOSE, etc, but I'm reluctant to play around with those as they could very very dangerous

edit: what I need is a spare x920 or z110 that I can play around with to speed up my development/testing cycles. It's a very slow process of trying something then taking it out to my car and going back and forth. I don't want to pull my radio out of my car, as I can live without tunes!

edit: what I need is a spare x920 or z110 that I can play around with to speed up my development/testing cycles. It's a very slow process of trying something then taking it out to my car and going back and forth. I don't want to pull my radio out of my car, as I can live without tunes!

yeaaah I know what you feel

made that way all the hackmode versions and all the experiments, many many hours in car, even after midnight lol

now i've got my avic in my home, its very handy now to test something new

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

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.

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 ?

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

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.

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

niceeeee we are getting closer and closer.. keep up the good work!

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/

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

Pionara,

Do you have some tool to encrypt scriptexec from the key in the testmode.key?