Jump to content
AVIC411.com

Upgrading NEX4000 to NEX4100 - Work in Progress


Recommended Posts

  • Replies 623
  • Created
  • Last Reply

Top Posters In This Topic

Ok I have modified the script and created an encode script. Now we just need to know the available commands!

 

Decoder:

#!/usr/bin/perl
# usage perl decode.pl TEST.KEY

my $filename = (shift);

open(my $fh, $filename) or die $!;

binmode($fh);

my $cnt = 0;

my $encodeString = "";
my $otherString = "";

while (read($fh, my $byte, 1))
{
	if ($cnt % 2 == 1)
	{
		$byte = ord($byte) - 0x14;
		$encodeString = $encodeString.chr($byte);
	} else {
		 $byte = ord($byte) - 0x14;
		 $otherString = chr($byte).$otherString;
	}
	$cnt++;
}

print $encodeString.$otherString;
print "\n";

close $fh;

Encoder:

#!/usr/bin/perl
# Usage perl encode.pl 008Recovery003ALL00833333333009AllUpdate0082013010100820201230000 OUT.KEY
my $string = shift;
my $outfile = shift;
open(my $ofh, ">", $outfile) or die $!;
binmode($ofh);

my $stringLength = length($string);

$stringHalfLength = ($stringLength/2);

$string1 = substr($string, 0,  $stringHalfLength);
$string2 = substr($string,  $stringHalfLength,  $stringHalfLength+1);

$string2 = reverse $string2;

for (my $i=0; $i < length($string2); $i++) {
   my $string1Byte = ord(substr($string1, $i, 1)) + 0x14;
   my $string2Byte = ord(substr($string2, $i, 1)) + 0x14;
   
   if($i > length($string1)-1) {
      print $ofh chr($string2Byte);
   } else {
      print $ofh chr($string2Byte), chr($string1Byte);
   }
   
}
 
print "\n";

close $ofh;

Here is the output of the current TestMode Keys we have that are known to work:

 

TESTMODE_A.Key - Triggers the unit to reboot once it is started up into what we think is the TestMode.apk

 

007SERVICE003ALL00833333333007SERVICE0082013010100820201230000

 

testmode_n_1/TESTMODE_N.key  -  Triggers the unit to reboot into recovery mode once it is started up.

 

008Recovery003ALL00833333333009AllUpdate0082013010100820201230000

 

testmode_n_2/TESTMODE_N.key  -  Triggers the unit to boot into EasyRecovery Copy & Verify Mode (Where I think it just dd's from the source device to the internal sd card)

 

008NORFLASH003ALL00833333333010COPYDEVICE0082013010100820201230000

 

testmode_n_3/TESTMODE_N.key  -  Triggers the unit to boot into EasyRecovery Mode Change Mode (Where I believe it just changes the mode, as the screen just says mode changed, so the string must contain the mode to change to)

 

008NORFLASH003ALL00833333333010MODECHANGE0082013010100820201230000

Link to post
Share on other sites

Ok found some more modes that are available with the TESTMODE_A.key and the contents:

 

XXTECHNICALXX - Starts up into a mode very much like the Service mode above, except it has a lot more debugging options.

 

013XXTECHNICALXX003ALL00833333333013XXTECHNICALXX0082013010100820201230000

 

PRODUCT - Starts up like the Service mode, seems to have a combination of Service and Technical.

 

007PRODUCT003ALL00833333333007PRODUCT0082013010100820201230000

 

AUTO - Starts up like the Service mode, says Production in the top right, couldn't tell the difference

 

004AUTO003ALL00833333333004AUTO0082013010100820201230000

 

DIRECT - Starts up like the Service mode, says Production in the top right, couldn't tell the difference

 

006DIRECT003ALL00833333333006DIRECT0082013010100820201230000

 

So here is the interesting part, with the XXTECHNICALXX mode you have the ability to change the usb port function from Host to Device (Change the USB OTG mode), as well as the ability to set a DEBUG over serial flag to on. I tried both these settings with a USB-A to USB-A cable I bought online, however my computer never detected the device when I swapped the usb port to OTG Device. However it is possible I have the wrong type of cable as its not an actual OTG cable. If anyone has a recommendation on a USB-A to USB-A OTG cable that would be awesome.

 

This mode also contains a lot more test functions that may provide more insight into the bluetooth issue, I will cross upgrade my deck tomorrow and renter the modes to see if the extra tests provide more insight.

 

 

post-116652-0-82682400-1437975004_thumb.jpg

 

post-116652-0-69920100-1437975035_thumb.jpg

 

post-116652-0-94409400-1437974978_thumb.jpg

Link to post
Share on other sites

...

 

So here is the interesting part, with the XXTECHNICALXX mode you have the ability to change the usb port function from Host to Device (Change the USB OTG mode), as well as the ability to set a DEBUG over serial flag to on. I tried both these settings with a USB-A to USB-A cable I bought online, however my computer never detected the device when I swapped the usb port to OTG Device. However it is possible I have the wrong type of cable as its not an actual OTG cable. If anyone has a recommendation on a USB-A to USB-A OTG cable that would be awesome.

 

...

 

Generally, in order to use USB-OTG, the pin #4 or X must be grounded for the USB hardware controller to understand that it is supposed to receive and supply power.

 

A standard USB port has just 4 pins while a device has 5 to designate charging/otg. You may need to locate hardware test points.

Link to post
Share on other sites

Great news. Using XXTECHNICALXX testmode you can do anything, including copy files and directories. testmode contains fully-functional file manager, you can even recursive copy full directories. Also, it is possible to run scripts and write whole partitions. There is copy-device mode to copy everything to sd/usb and so on.

 

@bass_rock Where did you get this information about XXTECHNICALXX? It is not in the public domain.

Awesome! Let's get a script with the outputs of dmesg, logcat, and id ported to a file on the SDCard.

 

Next we will want to install apps and execute them. We need a live terminal active on the device.

 

Good work guys! You've just busted through gaining access all the way through to maintaining access.

 

Stages of ethical hacking

1.Reconnaissance

2.Scanning & Enumeration

3.Gaining Access [Escalation of privileges]

4.Maintaining Access

5.Covering Tracks

 

Now we bounce around between 1-4 for a while until we are able to create a full update. But the important thing is that we have penetrated and have some level of access!

Link to post
Share on other sites

BTW.. I noticed yesterday, each partition appears to be signed. An Android boot.img starts with "ANDROID!". These images on the SD start with a header. Now we need to figure out how to sign an SD Image. The SD has a series of 00's instead of FF's. This is as far as I got yesterday in that area. I began looking for methods of executing files which you have found.

 

Now the single, final task is to figure out the partition headers on the SD.

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