Jump to content
AVIC411.com

advanced puzzles: TESTMODE.KEY & ScriptExec.ini


Recommended Posts

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

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

Top Posters In This Topic

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

Link to post
Share on other sites

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;

Link to post
Share on other sites

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

Link to post
Share on other sites


#!/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 :)

Link to post
Share on other sites

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

Link to post
Share on other sites

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 :D

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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 ? #

Link to post
Share on other sites

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? :smile:

 

You are the maaan! :grin:

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 :D

 

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

imag0458qu.jpg

 

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

Link to post
Share on other sites

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!

Link to post
Share on other sites

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

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