code integrity / signing policy toggle - Windows RT Development and Hacking

All,
First, let me say that this is not a jailbreak tool for RT 8.1! All clear? Good.
I've written a simple little driver and exe tool to patch the g_CiOptions and SeILSigningPolicy variables in ci and ntos. The obvious kicker is that you need the driver loaded for this to work -- but once loaded you can effectively use this to turn on/off the signing at will (eg: useful to avoid -- not disable -- patch guard).
I've tested this on my Surface RT as well as Windows 8 without issue.
You can find the code and binaries on github ( https://github.com/bfosterjr/ci_mod ). There isn't a whole lot of documentation (nearly zero), but you'll find batch files, windbg scripts, and various other bits which should help you figure out how it works (or you can just read the code).
Now, before you all flame me about how useless this is without a jailbreak or kernel execution for RT 8.1, let me say this: I've spent the last few days catching up on a lot of threads (over a years worth) in this form and there is enough information (if you look hard enough, open your mind, and tilt your head) in the threads to successfully start your own driver on 8.1 RT.
Cheers!

Any hint please?

Note that I would not recommend leaving this hack enabled on 8.1 once whatever programs are loaded. This will set off PatchGuard and the system will bluescreen. Enable it, run whatever, then disable it. Most programs should be OK once fully started to leave running with the hack disabled. Only loading unsigned DLLs from that point on would mess up.
8.0, do whatever; doesn't matter.
Melissa

Myriachan said:
Note that I would not recommend leaving this hack enabled on 8.1 once whatever programs are loaded. This will set off PatchGuard and the system will bluescreen. Enable it, run whatever, then disable it. Most programs should be OK once fully started to leave running with the hack disabled. Only loading unsigned DLLs from that point on would mess up.
8.0, do whatever; doesn't matter.
Melissa
Click to expand...
Click to collapse
Quite right - which is why the ci_mod program I wrote will run indefinitely waiting for user input to toggle on, or off, the kernel patching. So.. (1) Load the driver which will immediately toggle patching ON... (2) start ci_mod.exe and toggle patching back OFF ... (3) leave ci_mod.exe running. Doing so you will always re-toggle patching on (then off again) so you can run your unsigned app with minimal likelihood of PatchGuard being a problem.
Hopefully that makes sense.
Obviously, if anyone wants to make changes to the driver or program -- perhaps to alter it to suit initial driver execution conditions -- they're welcome too -- the code is GPL.
Cheers!

LolitaPlus said:
Any hint please?
Click to expand...
Click to collapse
Sorry no. There are serious reasons why I can't explain further. So please don't ask.
But trust me.. the bits you need are there... you just need to stitch them together.

bfosterjr said:
Sorry no. There are serious reasons why I can't explain further. So please don't ask.
But trust me.. the bits you need are there... you just need to stitch them together.
Click to expand...
Click to collapse
Hai, I'm kinda new to this whole hacking scene especially to the x86/x64 bit one (has been working on arm for a little while) and I was wondering what knowledge was necessary to be able to glue everything together? Which glue I need to use so to say
Thanks.

filfat said:
Hai, I'm kinda new to this whole hacking scene especially to the x86/x64 bit one (has been working on arm for a little while) and I was wondering what knowledge was necessary to be able to glue everything together? Which glue I need to use so to say
Thanks.
Click to expand...
Click to collapse
Years of Windows internals/development/debugging makes for good glue. That and the general desire (and patience) to want to mess with software....

bfosterjr said:
...
You can find the code and binaries on github ( https://github.com/bfosterjr/ci_mod ). ...
Click to expand...
Click to collapse
Hey mate, this looks very nice and far more user(noob)-friendly. Thank you soo much for sharing. :good:
Cheers
Blade
P.S.:
1) Is your deleted sign.bat a kind of launcher which : toggle -> start app -> toggle ?
2) Is it possible to share the compiled version? [Don't want to bother you] (Just formated my dev-pc and set it up to compile Android 4.4.4 for my desire Z. I know i need a new pc with a bigger hdd) :crying:

BIade said:
Hey mate, this looks very nice and far more user(noob)-friendly. Thank you soo much for sharing. :good:
Cheers
Blade
P.S.:
1) Is your deleted sign.bat a kind of launcher which : toggle -> start app -> toggle ?
2) Is it possible to share the compiled version? [Don't want to bother you] (Just formated my dev-pc and set it up to compile Android 4.4.4 for my desire Z. I know i need a new pc with a bigger hdd) :crying:
Click to expand...
Click to collapse
Hey Blade!
1) nope. that was a batch file to test sign the driver. its not required. the toggling of the patching is done by the user through cimod.exe (runs in a continuous user-input loop)
2) binaries for all supported platforms are there already -- https://github.com/bfosterjr/ci_mod/tree/master/bin
Cheers!

It would be really cool to hook the CreateProcess and LoadLibrary calls such that, if the target binary is unsigned and the caller isn't in an appcontainer, the policy is (automatically) flipped juuuust long enough for the call to succeed, and then (automatically) flipped back. That means minimal risk of a BSOD and maximum user-friendliness.
I proposed this approach months ago on the JB discussion thread, but never got around to writing it. Now bfosterjr has written the driver part (probably by far the hardest part) in a few days! We missed you...

GoodDayToDie said:
It would be really cool to hook the CreateProcess and LoadLibrary calls such that, if the target binary is unsigned and the caller isn't in an appcontainer, the policy is (automatically) flipped juuuust long enough for the call to succeed, and then (automatically) flipped back. That means minimal risk of a BSOD and maximum user-friendliness.
I proposed this approach months ago on the JB discussion thread, but never got around to writing it. Now bfosterjr has written the driver part (probably by far the hardest part) in a few days! We missed you...
Click to expand...
Click to collapse
Thanks man. Really wasn't all that difficult. The driver isn't quite as flexible (or perfect) as it could be. To accomplish what you're suggesting might take some effort because, IIRC, the normal process create callbacks don't get triggered until after process image verification. I'll have to double check that.
I might take a stab at updating the driver to make it more automated. Once I have a bough free time. Stay tuned
Cheers!

bfosterjr said:
Thanks man. Really wasn't all that difficult. The driver isn't quite as flexible (or perfect) as it could be. To accomplish what you're suggesting might take some effort because, IIRC, the normal process create callbacks don't get triggered until after process image verification. I'll have to double check that.
I might take a stab at updating the driver to make it more automated. Once I have a bough free time. Stay tuned
Cheers!
Click to expand...
Click to collapse
What GoodDayToDie suggested is not using PsSetCreateProcessNotifyRoutineEx but hooking Ring3 API. I can offer some help if you need ARM Ring3 inline hook. I already wrote a hook engine though it is more like a POC.

LolitaPlus said:
What GoodDayToDie suggested is not using PsSetCreateProcessNotifyRoutineEx but hooking Ring3 API. I can offer some help if you need ARM Ring3 inline hook. I already wrote a hook engine though it is more like a POC.
Click to expand...
Click to collapse
Yeah, I got that.. but I'm just not a fan of hooking the be-jesus outta usermode to solve this problem. I don't' like hooking in general.. as it tends to just lead to more problems and complications. I'd rather try to find a more clever way to solve this problem with callbacks or some other OS supported mechanism.
Cheers!

Yeah... another option would be hooking NtCreateProcess (ring 0) either in the actual entry point or at the syscall table, but I can't imagine you're *more* enthusiastic about hooking kernel-mode than user-mode, and messing with the syscall table could make PatchGuard angry too. With that said, the user-mode hook would be pretty easy, actually; once the tool is running, it uses the process instrumentation/shimming stuff in Windows (ImageFileExecutionOptions key?) to have every EXE load a (homebrew) DLL at startup. The DLL installs the requisite hooks (and probably then unloads itself). You'd need to inject that DLL into already-running processes, but that's not hard.
Windows automation isn't my strong point, but I know the x86 emulation layer is able to detect when somebody tries to run an x86 EXE and intercept the attempt *before* the process launch fails. Is this usable here (i.e. does whatever that listens on trigger before the signature check)? If not, a hook may be the only workable approach, hacky though it is.

bfosterjr said:
there is enough information (if you look hard enough, open your mind, and tilt your head) in the threads to successfully start your own driver on 8.1 RT.
Cheers!
Click to expand...
Click to collapse
Well I've been looking, and contributing, for a long time, but still cant quite crack it ...

Can't quite understand
I have read through your source code. I don't quite understand the point though. Is this app and driver to allow unsigned exe to run? Is the batch file required? From what I can see all that is required is netham45's Jailbreak and this to run unsigned exe. I would like to share my finding's in an instruction post but thought I would ask your permission first. May I?
Thanks,
Wcomhelp

The purpose of this is to make it "safer" to jailbreak 8.1, since if you change the code integrity flag in 8.1 and leave it changed for any length of time, the system will crash due to PatchGuard. This driver is so you can only change the code integrity settings when you need to load unsigned code, giving minimal time for PatchGuard to notice and minimizing the risk of a crash.
HOWEVER, you cannot load this driver unless you already have unsigned code execution through some other means. That other means has not yet been published; if you want to use this tool you will need to figure out how to install it yourself (or wait for a published hack).

EDIT:
Wouldn't CVE-2014-4148 / CVE-2014-4113 (MS14-058) be sufficient to initially load this tool?
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4113
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4148
technet.microsoft.com/library/security/MS14-058

Yeeeeesssssss... yes it probably would!
Of course, you'd need to avoid installing the patch for it - not really a "proper" jailbreak, in that sense - but yeah, that should work. All you need to do is toggle code signing off for a second to load the driver, and code execution in Win32k.sys should manage that.
Oh, win32k, how we love you... so many vulnerabilities in just one little kernel-mode component!

GoodDayToDie said:
The purpose of this is to make it "safer" to jailbreak 8.1, since if you change the code integrity flag in 8.1 and leave it changed for any length of time, the system will crash due to PatchGuard. This driver is so you can only change the code integrity settings when you need to load unsigned code, giving minimal time for PatchGuard to notice and minimizing the risk of a crash.
HOWEVER, you cannot load this driver unless you already have unsigned code execution through some other means. That other means has not yet been published; if you want to use this tool you will need to figure out how to install it yourself (or wait for a published hack).
Click to expand...
Click to collapse
Does this work?
http://msdn.microsoft.com/en-us/library/ff547565.aspx

Related

[ROM] AOSP w/o Google apps (readd-able) FIRST HALFLEGAL ROM

Here I provide a half legal (I included the HTC drivers for the hardware...) stock AOSP (android-1.5_r3) ROM!
You can add Google Apps legally if you have bought a Google experienced phone by running this script on a linux-machine:
http://forum.xda-developers.com/showthread.php?t=564744
Features:
-No special features
-Just stock w/o Google apps
Download for G1:
http://www.4shared.com/file/135524283/e812c64f/dream.html
Instructions:
Unzip the file, then:
fastboot erase userdata
fastboot flash system system.img
fastboot flash boot boot.img
fastboot reboot
To Do:
I'm a lazy guy.
Next release will be cyanogenmod w/o googleapps.
Well does the rom working without all googles stuffs ?
Can we add them easily ?
Thanks for the new build, hope this googles' issue will be fine
It does work, but it's nearly useless.
I work on a windows version of my script which adds google apps legally.
I also will create a script for recovery.
I'll work on this ROM when I'm done with these, as soon as the scripts are ready, this ROM will get some goodies from Cyan.
Nice work Maxisma!
Its a good start
awesome bro
keep it up it's a start!
maxisma said:
It does work, but it's nearly useless.
I work on a windows version of my script which adds google apps legally.
I also will create a script for recovery.
I'll work on this ROM when I'm done with these, as soon as the scripts are ready, this ROM will get some goodies from Cyan.
Click to expand...
Click to collapse
Excellent.
With all this doom and gloom.
Surely this is the problem solved?
But what do you mean by google experience?
I know I got all the apps with my phone... T-Mobile G1...
Google Experience are all phones with Google Apps preinstalled.
Just some indian and russian HTC devices don't have it.
Out of interest would this boot fine without running the script?
I am presuming not, but i am just curious?
I would try it out, but at the moment I am not at home and only have 2g coverage on my phone so its a bit slow to download
Edit //
Could i (in theroy) install, boot and then use wget to download sam3 from slideme.org and then download a third party dialer / K9 etc... etc..
So use all third party apps
vixsandlee said:
Out of interest would this boot fine without running the script?
I am presuming not, but i am just curious?
I would try it out, but at the moment I am not at home and only have 2g coverage on my phone so its a bit slow to download
Click to expand...
Click to collapse
It boot's fine w/o the script ;-)
Not to rain on your parade, but ....
Hi Maxisma,
Not to rain on the parade, but ...
Per Google, this ROM is no more "legal" than any other ...
The following is taken from http://source.android.com/documentation/building-for-dream
* The Dream device software contains some proprietary binaries. For contractual reasons, these cannot be redistributed separately from the shipping hardware, but the provided script may be used to extract these binaries from your development device so that they can be correctly included in your build. These libraries include the openGL|ES library, the Qualcomm camera library, the HTC Radio Interface Library, etc. You need adb to be in your path, and you need your device to be configured for adb access. If you don't have adb already, do a generic build first, which will put it in your path.
Click to expand...
Click to collapse
Just my understanding of things.
~enom~
Interesting, i am going to have to have a look and a play later.
Cheers for the work (forgot to say that in my first post)
if you're interested on maybe trying to do this on your own:
http://www.johandekoning.nl/index.php/2009/06/07/building-android-15-build-environment/
Contrary to what you might think, a room w/o google apps is not entirely useless. Probably the major setbacks are the lack of market access, the lack of a YouTube player (we need to work on a port of Totem's Youtube implementation but for android), and a way to manage contacts (irrenhaus is looking at the posibility of setting up a Google Contacts sync), plus we'd probably need to write an utility to actually read/write contacts to and from SIM.
G-mail, you can acess from the browser (which, AFAIK, is still free and open source under the Apache Licence), Maps can be downloaded once we get Market access.
Other than that, a bone-stock android build will keep you connected to the internet, allow you to tether, allow you to run scripts, deliver your mms, give you camera and music player, have theme support, and ofcourse, make phone calls just like any other build will. You'll just have to go a bit off of your way to get apps, but again, that's the main drive here, either get acess to market of create a new one and invite app developers to submit their apps there too
enomther said:
Hi Maxisma,
Not to rain on the parade, but ...
Per Google, this ROM is no more "legal" than any other ...
The following is taken from http://source.android.com/documentation/building-for-dream
Just my understanding of things.
~enom~
Click to expand...
Click to collapse
That's dead on too, and I forgot about it. The issue would not be with google anymore though, but with HTC and it's hardware partners. This is what cyanogen realized, now that the spotlight is on rom development, companies will have watchdogs for re-distribution of binary code. If you own an ADP device, you can legally download the binaries from the HTC website and MAKE YOUR OWN BUILD (so redistribution targeting dream is out, unless we can talk to HTC about it), either that, or, as I've said before, move onto an open hardware platform so we can write our own drivers.
---edit---
By the way, I still don't agree with the whole feeling of gloom floating around here. This is only a change to the way we're doing things right now, but it doesn't hinder development in any way. If you're the kind of dev that's here for the praise, then yeah, you wont like it that now people will have to actually know what they're doing, so your fanbase will be reduced. I for one welcome the change. This rom, for example, can still be distributed without the HTC binaries and maybe have instructions for the user to download them, install them in their OTA package, and the actually flash the rom. But then that requires that people actually know what they're doing, since we can't legally provide them the finished product.
Also, it doesn't hinder improvement of the platform. None, I repeat, NONE of cyanogen's or other dev's work ever even touched the proprietary parts of the build, as this is nearly impossible without the source (I know, baksmali, but really, I'm trying to make a point here!...) and most of what made his work awesome was the behind-the-userland work; kernel's bfs patches, scripting, cpu time management, modifications to available source, for example, the settings package.
We can still improve the platform, we can contribute, and maybe this time around the way Google wanted people to, by submitting code for their consideration to have it maybe implemented in android's next build.
I'll be glad to see all the "OMG, MY PHONE WONT START" threads diminish as people realize that this will no longer be the place where you get it all dumbed down and easy to use.
hey just by simple curiosity, how do you then log into the phone, if this rom is google less? I presume you still need a google account to set up your machine right????
kmassada said:
hey just by simple curiosity, how do you then log into the phone, if this rom is google less? I presume you still need a google account to set up your machine right????
Click to expand...
Click to collapse
You don't need to login as there is no setupwizard.
jubeh said:
That's dead on too, and I forgot about it. The issue would not be with google anymore though, but with HTC and it's hardware partners. This is what cyanogen realized, now that the spotlight is on rom development, companies will have watchdogs for re-distribution of binary code. If you own an ADP device, you can legally download the binaries from the HTC website and MAKE YOUR OWN BUILD (so redistribution targeting dream is out, unless we can talk to HTC about it), either that, or, as I've said before, move onto an open hardware platform so we can write our own drivers.
---edit---
By the way, I still don't agree with the whole feeling of gloom floating around here. This is only a change to the way we're doing things right now, but it doesn't hinder development in any way. If you're the kind of dev that's here for the praise, then yeah, you wont like it that now people will have to actually know what they're doing, so your fanbase will be reduced. I for one welcome the change. This rom, for example, can still be distributed without the HTC binaries and maybe have instructions for the user to download them, install them in their OTA package, and the actually flash the rom. But then that requires that people actually know what they're doing, since we can't legally provide them the finished product.
Also, it doesn't hinder improvement of the platform. None, I repeat, NONE of cyanogen's or other dev's work ever even touched the proprietary parts of the build, as this is nearly impossible without the source (I know, baksmali, but really, I'm trying to make a point here!...) and most of what made his work awesome was the behind-the-userland work; kernel's bfs patches, scripting, cpu time management, modifications to available source, for example, the settings package.
We can still improve the platform, we can contribute, and maybe this time around the way Google wanted people to, by submitting code for their consideration to have it maybe implemented in android's next build.
I'll be glad to see all the "OMG, MY PHONE WONT START" threads diminish as people realize that this will no longer be the place where you get it all dumbed down and easy to use.
Click to expand...
Click to collapse
I could probably write a Java application that would allow the user to:
1) hook their google phone up over USB and grab the existing google apps off of it
2) point to the location of their proprietary drivers on a manufacturers website for download
3) point to a central location of legal ROMS for download
4) click an ASSEMBLE button to put it all together. The resulting update file would be like they have always been, but no illegal redistribution has taken place.
One little problem ...
Ohsaka said:
I could probably write a Java application that would allow the user to:
1) hook their google phone up over USB and grab the existing google apps off of it
2) point to the location of their proprietary drivers on a manufacturers website for download
3) point to a central location of legal ROMS for download
4) click an ASSEMBLE button to put it all together. The resulting update file would be like they have always been, but no illegal redistribution has taken place.
Click to expand...
Click to collapse
Hi Ohsaka,
One little problem with that is ... the manufacturers do not post the drivers (standalone) on their websites for download, they only redist with the hardware. Also, there are other library files as well, it's not only drivers.
~enom~
Simple fix.. just don't include it. People will have to "magically" find the drivers on their own.
If it boots, why is it nearly useless?

Mer linux for kaiser.

EDIT:
Magister2k7 said:
Please update first post of a thread, as Mer should run X with a latest kernel from git.
You just need to disable FB_MSM_DOUBLE_BUFFER ("Enable MSM Framebuffer double buffering") and enable framebuffer refresh thread.
Click to expand...
Click to collapse
Yeah, I kinda doomed myself from the start with how I structured this post. I'll restructure it later to be more able to show you good information.
Old start:
Mer is a more community-led version of the Maemo phone and internet tablet operating system. See http://wiki.maemo.org/Mer/ .
I was in contact with a member of that project (Stskeeps on freenode#mer), who gave me some information about porting this to phones such as the kaiser. He and I thought it would be a great way to benefit both communities (we get a good, not google-owned linux-based os for our phones, they get developers helping them make mer better). We also agreed that it would take a bit of effort.
First of all, Mer is completely designed for landscape-only, 800x480 phones at this point. It has been run well at 640x480, but that's still 4 times our native resolution, and 2 times what we can fake without crashes. The resolution problem is easily fixed by skilled theme-makers. The landscape/portrait problem should be fixed soon, given that the upcoming n900 will be a portrait/landscape phone. He said wait for the maemo conference for more on that.
The other problems we might hit basically are just the standard problems of molding the userspace around the kernel (get a phone app working, get the modem to work, etc.).
If you are serious about helping, please come to #mer and/or #htc-linux on freenode. At this point, the mer folks are probably more help to what we need to do.
INSTRUCTIONS:
At this point, quite literally nothing works, but it all almost works. Here's what I did to get that far:
1. Partition your sd card into two partitions, and make the second one ext2.
2. Unpack (with the -p option of tar) the rootfs (http://wiki.maemo.org/Mer/Releases/0.16testing , pick the q5 rootfs) to the ext2 partition. Make sure that it's not in any subfolders, but as the root of the drive.
3. Grab a zImage (or build your own) using the instructions we had in place from android. Put it on the fat side.
4. Set up HaRET on the fat side - Use a default.txt from android, get rid of the initrd, get rid of your ppp stuff (for now), and add "root=/dev/mmcblk0p2 rootwait" to the kernel cmdline.
5. mknod /dev/fb0 c 29 0 (this was my number, check using the terminal in android, cat /proc/devices for the major, and /proc/fb for the minor). Also make sure that it's within the root, not on your disk .
That should boot, giving you a ton of messages about an "incorrect resolution png" or something - that's the splash screen unable to load. Simply rename /lib/init/splash-* (two files) to something else. Once you get a terminal later, there's an actual package to remove, but this lets it go a bit further.
You also need to keep X from starting at this point - all it does is hang. I have not yet done this myself, but it should be an initscript that you just un-link.
EDIT: It wasn't X that caused the issues. It was the combination of failed splashes and consolefont. Comment out the lines with "splash" in them in /etc/init.d/check{fs,root}.sh, and re-run.
I do not know if X actually fails - doing that test now.
EDIT: hitting framebuffer issues... no X yet.
So, if you're adventurous, and preferably a dev at this point (this is completely useless to users), please try this out and make it better!
Okay, just a note: the password is "rootme".
First reply!
this is relevant to my interests. I'll take a look. I remember seeing that Maemo was made on top of Gnome. Do you know if there's a chance to get Debian apps on here? That's the big thing for me to get me working on it-- some type of desktop compatibility. Having an X-server is perfect. Looks like you're saying the resolution issue is purely theme based? How open are the devs for it for suggestions and feedback?
2nd reply
This does sound cool
already made some read about this in the new nokia n900..
its cool.. it free.. but i dont like the ui :\
lets see where this goes.. but.. for now.. for me... android (L)
Ok, just saw it's Jaunty based which is what I've been looking for in a phone.
Is there a list of features/bugs/issues and what's been developed so far? Seems like if the kernel brought to us in part by dzo will work maybe it won't be so hard to get wifi and other features working. A list is good.
I'll admit I haven't put much effort into it, but at this point X won't work, for one thing - probably have to change the resolution in a config somewhere.
Indeed, most of the hardware should be fine - I imagine, for example, once we are able to load the firmware, wifi should be good. Some code will have to change (a few things are built android-specific in the kernel), and some of the RIL stuff especially (phone, data, etc.) will have to be ported by someone who has that code and some time.
Indeed, Mer is Ubuntu-based, and so, according to their site, 95% of ubuntu apps should work perfectly. This is really nice for getting software on (aren't just limited to any applications in an app store or market.).
At this point, all we need to do is everything .
I'm going to try now to disable X and see if I can't get a few more things working.
EDIT: in response to your question about how open the mer-folk are to suggestions? The idea that I got from talking to them was that they are more than happy to get this extra help, and since they are trying to bring this to more devices, they are willing to put up with our requirements, to make this more readily available in general.
Alright, as I edited, I got some more success.
By removing the splash calls and the X starting, I can get a terminal. I edited the /etc/shadow file to have a password that I knew for root. Now, I can log in as root on the console (/dev/tty1).
I tried to start X, and I'm getting some strange framebuffer errors.
I'll keep you posted.
Wow, if we could get this working, it'd be sick! Thanks for posting, formatting now.
with all the hard work already done for the Android port, seeing devs being interested in Mer is REALLY PROMISING! Waiting for Google to open up Android even more, is frustrating...
Porting Mer and thus having a REAL linux (kernel+software stack) is what we need to leverage the dev capacity of the great XDA community. At least, this is what I feel like .
Owning both a Kaiser and 2 N800s, I'll probably try out the stuff posted here... I was keeping an eye on Mer for my N800s anyway, but using it on the Kaiser is more triggering
so devs, have courage and good luck!
Frame Buffer and X server
Unfortunately I've been quite busy lately and haven't been following the Android development as closely as I would like. (I don't think I've updated my git repo for months)
If I remember correctly, the frame buffer code in the kernel wasn't finished. That would prevent X from running. Can anyone say whether that was completed? I just wanted to mention this in order to avoid people wasting their time if it is in fact the problem.
It would be great to *eventually* see X running with hardware acceleration, can anyone point me to info about how DZO got that working? Was it reverse engineered, or did he figure out how to make some binary blob happy?
It will be nice to have some choice of Linux based distros the Kaiser and Vogue. Keep up the good work everybody, I appreciate it!
-Mysteryvortex
I've been looking at the n900 for quite some time just waiting for its release to the US next month. I know nothing about developing but I am very excited about this one, and I hope that there is a quick start to the apps that are put out for it. I was curious myself as well at how this would port to the kaiser so I could get a good hands on before I went and bought one. I would be more than happy to be a tester. I bought an iphone cause cause the little green guy is really starting to piss me off and my tilt's about to give up the ghost. I quickly gave it to my wife as the signal strength and battery life just sucks so I hope this maemo can give me what I want
mysteryvortex, Android does not use an X server at all. This was my disappointment when issues arose trying to run Ubuntu in a chroot. This is different though. We should be looking at troubleshooting the X server as top priority I think. The rest should flow. Bear in mind the kernel for Android, like I said, has nothing to do with X compatibility since Android uses its own display so the kernel should need some serious work.
poly, is the build you linked to hardware specific? Looks like a generic one. If so, then the only outstanding difference should be the kernel and if that's the case we should be able to use this on any phone we happen to have a kernel for right?
enatefox said:
mysteryvortex, Android does not use an X server at all. This was my disappointment when issues arose trying to run Ubuntu in a chroot. This is different though. We should be looking at troubleshooting the X server as top priority I think. The rest should flow. Bear in mind the kernel for Android, like I said, has nothing to do with X compatibility since Android uses its own display so the kernel should need some serious work.
poly, is the build you linked to hardware specific? Looks like a generic one. If so, then the only outstanding difference should be the kernel and if that's the case we should be able to use this on any phone we happen to have a kernel for right?
Click to expand...
Click to collapse
The build has a kernel and stuff, but don't use it. Use the regular stuff from android (or build yourself from htc-vogue).
mdrobnak from irc got mer up on his raph - thanks to the vga screen, with a quick kernel patch and some xorg.conf modification, he got X working great.
Within the next few days, I'll do some tests of the data connection and such.
enatefox said:
mysteryvortex, Android does not use an X server at all. This was my disappointment when issues arose trying to run Ubuntu in a chroot. This is different though. We should be looking at troubleshooting the X server as top priority I think. The rest should flow. Bear in mind the kernel for Android, like I said, has nothing to do with X compatibility since Android uses its own display so the kernel should need some serious work.
Click to expand...
Click to collapse
Yes, that's correct. Android doesn't use X. Many, many months ago, it was mentioned that the framebuffer in the Vouge/Kaiser kernel (which X will use) was broken. Nobody was planning to fix it since Android doesn't need it. I was just trying to point people who have time to work on supporting our phones in the right direction.
poly_poly-man: Looks like the Raphael kernel is being developed on another branch, but it sounds like the FB patch helps us?
-Mysteryvortex
poly_poly-man,
I have setup my second partition of sdcard to 512MB and extracted there Mer preserving permissions.
What I did also is to modify the x config and change resolution and also resize the Mer-logo.jpg so it fits.
After I tried to boot I went successfully through all steps (at least I think so) and a blank screen appeared to me.
Can you tell me what was the parameter to output the Haret boot sequence to a file, so I can check what passes and what fails?
Another question: The following "mknod /dev/fb0 c 29" have to be performed on root of second permission, right? If so I think the command should be ""mknod ./dev/fb0 c 29", am I correct?
Regards,
Borkata
Borkata81 said:
Another question: The following "mknod /dev/fb0 c 29" have to be performed on root of second permission, right? If so I think the command should be ""mknod ./dev/fb0 c 29", am I correct?
Click to expand...
Click to collapse
'./dev/fb0 c 29' does only work if you are in "/" (root of the filesystem) otherwise (and in all other cases) 'mknod /dev/fb0 c 29' is correct.
bye...
Borkata81 said:
poly_poly-man,
I have setup my second partition of sdcard to 512MB and extracted there Mer preserving permissions.
What I did also is to modify the x config and change resolution and also resize the Mer-logo.jpg so it fits.
After I tried to boot I went successfully through all steps (at least I think so) and a blank screen appeared to me.
Can you tell me what was the parameter to output the Haret boot sequence to a file, so I can check what passes and what fails?
Another question: The following "mknod /dev/fb0 c 29" have to be performed on root of second permission, right? If so I think the command should be ""mknod ./dev/fb0 c 29", am I correct?
Regards,
Borkata
Click to expand...
Click to collapse
It seems that even set to the right resolution, our fb does not work with X. Needs more patching than just the patches I got from the other branch. We may need to move up to the other branch, I'm not sure.
the /dev/fb0 should be replaced with /path/to/sdcard/root/dev/fb0, of course. And it's better to just get rid of all the splash references - that way, you don't get the blank screen issue.
toasty_ said:
'./dev/fb0 c 29' does only work if you are in "/" (root of the filesystem) otherwise (and in all other cases) 'mknod /dev/fb0 c 29' is correct.
bye...
Click to expand...
Click to collapse
Yes, but poly has written that user have to be in root so that was what I have asked
Question: our fb driver is msm_fb?
poly can you share which patches you tried from raph branch?
Borkata81 said:
Yes, but poly has written that user have to be in root so that was what I have asked
Question: our fb driver is msm_fb?
poly can you share which patches you tried from raph branch?
Click to expand...
Click to collapse
Oh yes, you're right. I should first read the full post before answering questions that havn't been asked
Borkata81 said:
Yes, but poly has written that user have to be in root so that was what I have asked
Question: our fb driver is msm_fb?
poly can you share which patches you tried from raph branch?
Click to expand...
Click to collapse
http://people.openezx.org/tmzt/
the msmts and vres patch. Didn't work, because there are more problems in our older kernel.
I'm interested in finding out why we aren't on 2.6.27 already...

[Q] Permanent jailbreak for Windows RT

Hi for Guru and everyone!
Sorry for new topic creation. I had a wish to post my message in this thread - http://forum.xda-developers.com/showthread.php?t=2092158
but, as a beginner, which has less than 10 posts, I was transfered to Q&A. So...
I have Asus TF600T. Thanks a lot to Netham45, I jailbreaked my tablet and use some of ported applications, such as classic start menu & 7zip. But, its very tediously to jailbreak my tablet again'n'again after every reboot. And, as I understood, its possible to make JB permanent. But it still stay temporary becose of legality moments. So, I don't care about legality, and, also, all of as have possibility to recover our tablet to factory settings if anything crops up. So please, Netham45 or other Guru, I ask all of you - make us happy, we'll be very grateful )))
Still waiting for permanent Win RT jailbreak, your Denis_63 )))
Denis_63 said:
Hi for Guru and everyone!
@Denis_63,
I share your pain with the 'less than 10 posts' issue.
If you download Netham45's latest verion, I think that has an automatic startup feature, reastarting the batch file after reboot is not that bad really.
I'm looking for a way to execute the exploit from within the recovery environment, any suggestions would be appreciated!
Colin.
Click to expand...
Click to collapse
cramsden said:
Denis_63 said:
Hi for Guru and everyone!
@Denis_63,
I share your pain with the 'less than 10 posts' issue.
If you download Netham45's latest verion, I think that has an automatic startup feature, reastarting the batch file after reboot is not that bad really.
I'm looking for a way to execute the exploit from within the recovery environment, any suggestions would be appreciated!
Colin.
Click to expand...
Click to collapse
Yes, the new one solves this sort of. However it is still dependent on the same exploit, meaning you will still need some steps to actually activate it. I've since removed the jailbreak from automatic bootup again because it seems to mess with the windows store (cannot buy/download apps when the jailbreak is active).
A reasonably easy way to work around this is to make a shortcut to the jailbreak and pin that to the taskbar, then it's just a (almost) one-click affair.
Click to expand...
Click to collapse
1. Yes, the latests versions of JB can be automaticaly startuped, but you still need to do some uncomfortable steps (press volume "-", for example). So, I can call this variant as half-automatical (non-persistant, unfortunatelly). Also, it means, that JB is hanging in RAM, wich is also not good !
2. Didn't see any relation between JB and M$ store correct functioning.
Still don't understand Netham45 reluctance to make persistant JB (for those, who want to). May be some other Guru of xda are able to improve Netham45 JB ?

Rooting Sony's e-reader DPT-RP1 and DPT-CP1

Update (5/18/2019)
Since the first tool was released, HappyZ has improved many features so I think I can just refer to
* HappyZ's rooting guide: https://github.com/HappyZ/dpt-tools/wiki/The-Ultimate-Rooting-Guide
- The only thing I want to add as Windows user is (because the guide is for Mac/Linux users) it gets much easier if you use Linux terminal like cygwin, and the port name should be something like COM# where # can be found in Device Manager by comparing before/after you attach the device.
* HappyZ's upgrade guide: https://github.com/HappyZ/dpt-tools/wiki/The-Upgrade-Guide (Recommend to read this before/after you update the new firmware.)
You may donate a cup of coffee to him there Thanks to all others who contributed a lot.
--
Update (12/02/2018) -- These are outdated.
Finally we manage to root the device! Many thanks to all of your efforts.
Just refer to HappyZ's well written guide: https://github.com/HappyZ/dpt-tools
For whom have never used python like me (and probably using Windows):
(1) Install Python 3 and add it to PATH.
(2) Install MINGW64 and run scripts here instead of Powershell due to xxd issue if you are on Windows.
(2) pip httpsig pyserial on bash.
(3) Download HappyZ's dpt-tools and unzip.
(4* this issue is fixed by HappZ)
(5) Follow HappyZ's guide. You should execute dpt-tools.py in the folder you unzipped to use get-su-bin because of how the script is written.
Some suggestions after rooting (let me know if you have better ideas):
Here is my setup: install "E-ink Launcher" and "Multi action home button" using adb install.
Use adb shell am start -a android.intent.action.MAIN to change the main launcher to your launcher.
Then change the setting of Multi Action Home button (say, the height should be large to be visible in the bottom) and assign its function to be Home for click and Back for double-click.
Whenever you want to use Sony's apps (these are good for pdf markup), just push the home button to open the pop-up menu.
Otherwise, touch the Multi Action Home Button to access to other Android apps. So far I've never experience any crash.
Yet more tips:
Some complain fonts are too small after installing generic apps.
adb shell wm density 320 changes your DPI by 2 times (160 is a default value.) EDIT: I found 200 is quite enough that does not distort Sony apps too much.
My application is using "Tasker" to execute the above code when specific apps are open and execute wm density reset when the apps are closed.
The reason why we cannot change the global DPI is sadly because it makes the default apps by Sony so awkward.
Alternatively, I could successfully install Xposed to try App Settings but this app crashed.
You can also install Gboard (but it has no hide button, so prepare with virtual back button) if you need another keyboard.
Enjoy your DPT devices
--
Sony recently released a new digital paper device DPT-RP1, apparently using their own linux firmware but underlying on Android 5.1.1. Few weeks ago, some Chinese successfully hacked it to jailbreak for third-party apps (without changing the original firmware), but they don't share any information to sell those hacked devices. I'm willing to pay for it, but it is too risky to send my device to China so I'm trying to root it by myself.
I don't know much about this world, but I found some information that might be helpful. It uses Marvell A140 IoT Processor a.k.a. PXA1908. There are two Android smartphones (as the same version 5.1.1) with this chip - Samsung Xcover 3 and Samsung Galaxy Grand Prime. Fortunately, they have been both rooted in the past here.
Is this information really helpful to root my device? If so, is there any way to apply the previous methods to easily jailbreak DPT-RP1? I think the problem here is that it does not look like Android at all, so has no setting menu or developer tools. And not sure how to enter to the recovery mode since it only has two buttons - power/menu.
I'd appreciate any help or advice. Thanks!
And here you can find source codes.
oss.sony.net/Products/Linux/dp/DPT-RP1.html
sartrism said:
Sony recently released a new digital paper device DPT-RP1, apparently using their own linux firmware but underlying on Android 5.1.1. Few weeks ago, some Chinese successfully hacked it to jailbreak for third-party apps (without changing the original firmware), but they don't share any information to sell those hacked devices. I'm willing to pay for it, but it is too risky to send my device to China so I'm trying to root it by myself.
I don't know much about this world, but I found some information that might be helpful. It uses Marvell A140 IoT Processor a.k.a. PXA1908. There are two Android smartphones (as the same version 5.1.1) with this chip - Samsung Xcover 3 and Samsung Galaxy Grand Prime. Fortunately, they have been both rooted in the past here.
Is this information really helpful to root my device? If so, is there any way to apply the previous methods to easily jailbreak DPT-RP1? I think the problem here is that it does not look like Android at all, so has no setting menu or developer tools. And not sure how to enter to the recovery mode since it only has two buttons - power/menu.
I'd appreciate any help or advice. Thanks!
Click to expand...
Click to collapse
You must be an iPhone user that isn't familiar with android. Jailbreak in is an Apple thing, not an android thing.
In android it's called "rooting" and it isn't quite the same thing as jailbreaking an Apple device.
This device does not at all seem to be worth the price, especially considering the limitations it has. What a waste of hardware.
I would assume that you could port something from one of those other devices to work on yours but it really depends on how your hardware is designed compared to those devices.
Does your device have a typical bootloader like other android devices?
Is the bootloader unlocked?
If it is locked, can it be unlocked?
Does the device use fastboot or does it have a flash mode that is used with a specific PC flashtool?
If it is unlocked or if you can unlock it and it has a flash mode that can actually be used, you might be able to port a custom recovery from one of the devices you named then use that recovery to somehow root the device. If the device can't install android apps then it would probably involve using adb to root the device.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Droidriven said:
You must be an iPhone user that isn't familiar with android. Jailbreak in is an Apple thing, not an android thing.
In android it's called "rooting" and it isn't quite the same thing as jailbreaking an Apple device.
This device does not at all seem to be worth the price, especially considering the limitations it has. What a waste of hardware.
I would assume that you could port something from one of those other devices to work on yours but it really depends on how your hardware is designed compared to those devices.
Does your device have a typical bootloader like other android devices?
Is the bootloader unlocked?
If it is locked, can it be unlocked?
Does the device use fastboot or does it have a flash mode that is used with a specific PC flashtool?
If it is unlocked or if you can unlock it and it has a flash mode that can actually be used, you might be able to port a custom recovery from one of the devices you named then use that recovery to somehow root the device. If the device can't install android apps then it would probably involve using adb to root the device.
Click to expand...
Click to collapse
Thanks for suggesting a general principle! I just use the word jailbreaking not because I'm an iPhone user. What I actually want to do as the first step is not rooting an android system, but revealing it from the current customized linux system. Rooting is the next step if necessary. If the word choice is still not accurate and bothers you, I apologize.
It has apparently no typical bootloader, and neither PC nor adb recognize it as an android device. In fact, direct USB file transfer is blocked so I need to use Sony's designated software. But an android system surely coexists according to the hacker who already rooted it.
sartrism said:
Thanks for suggesting a general principle! I just use the word jailbreaking not because I'm an iPhone user. What I actually want to do as the first step is not rooting an android system, but revealing it from the current customized linux system. Rooting is the next step if necessary. If the word choice is still not accurate and bothers you, I apologize.
It has apparently no typical bootloader, and neither PC nor adb recognize it as an android device. In fact, direct USB file transfer is blocked so I need to use Sony's designated software. But an android system surely coexists according to the hacker who already rooted it.
Click to expand...
Click to collapse
Without some kind of way to flash or interface with the device there isn't much you can do.
I have a kindle fire HD that didn't come with a typical android system but does have a typical bootloader. The Amazon OS was removed and now it's full blown android but it required a "second" bootloader. You don't have a bootloader so I'm not sure what your options are with that device.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Droidriven said:
You must be an iPhone user that isn't familiar with android. Jailbreak in is an Apple thing, not an android thing.
In android it's called "rooting" and it isn't quite the same thing as jailbreaking an Apple device.
This device does not at all seem to be worth the price, especially considering the limitations it has. What a waste of hardware.
I would assume that you could port something from one of those other devices to work on yours but it really depends on how your hardware is designed compared to those devices.
Does your device have a typical bootloader like other android devices?
Is the bootloader unlocked?
If it is locked, can it be unlocked?
Does the device use fastboot or does it have a flash mode that is used with a specific PC flashtool?
If it is unlocked or if you can unlock it and it has a flash mode that can actually be used, you might be able to port a custom recovery from one of the devices you named then use that recovery to somehow root the device. If the device can't install android apps then it would probably involve using adb to root the device.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Click to expand...
Click to collapse
Jailbreaking is the process of modifying any electronic device in order to remove restrictions imposed by a manufacturer (Apple) or operator (to allow the installation of unauthorized software).
Rooting is the act of gaining access to the root account of a device (such as a smartphone or computer).
There is a huge difference between the two. You can't just say that rooting is Android's version of jailbreaking. Not accurate in the least.
https://www.androidpit.com/jailbreak-android
Sent from my SM-G928T using Tapatalk
MarkBell said:
Jailbreaking is the process of modifying any electronic device in order to remove restrictions imposed by a manufacturer (Apple) or operator (to allow the installation of unauthorized software).
Rooting is the act of gaining access to the root account of a device (such as a smartphone or computer).
There is a huge difference between the two. You can't just say that rooting is Android's version of jailbreaking. Not accurate in the least.
https://www.androidpit.com/jailbreak-android
Sent from my SM-G928T using Tapatalk
Click to expand...
Click to collapse
You're reading too much into what I said.
Basically, what I said was that jailbreaking isn't an android thing, it's an Apple thing(didn't say it was exclusively an Apple thing, just NOT an android thing). It applies to more than just Apple devices but on this website dedicated to mobile platforms, I'm only referring to its application in the mobile device world. For the mobile world it's pretty much only an Apple thing(still not exclusively but mostly so).
Then I said that in the android world it's called rooting(not exclusively an android thing, just NOT an Apple thing). And that jailbreaking and rooting aren't the same thing(this does not say that rooting is android's version of jailbreaking, that would imply that they are the same thing, I'm saying they aren't the same thing)
Basically, explaining what they "aren't", you explained what they "are".
I understand the difference, but thank you.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Droidriven said:
You're reading too much into what I said.
Basically, what I said was that jailbreaking isn't an android thing, it's an Apple thing(didn't say it was exclusively an Apple thing, just NOT an android thing). It applies to more than just Apple devices but on this website dedicated to mobile platforms, I'm only referring to its application in the mobile device world. For the mobile world it's pretty much only an Apple thing(still not exclusively but mostly so).
Then I said that in the android world it's called rooting(not exclusively an android thing, just NOT an Apple thing). And that jailbreaking and rooting aren't the same thing(this does not say that rooting is android's version of jailbreaking, that would imply that they are the same thing, I'm saying they aren't the same thing)
Basically, explaining what they "aren't", you explained what they "are".
I understand the difference, but thank you.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Click to expand...
Click to collapse
I tend to read too deeply into everything. It's the way I am. Lol.
Sent from my SM-G928T using Tapatalk
Could you please post some information about usb device? Just like PID & VID.
Do it like:
Connect DPT-RP1 to Linux, and then type this command 'lsusb'
P.S. Under Windows or MacOS system, you can find the information from system settings...
happy to help with simple things
thisvip said:
Could you please post some information about usb device? Just like PID & VID.
Do it like:
Connect DPT-RP1 to Linux, and then type this command 'lsusb'
P.S. Under Windows or MacOS system, you can find the information from system settings...
Click to expand...
Click to collapse
Bus 001 Device 008: ID 054c:0be5 Sony Corp.
It is good to see some people have been interested in this thread.
So far, I realized that the hacker used a hardware hacking method. I actually obtained the hacked system apps from one of his customer. I guess he did sometihng like directly modifying eMMC to root and put "USBDeviceSwitcher.apk" to allow an usual USB connection. Since I don't want to take such risk, I decided to wait until the first firmware to see if there could be an indirect way to penetrate the system files. But if you want to analyze the hacked system, contact me.
sartrism said:
It is good to see some people have been interested in this thread.
So far, I realized that the hacker used a hardware hacking method. I actually obtained the hacked system apps from one of his customer. I guess he did sometihng like directly modifying eMMC to root and put "USBDeviceSwitcher.apk" to allow an usual USB connection. Since I don't want to take such risk, I decided to wait until the first firmware to see if there could be an indirect way to penetrate the system files. But if you want to analyze the hacked system, contact me.
Click to expand...
Click to collapse
Does it have a web browser? Maybe you can utilize for example the Stagefright Exploit + DirtyC0W to get root.
I have found out some interesting stuff about the device with the help of the Digital Paper App.
The app is built using electron and there is a file: /Applications/Digital\ Paper\ App.app/Contents/Resources/app.asar
This file contains the electron javascript files, which handle all the communication with the device.
It can be extracted with: sudo asar extract app.asar output
(github_com/electron/asar)
This also requires node to be installed: with e.g. brew install node (changelog_com/posts/install-node-js-with-homebrew-on-os-x)
The app communicates with the device via Restlet-Framework/2.3.7 on port 8443 with tcp (no matter if it is the bluetooth, wifi or usb connection).
This is the only port that is open.
In the file: /Applications/Digital\ Paper\ App.app/Contents/Resources/output/node_modules/mw-error/lib/codeparams.js you can find all the relative paths, which are getting called during e.g. file transfer, firmware update and stuff.
Running the app and placing breakpoints reveals that before you can transfer files and stuff:
'/auth'
'/auth/nonce/'
are called in order to authenticate, which looks e.g. like url digitalpaper.local:8443/auth/nonce/1e9ee24d-6613-433a-9770-76b04333ac95
the last part of the call is the "client_id": "1e9ee24d-6613-433a-9770-76b04333ac95", which is retrieved via the url digitalpaper.local:8443/auth call.
digitalpaper.local:8443/auth/
Important:
In /Applications/Digital\ Paper\ App.app/Contents/Resources/output/lib/config.js
change the line
config.DEVBUILD = false;
to
config.DEVBUILD = true;
After you finished your modifications you have pack the output folder again:
sudo asar pack output app.asar
I did not have time to continue, but the following relative urls look promising (especially recovery_mode):
'/testmode/auth/nonce',
'/testmode/auth',
'/testmode/launch',
'/testmode/recovery_mode',
'/testmode/assets/{}',
mcplectrum said:
I have found out some interesting stuff about the device with the help of the Digital Paper App.
The app is built using electron and there is a file: /Applications/Digital\ Paper\ App.app/Contents/Resources/app.asar
This file contains the electron javascript files, which handle all the communication with the device.
It can be extracted with: sudo asar extract app.asar output
(github_com/electron/asar)
This also requires node to be installed: with e.g. brew install node (changelog_com/posts/install-node-js-with-homebrew-on-os-x)
The app communicates with the device via Restlet-Framework/2.3.7 on port 8443 with tcp (no matter if it is the bluetooth, wifi or usb connection).
This is the only port that is open.
In the file: /Applications/Digital\ Paper\ App.app/Contents/Resources/output/node_modules/mw-error/lib/codeparams.js you can find all the relative paths, which are getting called during e.g. file transfer, firmware update and stuff.
Running the app and placing breakpoints reveals that before you can transfer files and stuff:
'/auth'
'/auth/nonce/'
are called in order to authenticate, which looks e.g. like url digitalpaper.local:8443/auth/nonce/1e9ee24d-6613-433a-9770-76b04333ac95
the last part of the call is the "client_id": "1e9ee24d-6613-433a-9770-76b04333ac95", which is retrieved via the url digitalpaper.local:8443/auth call.
digitalpaper.local:8443/auth/
Important:
In /Applications/Digital\ Paper\ App.app/Contents/Resources/output/lib/config.js
change the line
config.DEVBUILD = false;
to
config.DEVBUILD = true;
After you finished your modifications you have pack the output folder again:
sudo asar pack output app.asar
I did not have time to continue, but the following relative urls look promising (especially recovery_mode):
'/testmode/auth/nonce',
'/testmode/auth',
'/testmode/launch',
'/testmode/recovery_mode',
'/testmode/assets/{}',
Click to expand...
Click to collapse
Hope you get some result from wifi side. I also realized they use the port 8443 but couldn't get further as you.
For whom trying to hack it, here is the link for the already 'hacked' system apps (including the original files) - that of the famous hacked RP1 video. Inside the subfolder S1, there are also the hacked system apps for DPT-S1 just in case.
https://www.dropbox.com/sh/dvtvokdzrgwjc83/AACXOJA-E56nUpUfiWUOzrM3a?dl=0
George Malas said:
Does it have a web browser? Maybe you can utilize for example the Stagefright Exploit + DirtyC0W to get root.
Click to expand...
Click to collapse
The stock device has no web browser, no sd-card, no usb connection, and no typical system. I think SONY was haunted by some security issues maybe because they thought the major users are lawyers or very important people? lol
Any chance to create a buffer overflow PDF to attack RP1's pdf reader?
I am unable to help, but wanted to let you know I am definitely interested in and supportive of this. If this device can be unlocked as suggested in that one youtube video then I would buy it, despite the steep price.
jess91 said:
I am unable to help, but wanted to let you know I am definitely interested in and supportive of this. If this device can be unlocked as suggested in that one youtube video then I would buy it, despite the steep price.
Click to expand...
Click to collapse
If you're interested and supportive of this then go buy one anyway and apply yourself to going forward figuring out how to get it done. Other than that, you're not supportive, you're just hopeful that someone figures it out and then you'll probably go get one.
DO NOT CONTACT ME VIA PM TO RECEIVE HELP, YOU WILL BE IGNORED. KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Hey guys,
I also recently got the RP1 and am also looking for ways to mod it. Big kudos and thanks to all of you for posting this! This alread is amazing. @sartrism: can you maybe give me a hint how to load the files on the rp1? Sorry if this might be a stupid question but I'm new to adroid and that stuff.
Paderico said:
Hey guys,
I also recently got the RP1 and am also looking for ways to mod it. Big kudos and thanks to all of you for posting this! This alread is amazing. @sartrism: can you maybe give me a hint how to load the files on the rp1? Sorry if this might be a stupid question but I'm new to adroid and that stuff.
Click to expand...
Click to collapse
Just a little update from my side. I'm currently tryng to recreate the steps @mcplectrum was using. It seems that my RP1 also uses other ports. I tried to wireshark the USB and WiFi connection. By that I saw that often GET /registration/information is called for Host: localhost:58052. Moreover the first call is GET /register/serial_number also on port 5808. This was via USB.
Trying to trigger the /auth/ call via Telnet returns nothing unfortunately. But also the 8080 port is open. Trying to call digitalpaper.local:8443/auth/ returns nothing on firefox.
@mcplectrum: how did you get the client_id and what would one need that for?
I also tried to change the config.DEVBUILD to true but that seemed to change nothing at all.
So to sum up what we know:
The device is using some kind of android structure, the source code seems to use the uboot bootloader, all communication is done by a rest restlet framework. So actually there should be some kind of way to use the restlet framework to PUT or POST the modified files.
The other option would be directly flash the eMMC right? I would take the risk and just load it on my device and see what happens. Any hints on how to do that?

[Joying for VW] Universal steering wheel controls with arduino

On Joying headunits with CAN Bus, it is not possibile to use resistor based USWC: this thread aims to overcome the limitation by using an Arduino MICRO connected to the receiving unit of the USWC and to the headunit via USB to simulate a hardware keyboard.
reserved 1
Github repository: https://github.com/MobeedoM-opensource/android-auto
reserved 2
reserved 3
surfer63 said:
In your code you also use the BOOT_COMPLETED broadcast. You know that with the Joying deep-sleep option, you will see that only on rare occasions? This is: only on reboots or power (dis)connects?
Click to expand...
Click to collapse
Yes i know thank you, i noticed that for some strange reason the firmware deactivates the accessibility service even at reboot (at true boot not only with ACC_OFF).
You use the "com.fyt.boot.ACCON" intent filter in your services. If it doesn't have serious consequences please also add the "com.glsx.boot.ACCON" for those users on Sofia that might want to start using your app as well. But this in turn would also require the "minSdkVersion 23" instead of "minSdkVersion 24" like you have now. My PX5 is on 8 so I have api level 26, but my old Sofia on the bench is on 6.0.1 and it would be handy to test there first. (I tried to build your code, but there are many "hurdles" in your app/build.gradle, so I need to dive a little deeper into it)
Click to expand...
Click to collapse
Yes of course i'll add the intent filter, but please note that the current version of the app doesn't use those intents on api level 26+ (my headunit), because of the background execution limits (the implicit intent is simply not received).
The only intent that i was able to trap, but i still need to investigate because it doesn't always work and I haven't figured out why yet, is the android.hardware.usb.action.USB_DEVICE_ATTACHED.
For the build.gradle, if you tell me what are the hurdles maybe i can help, also via PM if you prefere.
You have the method startAccessibilityService with the rooted system call: What does that actually do? Is it for the user to give access? Or the system to give access (as it is rooted)? Is it for the root_preference "OnlyBroadcast"?
Click to expand...
Click to collapse
An accessibility service cannot be started programmatically in android, the user must manually activate it with the switch in the accessibility services section.
That command is used to simulate the behavior of the user who changes the state of the switch, it requires root and it is not granted to work on all roms.
You use the "getCurrentForegroundPackage()". I guess this still works if your have (for example) your navi app in the foreground and your media player in the background and you want to skip to the NEXT, as you automatically come to the last "if" statement in your MediaKeysMapper. But does this also work when your navi app is the foreground program and you are listening to the radio or some "generic_syu" program in the background?
Click to expand...
Click to collapse
Yes you are right, the last use case is not covered. To manage it correctly you need to know which app is currently playing, maybe it is possbile to distinguish syu apps by non syu apps by checking the android AudioManager which i think is only used by non-syu apps.
bambapin said:
Yes of course i'll add the intent filter, but please note that the current version of the app doesn't use those intents on api level 26+ (my headunit), because of the background execution limits (the implicit intent is simply not received).
The only intent that i was able to trap, but i still need to investigate because it doesn't always work and I haven't figured out why yet, is the android.hardware.usb.action.USB_DEVICE_ATTACHED.
For the build.gradle, if you tell me what are the hurdles maybe i can help, also via PM if you prefer.
Click to expand...
Click to collapse
I know about the implicit intents, but on a Sofia on Android 6.0.1 (api level 23) they should still work.
W.r.t. the build.gradle.
I had to remove the private.gradle import statement, some signing statements, defProd and the like, and finally (also literally in time) upgrade my sdk from 27 to 29 to be able to do a simple "./gradlew assembleDebug".
So no issues anymore.
(Of course I had set compile version to 27 in the build.gradle, but I ran into "missing" xmls, which I first blamed on being not committed to the repo (your fault, not mine of course ), but which turned out to be part of sdk 28 and up, so still my fault ).
surfer63 said:
W.r.t. the build.gradle.
I had to remove the private.gradle import statement, some signing statements, defProd and the like, and finally (also literally in time) upgrade my sdk from 27 to 29 to be able to do a simple "./gradlew assembleDebug".
Click to expand...
Click to collapse
Ah yes, the private.gradle... it contains my private keys passwords so i preferred not to publish them on the internet .
Indeed that file must be placed next to the app build.gradle with this content:
Code:
ext {
my_keyAlias = 'YOUR_KEY_ALIAS'
my_keyPassword = 'YOUR_KEY_PASSWORD'
my_storeFileName = 'YOUR_KEYSTORE_FILEPATH'
my_storePassword = 'YOUR_KEYSTORE_PASSWORD'
}
bambapin said:
Yes you are right, the last use case is not covered. To manage it correctly you need to know which app is currently playing, maybe it is possbile to distinguish syu apps by non syu apps by checking the android AudioManager which i think is only used by non-syu apps.
Click to expand...
Click to collapse
Maybe I insult you with providing this link , but anyway: here it is: https://developer.android.com/guide/topics/media-apps/mediabuttons
And the image in post #1. How is red and black connected, and to what?
surfer63 said:
Maybe I insult you with providing this link , but anyway: here it is: https://developer.android.com/guide/topics/media-apps/mediabuttons
And the image in post #1. How is red and black connected, and to what?
Click to expand...
Click to collapse
No insults at all don't worry and even if it were i hardly get offended
Actually i'm not expert on this particular topic, at the beginning i tried to use the standard Android MediaControllers but it seemed to me that when it came to "syu" APPS everything was bypassed, but if you think it's a viable way i'll try again.
The photo is the final version that is now installed in the car.
I noticed that there was enough room inside the SWC receiver to insert the arduino, i made a little hole for the usb socket and i connected the arduino directly (yes i admit, i soldered to save the space of dupont ).
What you see is the inside of the receiver + the arduino. The black and red cables are the power supply of the receiver, the orange and blue are KEY1 and KEY2 (the white and gray of the video). The arduino is simply glued with a removable glue (patafix).
@surfer63 i was thinking again about the autostart after the ACCON.
In the end i managed to make the intent android.hardware.usb.action.USB_DEVICE_ATTACHED always work so the accessibility service is always restarted, but i'm still looking for a better alternative (using the navi app would work but it interfere with the audio mixing level).
I looked again at the code of syu.ms and saw that when the unit wakes up, a series of apps are always launched with hard-coded package names: eg. "com.yh.devicehelper" and "com.cpsdna.mirror" which i don't seem to find installed in the headunit.
Do you have any idea what they are?
If they are never installed, perhaps it is enough to create an app with one of those package names and the system will take care of starting it at ACCON.
bambapin said:
No insults at all don't worry and even if it were i hardly get offended
Actually i'm not expert on this particular topic, at the beginning i tried to use the standard Android MediaControllers but it seemed to me that when it came to "syu" APPS everything was bypassed, but if you think it's a viable way i'll try again.
The photo is the final version that is now installed in the car.
I noticed that there was enough room inside the SWC receiver to insert the arduino, i made a little hole for the usb socket and i connected the arduino directly (yes i admit, i soldered to save the space of dupont ).
What you see is the inside of the receiver + the arduino. The black and red cables are the power supply of the receiver, the orange and blue are KEY1 and KEY2 (the white and gray of the video). The arduino is simply glued with a removable glue (patafix).
Click to expand...
Click to collapse
I do indeed think that the SYU apps do nothing according standard Android rules, so the MediaController would only be helpful for any other app. I do think you need to check if "some" SYU app is active by using something like "this" or by checking the com.syu.ms apk (via jadx(-gui)) or so, because that one also checks on several places whether one of its own SYU app is active or not, and on top or not.
So the bottom side of of the plate with the red led and condensator (or so), is the bottom of the SWC controller circuit?? If so, the image now makes sense.
surfer63 said:
So the bottom side of of the plate with the red led and condensator (or so), is the bottom of the SWC controller circuit?? If so, the image now makes sense.
Click to expand...
Click to collapse
Yes, it is the bottom, when it is inserted it rests on the 4 pillars and leaves enough space below, there will be almost 1cm from the arduino.
The only negative thing i noticed is that with the arduino so close to the antenna the reception distance of the buttons is a little lower than before, but they still work.
bambapin said:
@surfer63 i was thinking again about the autostart after the ACCON.
In the end i managed to make the intent android.hardware.usb.action.USB_DEVICE_ATTACHED always work so the accessibility service is always restarted, but i'm still looking for a better alternative (using the navi app would work but it interfere with the audio mixing level).
I looked again at the code of syu.ms and saw that when the unit wakes up, a series of apps are always launched with hard-coded package names: eg. "com.yh.devicehelper" and "com.cpsdna.mirror" which i don't seem to find installed in the headunit.
Do you have any idea what they are?
If they are never installed, perhaps it is enough to create an app with one of those package names and the system will take care of starting it at ACCON.
Click to expand...
Click to collapse
It worked!!! :laugh:
The app attached is automatically launched by the syu.ms at ACC_ON.
I used the package name "com.cpsdna.mirror", i have no idea what the original app was supposed to do, but now we have a real autorunner at our disposal.
bambapin said:
It worked!!! :laugh:
The app attached is automatically launched by the syu.ms at ACC_ON.
I used the package name "com.cpsdna.mirror", i have no idea what the original app was supposed to do, but now we have a real autorunner at our disposal.
Click to expand...
Click to collapse
:good: Very nice.
There are many apps in this ms.apk that no longer exist. Some are hardcoded called inside the app, some are called via the text files in the assets/property, but no longer exist.
I assume it is related to http://www.cpsdna.com/solutions1.html and a previous "mirrorlink" application. zlink is now by another company.
What I would do (and did in the past) is making a "micro starter app" (11~16Kb) , that only starts the app you want. So the "com.cpsdna.mirror" started by ACC_ON, starts your "com.mobeedom.android.auto.jyhuremote".
If Joying/FYT updates their list of started apps, you can simply take another "old" app and still call your own app without having to rewrite all the packages inside your own code.
(And please don't use the appcompat for such a microstarter . It explodes your code from ~11-16Kb to 1.5MB. I really hate how Studio always adds that to your project even if you target APIs that don't need it, or your app as such doesn't need it)
It would only need something like:
Code:
PackageManager pManager = context.getPackageManager();
Intent intent = pManager.getLaunchIntentForPackage("com.mobeedom.android.auto.jyhuremote");
if (intent != null) {
context.startActivity(intent);
}
surfer63 said:
:good: Very nice.
There are many apps in this ms.apk that no longer exist. Some are hardcoded called inside the app, some are called via the text files in the assets/property, but no longer exist.
I assume it is related to http://www.cpsdna.com/solutions1.html and a previous "mirrorlink" application. zlink is now by another company.
What I would do (and did in the past) is making a "micro starter app" (11~16Kb) , that only starts the app you want. So the "com.cpsdna.mirror" started by ACC_ON, starts your "com.mobeedom.android.auto.jyhuremote".
If Joying/FYT updates their list of started apps, you can simply take another "old" app and still call your own app without having to rewrite all the packages inside your own code.
(And please don't use the appcompat for such a microstarter . It explodes your code from ~11-16Kb to 1.5MB. I really hate how Studio always adds that to your project even if you target APIs that don't need it, or your app as such doesn't need it)
It would only need something like:
Code:
PackageManager pManager = context.getPackageManager();
Intent intent = pManager.getLaunchIntentForPackage("com.mobeedom.android.auto.jyhuremote");
if (intent != null) {
context.startActivity(intent);
}
Click to expand...
Click to collapse
Ok ok, no AppCompat
Maybe i could also put a minimum of parameterization with the ability to choose what to launch, maybe even more than one app.
Do you think something like this could be useful in your JET?
bambapin said:
Ok ok, no AppCompat
Maybe i could also put a minimum of parameterization with the ability to choose what to launch, maybe even more than one app.
Do you think something like this could be useful in your JET?
Click to expand...
Click to collapse
I don't see it yet. What would be useful to start from my Jet apk? Can you explain?
Please also note that when I started the JET apk I knew absolutely nothing about java (and didn't want to know anything about java) and started in appinventor/thunkable, as that was easy enough. But it is a big mess of all kind of shell scripts called from my app using the "rootexec" plugin, because that was the only way to make it work.
If I would start again I would rewrite it immediately in java.
So perhaps your own app would be a much better basis than my JET apk.
Please don't think I'm against it, but I do not understand (yet?) why that would be useful.
surfer63 said:
I don't see it yet. What would be useful to start from my Jet apk? Can you explain?
Please also note that when I started the JET apk I knew absolutely nothing about java (and didn't want to know anything about java) and started in appinventor/thunkable, as that was easy enough. But it is a big mess of all kind of shell scripts called from my app using the "rootexec" plugin, because that was the only way to make it work.
If I would start again I would rewrite it immediately in java.
So perhaps your own app would be a much better basis than my JET apk.
Please don't think I'm against it, but I do not understand (yet?) why that would be useful.
Click to expand...
Click to collapse
Don't know, i thought of your JET because i see it as a great collection of tools dedicated to Joying head units.
Given that on android 8 the intents ACC_ON and ACC_OFF are not usable, it could be an additional tool that allows you to schedule actions to be performed on wakeup without without the need to set Tasker as an NAVI app and without Xposed, since it still doesn't work on SC9853i.
BTW about Xposed i am also afraid, but i really hope i'm wrong, that with the code obfuscation of the firmwware, the maintenance of the Xposed modules will become increasingly difficult.
However, i will make a mini app with a list of apps to launch at ACC_ON (in my case the Accessibility Service, Poweramp and the NAVI), the code will be available if you change your mind .
bambapin said:
Given that on android 8 the intents ACC_ON and ACC_OFF are not usable, ...
Click to expand...
Click to collapse
Based on your work on USB, I also started to work on that idea again and built a "UsbReceiver" in my FytHWOneKey. It works great on my old sofia (6.0.1), but the usb event (""android.hardware.usb.action.USB_DEVICE_ATTACHED"") is never triggered on my 8.0.0 PX5. It doesn't work there.
Does this USB still work for you on 8.1.0?
bambapin said:
BTW about Xposed i am also afraid, but i really hope i'm wrong, that with the code obfuscation of the firmwware, the maintenance of the Xposed modules will become increasingly difficult.
However, i will make a mini app with a list of apps to launch at ACC_ON (in my case the Accessibility Service, Poweramp and the NAVI), the code will be available if you change your mind .
Click to expand...
Click to collapse
Xposed will no longer be feasible indeed when you look at the code obfuscation.
Your list of apps to be started: An internal list or external list (ascii config/ini file?), or preferences list?
surfer63 said:
Based on your work on USB, I also started to work on that idea again and built a "UsbReceiver" in my FytHWOneKey. It works great on my old sofia (6.0.1), but the usb event (""android.hardware.usb.action.USB_DEVICE_ATTACHED"") is never triggered on my 8.0.0 PX5. It doesn't work there.
Does this USB still work for you on 8.1.0?
Click to expand...
Click to collapse
Yes, it's the intent i'm still using to re-activate the accessibility service. It seems strange to me that it is not triggered at all, do you have any other app installed that could "steal" it? Torque for example?
EDIT: did you fetch the last version from github? i added a .xml with the filtered devices, it could be required (it depends on the firmware implementation)
Xposed will no longer be feasible indeed when you look at the code obfuscation.
Your list of apps to be started: An internal list or external list (ascii config/ini file?), or preferences list?
Click to expand...
Click to collapse
Internal, stored in the shared preferences.
bambapin said:
Yes, it's the intent i'm still using to re-activate the accessibility service. It seems strange to me that it is not triggered at all, do you have any other app installed that could "steal" it? Torque for example?
EDIT: did you fetch the last version from github? i added a .xml with the filtered devices, it could be required (it depends on the firmware implementation)
Click to expand...
Click to collapse
No other apps, only my own FytHWOneKey.
I did see the xml, but did not understand it and wanted to ask later. Those vendor id's / product id's: Are those from your usb devices or are they from (internal) Joying devices?
I can only find one vendor-id in the USB device database.

Categories

Resources