Next post will elaborate on what exactly we need to unlock this damn bootloader.



So the 'standard' motorola procedure for unlocking the bootloader goes like this:

fastboot oem get_unlock_data
(bootloader) 3A45990705949553#54413436333034
(bootloader) 494E3300585431303435000000#A07E
etc...
we send this bigass string: 3A45990705949553#54413436333034... to moto via their website
and ideally (not for this phone/carrier model) get a string back, then
fastboot oem unlock STRING

unfortunately, us poor bastards with XT1045 and many other devices instead get an error notice from moto saying that we're screwed.

that's where sunshine comes in - somehow, those bastards are (presumably) generating this unlock key.

now, these question is: is that unlock_data all that's required to generate the unlock string? or is moto using other data from their own database to hash it?

like this stuff:
C:\Program Files\Minimal ADB and Fastboot>fastboot getvar all
(bootloader) version: 0.5
(bootloader) version-bootloader: 4113
(bootloader) product: peregrine
(bootloader) secure: yes
(bootloader) hwrev: 0x82D0
(bootloader) radio: 0x1
(bootloader) emmc: 8GB Toshiba REV=06 PRV=51 TYPE=17
(bootloader) ram: 1024MB Elpida S4 SDRAM DIE=4Gb
(bootloader) cpu: MSM8926
(bootloader) serialno: 
(bootloader) cid: 0x0010
(bootloader) channelid: 0x84
(bootloader) uid: 
(bootloader) unlocked: no
(bootloader) iswarrantyvoid: no
(bootloader) mot_sst: 0
(bootloader) max-download-size: 536870912
(bootloader) reason: Volume down key pressed
(bootloader) imei:
(bootloader) meid:
(bootloader) date:
(bootloader) sku:
(bootloader) iccid:
(bootloader) cust_md5:
(bootloader) max-sparse-size: 268435456
(bootloader) current-time: "Mon Aug 24  8:54:16 UTC 2015"
(bootloader) ro.build.fingerprint[0]: 

motorola/peregrine_cricket/peregri
(bootloader) ro.build.fingerprint[1]: ne:4.4.4/KXB21.14-

L1.45/15:user/re
(bootloader) ro.build.fingerprint[2]: lease-keys
(bootloader) ro.build.version.full[0]: 

Blur_Version.21.1.45.peregrine_cr
(bootloader) ro.build.version.full[1]: icket.cricket.en.US
(bootloader) ro.build.version.qcom[0]: 

AU_LINUX_ANDROID_LNX.LA.3.5.1_RB1
(bootloader) ro.build.version.qcom[1]: .04.04.02.048.020
(bootloader) version-baseband:
(bootloader) kernel.version[0]: Linux version 3.4.42-

(hudsoncm@
(bootloader) kernel.version[1]: ilclbld30) (gcc version 4.7 

(GCC) ) #1 S
(bootloader) kernel.version[2]: MP PREEMPT Sun Jun 29 17:26:32 

CDT 2014
(bootloader) sdi.git: git=MBM-NG-V41.13-0-
(bootloader) sbl1.git: git=MBM-NG-V41.13-0-
(bootloader) rpm.git: git=MBM-NG-V41.13-0-
(bootloader) tz.git: git=MBM-NG-V41.13-0-
(bootloader) aboot.git: git=MBM-NG-V41.13-0-
(bootloader) qe: qe 0/0
(bootloader) ro.carrier: att
all: listed above
finished. total time: 0.331s


How do we find out? Well we sandbox sunshine, of course, because hopefully their using the same parameters to perform their unlocking.

So let's look at my setup here:


XT1045, locked up tight
SM-T230, fully rooted test device
Emulators TBD


Using 2x versions of sunshine.apk for testing currently.

 So immediately, I have a couple of ideas on how to RE this puppy. The conventional (and perhaps, hopefully, overly difficult) method is illustrated, in part above.




1. The hard way

     - I popped open Wireshark,
     - started a SOCKS proxy on my computer,
     - changed network connection on XT1045 to forward through local IP:port of comp via proxy
     - ran sunshine on the device and collected the network data it used

Unfortunately(?), sunshine reported that I was using an outdated version and directed me to update.

Buuut... Now I've got a TCP stream contained within a pcap file on my computer, which hypothetically contains data hashed via the private key within sunshine.apk.

The next step here is to strip the SSL from the TCP stream and then disassemble sunshine with IDAPRO6 to start finding the hash, then use that to decrypt the app stream and figure out exactly what it's sending up to the server (theroot.ninja, in fact).

>I almost posted my TCP stream here but thought better of it, considering I don't yet know what it contains...

However, I've never disassembled an APK like that and it occurred to me there may be a far easier way to do this, courtesy of the environment within which theroot.ninja has been forced to code.




2. The smart way(?)

Here's my current plan:

Run sunshine.apk inside of an emulator/sandbox, determine what exactly it's pulling from the XT1045 data-wise, figure out what it's receiving, and determine what all it's using for license verification (and if we're lucky enough to only be dealing with Google Play LVL).

However, there are a BUTTLOAD of potential pitfalls here if the devs coded against this, which is very easy to do. They could presumably brick my device after all my tests indicate that my cr*ck has succeeded completely. But hell, let's try it.



Next post will elaborate on what exactly we need to unlock this damn bootloader.

Well I've decided on a project - hopefully no one is reading this, but I should be alright considering I'm just posting without promoting this blog, right? (FLW)

3. RE sunshine.apk - the bootloader unlocker tool for Moto G/X.
- Very difficult without a rooted test device.
- Set up rooted tablet to 'emulate' Moto X and read actual results
   - What device info is sunshine actually reading/using?
- Remove license verification and resign apk to run on moto x
   - Will signing be an issue?

http://forum.xda-developers.com/showthread.php?t=2050393
http://linux.die.net/man/1/gdbserver
http://www.hexblog.com/?p=809
http://forum.xda-developers.com/showthread.php?t=640592
http://ibotpeaches.github.io/Apktool/documentation/


Anways, I've never done a "hard" apk crack before so success is hardly guaranteed here.. And I'll be doing this sort of tutorial-style to help track my own work, and in case anyone else perhaps wants to learn something.

Keep in mind that the ultimate goal of this project is to actually RE this program in order to create a redistrib. solution to unlocking the bootloader on the moto x/g. But if that doesn't happen. please don't ask for my source/binaries from this tut... At least do that yourself.

I'm using this post to catalog a few project ideas that I've been procrastinating for far too long. But now that I'm set to be stupidly busy indefinitely, why not start one?


1. Live display feed over [usb?] to microSD for playback on non-networked display device.

Easiest method I've guessed up:
- Run VNC server using rfbproxy or vncrec to write live display to video file
- Will need to scale output video dimensions via either server, rfbproxy/vncrec, or through Handbrake/similar in order to ensure decoding can be done quickly enough and to correct file format
- Hardware part: a microSD[?] will need to be mounted concurrently on both the host and the client, with the client reading the video file while the host writes it... This may be nearly impossible.

* look into how VLC procedurally plays a video still being downloaded
* client may require SD mounted RO
* may need to let host initialize SD, put a 'dummy' card in that won't be handling any RW anyways then let the client initialize then force concurrent mounting

- This may be easier with a thumb drive simply wired up to an OPEN'ed mSD.
- What about trying to use WiDi as a video source?

http://rfbproxy.sourceforge.net/manpage.html
http://ronja.twibright.com/utils/vncrec/
http://www.fourwalledcubicle.com/LUFA.php



2. What can I convince to run a mostly-compliant JVM?
 - Start high-level and code a JVM in C# [java? lol] to run on Windows then move to something else - ideally eventually to an MC or FPGA.

https://en.wikipedia.org/wiki/Java_virtual_machine
http://www.fourwalledcubicle.com/LUFA.php


3. RE sunshine.apk - the bootloader unlocker tool for Moto G/X.
- Very difficult without a rooted test device.
- Set up rooted tablet to 'emulate' Moto X and read actual results
   - What device info is sunshine actually reading/using?
- Remove license verification and resign apk to run on moto x
   - Will signing be an issue?

http://forum.xda-developers.com/showthread.php?t=2050393
http://linux.die.net/man/1/gdbserver
http://www.hexblog.com/?p=809
http://forum.xda-developers.com/showthread.php?t=640592
http://ibotpeaches.github.io/Apktool/documentation/



4. Back to the Wintel
- What drivers are missing/required to get sound[?] and BT running under Android?
- What would be required to OC this thing under Windows?
- Driver support under Ubuntu?
- What sort of hw mods could be done - RAM, PCIe?



5. ReactOS is awesome! What can I do with it?
- CR-infringing Win/React hybrid, enabling unlocked everything and DX12+ support as well, running natively?
- Cross with JVM project?



6. BTC/altcoins?
- JVM/React dedicated miner? Are those even cool any more?



7. Any Android games worth RE or botting?

Reinstalling Windows/Android/Ubuntu on the Wintel CX-W8

Well I recently acquired a Wintel CX-W8 Windows/Android TV box 

(mine had a lovely unlicensed Windows 8.1 with Bing on arrival, as the only OS) 

and quickly proceeded to corrupt my Windows installation beyond all repair... Oh well, native Android support anyways, right? Or not...

Hours upon hours of hunting later, I've finally learned enough about this PITA SOC to potentially save someone else a good amount of time, so why not?



1. Reinstalling Windows

The CX-W8 has two options for booting: EFI and GFY ('go fuck yourself'). Originally, I tried an install of Windows 7 x64 and probably could have gotten it to work... However I hadn't yet figured out item #4 below so ended up with Win8.1x32 again, though the 32bit OS is probably better given my unit only contains 2gB of RAM.

Anyways, I'll include some links here if you wish to do a bit more with this, however my recommendation (and the first step in multi-booting this son of a bitch regardless) is to pick up an ISO of Windows 8.1 x32, the USB ISO-boot app Rufus, and a flash drive.

You'll need DRIVERS (WITH RTL8723BS) (NOT WITH AP6330) of course:
https://drive.google.com/file/d/0B_J0hmST3aYmdGxVVEtDWk56RmM/view?usp=sharing

Here's the quick:
1. Rufus the ISO to a flash drive - GPT for UEFI/FAT32 (you can find guides for EFI setup with Windows 8 easily)
2. Esc into bios on boot to enable USB booting (DISABLE THIS AFTER INSTALLATION)
3. Finish install and use these drivers, ripped from my own fresh install:


The F*** is wrong still? <--- Disable USB Boot in Bios
For some reason the device manager was throwing strange error codes on several devices and refusing the install drivers on others. Per a side-comment in a thread somewhere, I decided to disable USB booting in the bios and everything worked again, magically.https://plus.google.com/communities/117853703024346186936

Final Note: Power Management
I was having issues with the box going to sleep and either not coming back at all or seeming to lose USB drivers upon wake. The solution to this one was going through every item in device manager and, if there was a Power Management tab under its properties, unchecking 'Allow Windows to turn off this device to save power.'

Here's the util I used to backup all those drivers:
http://sourceforge.net/projects/drvback/

2. Where'd those drivers come from?

I found two devices that operate with the same SOC as this Wintel - the Linx 7 and the Transformer T100. Apparently the WLAN and BT hardware varies, however (either RTL8723BS/AP6330). From there, it was trial & error and alot of google. Mine uses RTL8723BS BTW


3. Installing Android

Here's a fairly new build of Android x86 for the T100, also great for the Wintel
https://groups.google.com/forum/#!msg/android-x86/FUiFCtrgc6I/UAoQ-if9dZMJ

And here is a kickass prebuilt USB containing Ubuntu and Android for the T100 with several fixes already applied (be sure to search the group for any new version):
https://groups.google.com/d/topic/android-x86/DFBxPGlpn_M

Want to tri-boot this thing (add Ubuntu+Android)? Read here:
http://reboot.pro/topic/20334-tri-booting-on-meegopad-t01/


4. Where's Ubuntu?

Either get it from here:
https://plus.google.com/communities/117853703024346186936

Or check out the previous link to the T100 Magic Stick which includes a build already


5. A tip for graphics performance

In the bios there's an option to set the amount of RAM reserved by the system for the integrated video card... I set mine to the max (512mB) and have squeezed a small amount of gaming performance out of this system. I also went through and disabled the power management settings that would decrease performance.


6. Hope for the future? Thoughts on upgrading the SOC

The bios says that only one SODIMM slot is in use, however inside the device there's no obvious way to utilize the other slot. That said, if anyone manages to do so please let me know via comments. There's a teardown of CX-W8 on another blog, showing several unused pin sets that we should totally figure out what to do with.

My only other idea is adding a battery and a small HDMI board/LCD display like many do with the Raspberry Pi. I'd assume we'd just need to borrow the bios settings from a T100 in order to manage the battery.