pionara Posted September 23, 2012 Report Share Posted September 23, 2012 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 Quote Link to post Share on other sites
pionara Posted September 23, 2012 Author Report Share Posted September 23, 2012 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 ..... Quote Link to post Share on other sites
pionara Posted September 23, 2012 Author Report Share Posted September 23, 2012 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 Quote Link to post Share on other sites
pionara Posted September 23, 2012 Author Report Share Posted September 23, 2012 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; Quote Link to post Share on other sites
condiczek Posted September 23, 2012 Report Share Posted September 23, 2012 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 Quote Link to post Share on other sites
condiczek Posted September 23, 2012 Report Share Posted September 23, 2012 #!/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 Quote Link to post Share on other sites
pionara Posted September 23, 2012 Author Report Share Posted September 23, 2012 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... Quote Link to post Share on other sites
condiczek Posted September 23, 2012 Report Share Posted September 23, 2012 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 Quote Link to post Share on other sites
pionara Posted September 23, 2012 Author Report Share Posted September 23, 2012 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!) Quote Link to post Share on other sites
mattaleao Posted September 23, 2012 Report Share Posted September 23, 2012 Nice work guys. Quote Link to post Share on other sites
pionara Posted September 23, 2012 Author Report Share Posted September 23, 2012 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. Quote Link to post Share on other sites
pionara Posted September 24, 2012 Author Report Share Posted September 24, 2012 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 ? # Quote Link to post Share on other sites
condiczek Posted September 24, 2012 Report Share Posted September 24, 2012 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... Quote Link to post Share on other sites
pionara Posted September 24, 2012 Author Report Share Posted September 24, 2012 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! Quote Link to post Share on other sites
condiczek Posted September 24, 2012 Report Share Posted September 24, 2012 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 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.