Related
I am creating a little app that will let a user read what's in a certain textfile in /data/local, edit it, and then save it. I have gotten everything to work by using some tutorials here and there, but there's still something not working.
Root access has been achieved, and writing/reading the file is done too, but when pressing the "Write" button, I get a toast saying "open failed: EACCES (Permission denied)". Google unfortunately didn't help me much on this one. Also, I am using the WRITE_EXTERNAL_STORAGE permission.
Code:
Code:
package bas.sie.hai;
import java.io.BufferedReader;
import java.io.DataOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import android.os.Bundle;
import android.os.Environment;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.EditText;
import android.widget.Toast;
import com.actionbarsherlock.app.SherlockActivity;
public class DataLocalActivity extends SherlockActivity {
EditText txtData;
Button btnReadSDFile;
Button btnWriteSDFile;
Button btnReadSkipFile;
Button btnWriteSkipFile;
Button btnClearScreen;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
Process p;
try {
// Preform su to get root privledges
p = Runtime.getRuntime().exec("su");
// Attempt to write a file to a root-only
DataOutputStream os = new DataOutputStream(p.getOutputStream());
os.writeBytes("echo \"Do I have root?\" >/system/sd/temporary.txt\n");
// Close the terminal
os.writeBytes("exit\n");
os.flush();
try {
p.waitFor();
if (p.exitValue() != 255) {
// TODO Code to run on success
Toast.makeText(this, "root", Toast.LENGTH_LONG);
}
else {
// TODO Code to run on unsuccessful
Toast.makeText(this, "No root", Toast.LENGTH_LONG);
}
} catch (InterruptedException e) {
// TODO Code to run in interrupted exception
Toast.makeText(this, "No root", Toast.LENGTH_LONG);
}
} catch (IOException e) {
// TODO Code to run in input/output exception
Toast.makeText(this, "NO root", Toast.LENGTH_LONG);
}
if(!Environment.MEDIA_MOUNTED.equals(Environment.getExternalStorageState())){
Toast.makeText(this, "External SD card not mounted", Toast.LENGTH_LONG).show();
}
txtData = (EditText) findViewById(R.id.txtData);
btnReadSDFile = (Button) findViewById(R.id.btnReadSDFile);
btnReadSDFile.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
// write on SD card file data in the text box
try {
File myFile = new File("/data/local/move_cache.txt");
FileInputStream fIn = new FileInputStream(myFile);
BufferedReader myReader = new BufferedReader(
new InputStreamReader(fIn));
String aDataRow = "";
String aBuffer = "";
while ((aDataRow = myReader.readLine()) != null) {
aBuffer += aDataRow + "\n";
}
txtData.setText(aBuffer);
myReader.close();
Toast.makeText(getBaseContext(),
"Done reading from SD: 'move_cache.txt'",
Toast.LENGTH_SHORT).show();
} catch (Exception e) {
Toast.makeText(getBaseContext(), e.getMessage(),
Toast.LENGTH_SHORT).show();
}
}
});
btnWriteSDFile = (Button) findViewById(R.id.btnWriteSDFile);
btnWriteSDFile.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
// write on SD card file data in the text box
try {
File myFile = new File("/data/local/move_cache.txt");
myFile.createNewFile();
FileOutputStream fOut = new FileOutputStream(myFile);
OutputStreamWriter myOutWriter = new OutputStreamWriter(
fOut);
myOutWriter.append(txtData.getText());
myOutWriter.close();
fOut.close();
Toast.makeText(getBaseContext(),
"Done writing to SD: 'move_cache.txt'",
Toast.LENGTH_SHORT).show();
} catch (Exception e) {
Toast.makeText(getBaseContext(), e.getMessage(),
Toast.LENGTH_SHORT).show();
}
}
});
btnReadSkipFile = (Button) findViewById(R.id.btnReadSkipFile);
btnReadSkipFile.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
// write on SD card file data in the text box
try {
File myFile = new File("/data/local/skip_apps.txt");
FileInputStream fIn = new FileInputStream(myFile);
BufferedReader myReader = new BufferedReader(
new InputStreamReader(fIn));
String aDataRow = "";
String aBuffer = "";
while ((aDataRow = myReader.readLine()) != null) {
aBuffer += aDataRow + "\n";
}
txtData.setText(aBuffer);
myReader.close();
Toast.makeText(getBaseContext(),
"Done reading from SD: 'skip_apps.txt'",
Toast.LENGTH_SHORT).show();
} catch (Exception e) {
Toast.makeText(getBaseContext(), e.getMessage(),
Toast.LENGTH_SHORT).show();
}
}
});
btnWriteSkipFile = (Button) findViewById(R.id.btnWriteSkipFile);
btnWriteSkipFile.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
// write on SD card file data in the text box
try {
File myFile = new File("/data/local/skip_apps.txt");
myFile.createNewFile();
FileOutputStream fOut = new FileOutputStream(myFile);
OutputStreamWriter myOutWriter = new OutputStreamWriter(
fOut);
myOutWriter.append(txtData.getText());
myOutWriter.close();
fOut.close();
Toast.makeText(getBaseContext(),
"Done writing to SD: 'skip_apps.txt'",
Toast.LENGTH_SHORT).show();
} catch (Exception e) {
Toast.makeText(getBaseContext(), e.getMessage(),
Toast.LENGTH_SHORT).show();
}
}
});
btnClearScreen = (Button) findViewById(R.id.btnClearScreen);
btnClearScreen.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
// clear text box
txtData.setText("");
}
});
}// onCreate
}
Thanks in advance,
Bas
Dooder
1. Chaper 8. Have mercy on yourself.
2. coloredlogcat.py
3. why not
Code:
e.printStackTrace()
but
Code:
Toast.LENGTH_SHORT
is beyond me
4.
Code:
android.permissions.WRITE_EXTERNAL_STORAGE
does not equal permissions to write to
Code:
/data/local
5.
Google unfortunately didn't help me much on this one
Click to expand...
Click to collapse
Moment of honesty. G-FU sucks or you just gave up?
I am an a-hole for a reason here. All you need to know is out there. No one else will hit you harder on the head with a RTFM board than a coder.
el_bhm said:
Dooder
1. Chaper 8. Have mercy on yourself.
2. coloredlogcat.py
3. why not
Code:
e.printStackTrace()
but
Code:
Toast.LENGTH_SHORT
is beyond me
4.
Code:
android.permissions.WRITE_EXTERNAL_STORAGE
does not equal permissions to write to
Code:
/data/local
5.
Moment of honesty. G-FU sucks or you just gave up?
I am an a-hole for a reason here. All you need to know is out there. No one else will hit you harder on the head with a RTFM board than a coder.
Click to expand...
Click to collapse
The code is mostly from a tutorial, with a few edits. Why use stackTrace on a test? Also, I test on the device for reliability and root access. It's easier to see a Toast there, so didn't remove it.
About the Chapter 8: Yes, onClickListener is not the best way (skimmed over it, it's 1:26 AM here), but here too: optimizations later.
About Google: I Googled, didn't find anything that really could help me along so that I understood, asked in three other places. SO was someone who didn't reply later on, Google Groups said my permission was wrong, as I said WRITE_TO_EXTERNAL_STORAGE. I corrected that, saying I had the right permission but I wrote down the wrong one (hastily. Stupid, I know...), and here, on XDA, you're the only post yet. I have waited between posts to post it on all those boards, as I'm not an a**hole.
If any more information is needed, just tell me.
Bas
EDIT: Missed a bit. About the writing: I know now, it's just that I have no idea how to proceed from root access to writing there. And I do hope to learn how to do it.
1. You'd rather want to write into
Code:
/data/data/[package]/
Is there any particular reason you want to write directly to local? Some "system wide" app? From code I understand this is some tabbed app(?). Or is it just test for root?
Unless you have somewhat extensive knowledge of Linux and programming, don't go into root access. Make yourself a favour and get as much knowledge of objective programming first. It seems it was inspired by Outler doing root in part two. He's doing ADK in part 3. These are not easy things.
2. Are you sure you are writing anything? With this code I am getting nowhere actually.
I have not written anything with root (main reason it caught my attention). My best guess is though, permissions are not escalated for objects you are creating while setting up listeners for buttons.
From brief reading of the code and documentation it seems that you are escalating permissions for Process p which you works in conjunction with DataOutputStream. While setting up listeners you are not doing anything with p anymore.
My best guess permissions escalation would apply to the whole package, but as I see it, it does not happen.
EDIT: Besides, keep in mind you are writing a file via echoing through shell. Which is not equivalent of writing through instances of classes in onClickListeners
3. As to why printStackTrace()
Unless you are running Windows(which for Android development I really feel you should not) with coloredlogcat.py you'll have much more comprehensive output to troubleshoot the app. Line where problem occurs. Where it originates, where it goes, etc.
There should be some interpreter of python for Windows, but I don't know how the script will behave though.
4. Inserting logcat output is always helpful.
Providing the layout is always helpful.
el_bhm said:
1. You'd rather want to write into
Code:
/data/data/[package]/
Is there any particular reason you want to write directly to local? Some "system wide" app? From code I understand this is some tabbed app(?). Or is it just test for root?
Unless you have somewhat extensive knowledge of Linux and programming, don't go into root access. Make yourself a favour and get as much knowledge of objective programming first. It seems it was inspired by Outler doing root in part two. He's doing ADK in part 3. These are not easy things.
2. Are you sure you are writing anything? With this code I am getting nowhere actually.
I have not written anything with root (main reason it caught my attention). My best guess is though, permissions are not escalated for objects you are creating while setting up listeners for buttons.
From brief reading of the code and documentation it seems that you are escalating permissions for Process p which you works in conjunction with DataOutputStream. While setting up listeners you are not doing anything with p anymore.
My best guess permissions escalation would apply to the whole package, but as I see it, it does not happen.
EDIT: Besides, keep in mind you are writing a file via echoing through shell. Which is not equivalent of writing through instances of classes in onClickListeners
3. As to why printStackTrace()
Unless you are running Windows(which for Android development I really feel you should not) with coloredlogcat.py you'll have much more comprehensive output to troubleshoot the app. Line where problem occurs. Where it originates, where it goes, etc.
There should be some interpreter of python for Windows, but I don't know how the script will behave though.
4. Inserting logcat output is always helpful.
Providing the layout is always helpful.
Click to expand...
Click to collapse
The files I'm writing are supposed to be in /data/local. Writing anywhere else would obviously kind of defeat the purpose.
I don't really have knowledge of Linux, didn't know you had to to be able to write a file. On the other hand, I had basically no knowledge of Android when I started writing my first app, and that worked out quite well, if I do say so myself.
About the permissions for the writing: I think you are right about that. I simply followed a tutorial, added SU permission check, and changed the path. Then tried to get that working.
I am running Windows. I do have Ubuntu on a bootable USB and on my HDD, but on the stick it has a low res and doesn't save any configs (which is not that weird), and on my HDD it suddenly fails to boot, and WUBI won't let me uninstall...
Plus, too much fiddling. Why is it so hard to get Flash installed, for God's sake?
About the LogCat output: I'm not really one to hook my phone up to my PC for that, unless no other solution is possible. Not because I'm lazy, but because my PC generally takes a couple of minutes to recognize the phone, open Explorer, etc. when I am doing a couple of other things.
I guess I'll just give up. Do you have any sites/places where I can gain some valuable knowledge about this?
Bas
About that permission check. Well, it passes the test. Thing is, there is no
Code:
/system/sd/temporary.txt
after I drop to adb shell.
Is that path the one you had set? IIRC Samsung does something funky with internal/external memory mounts in their devices. Is that path valid at all?
I'm guessing echo fails but passes the su test. So permissions are good, it seems.
Theoretically you can try parsing contents you need to that command you are basically executing. If there is a file in
Code:
/system/sd/
You could write file you need as temps wherever you have rights, then gain permissions and copy the contents via
Code:
cat [path_to_temp_file] > /data/local/file
Going offtopic.
Never. Ever use WUBI. Seriously. Just read about install process. If it fails on normal CD, download alternate. A bit more daunting but still should be manageable. Or get other distro like Mint.
It's enough to copy file to
Code:
~/.mozilla/plugins
. FF and Opera should easily use it.
Or just install
Code:
ubuntu-restricte-extras
. It should have flash.
You can also get to your phone over wifi. Just get adbWireless from market.
Knowledge? On what?
Programming? Read documentation of android. Many tutorials. Really easy to read (compared to other OS docs), extensively described.
Stackoverflow
Get any O'reily books.
Android? See above.
Linux? Stop expecting from any distro to behave like Windows and use it as you would know nothing about PC. You'll save yourself much time and frustration.
webup8, omgubuntu, planet-ubuntu. Enough there to start.
el_bhm said:
About that permission check. Well, it passes the test. Thing is, there is no
Code:
/system/sd/temporary.txt
after I drop to adb shell.
Is that path the one you had set? IIRC Samsung does something funky with internal/external memory mounts in their devices. Is that path valid at all?
I'm guessing echo fails but passes the su test. So permissions are good, it seems.
Theoretically you can try parsing contents you need to that command you are basically executing. If there is a file in
Code:
/system/sd/
You could write file you need as temps wherever you have rights, then gain permissions and copy the contents via
Code:
cat [path_to_temp_file] > /data/local/file
Going offtopic.
Never. Ever use WUBI. Seriously. Just read about install process. If it fails on normal CD, download alternate. A bit more daunting but still should be manageable. Or get other distro like Mint.
It's enough to copy file to
Code:
~/.mozilla/plugins
. FF and Opera should easily use it.
Or just install
Code:
ubuntu-restricte-extras
. It should have flash.
You can also get to your phone over wifi. Just get adbWireless from market.
Knowledge? On what?
Programming? Read documentation of android. Many tutorials. Really easy to read (compared to other OS docs), extensively described.
Stackoverflow
Get any O'reily books.
Android? See above.
Linux? Stop expecting from any distro to behave like Windows and use it as you would know nothing about PC. You'll save yourself much time and frustration.
webup8, omgubuntu, planet-ubuntu. Enough there to start.
Click to expand...
Click to collapse
Well, this is intended for AOSP ROMs, so I was thinking that there shouldn't be any problem in trying to write a file in that directory. But yes, Samsung does do some weird things...
About the copying and then moving from there: Might be a good idea if I can figure it out. However, do you think that will suddenly work?
The install at first was planned to be from the bootable stick I have, but when I read about WUBI, it seemed so easy. Easy to deinstall Ubuntu, too. Anyhow, I think a friend kind of borked it not too long ago. Pressed the wrong button somewhere, might have slightly affected the MBR (Windows boot animation is also gone now, back to Vista ).
Could you explain a bit more about the Flash install? It seemed (and truly was) so tedious at the time for something that was still slow and laggy... In my experience, don't get me wrong.
I have used AirDroid for example for reaching my phone, good suggestion there.
On the topic of developing (circling back around ), I will be looking into your suggestions. I do use Google and tutorials a lot, and SO has been quite a good help in that. Also, asking people to help personally (GTalk, for example, or PM on a forum), has got me quite a long way.
And using Ubuntu like I know nothing: It was quite different . I noticed that almost all of my knowledge was rendered useless in a matter of minutes haha. Bad thing is I did still think I knew, I guess. Led to frustration over it being so annoying. I guess it takes a lot of getting used to.
If that "temporary.txt" file is created, I don't see why it should fail since it passes the Root check.
instead of
Code:
cat
you may as well use
Code:
cp
which is basically command for copy.
About Flash (on which even Adobe is dropping a ball since they have balls to finally admit it's a joke anyway) you can read here.
https://help.ubuntu.com/community/RestrictedFormats
Alternate version of installer never failed me so far.
el_bhm said:
If that "temporary.txt" file is created, I don't see why it should fail since it passes the Root check.
instead of
Code:
cat
you may as well use
Code:
cp
which is basically command for copy.
About Flash (on which even Adobe is dropping a ball since they have balls to finally admit it's a joke anyway) you can read here.
https://help.ubuntu.com/community/RestrictedFormats
Alternate version of installer never failed me so far.
Click to expand...
Click to collapse
I'll take a look at using cp. However, it might be some time before I pick this up again. My earlier project has almost been accepted by the person who asked me to make it, so first I'll be busy on that.
But the basic thing here is to create it somewhere else and copy it, right? Let's hope that works, then .
Also, I'll be looking at your suggestions for Flash and the alternate installer, thanks a lot!
Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums & Read the Forum Rules
Moving to Q&A
Found this on Huawei's webpage: http://www.huaweidevice.com/worldwi...=toDownloadFile&flay=software&softid=NDcwODE=
open source_wlan.tar_S7_Android2.2
Would be nice if someone has the time to look at this.
The binary file that shipped with my Huawei firmware has version 4.218.248.17
Edit:
Tested and working. Forgot to update text here.
Mirrored the file for convenience for everyone who wants this. The first link actually was wrong, so I changed it.
Put this in an Android tree (such as /hardware/broadcom), do breakfast/lunch after envsetup, and perform 'make dhdko' with the kernel files present at /kernel. This is for Froyo. To build for Gingerbread, LOCAL_MODULE_TAGS cannot be equal to 'user', so you need to change Android.mk to say 'optional' instead. That's if you want to use Android.mk to build. If you are not building the whole tree, remember to make a folder /lib/modules/, or dhd.ko will not copy from the product obj folder properly.
Not sure how this will build for ICS/Jellybean, but at least now we have the source code that actually builds a proper module.
Kernel objects need to be in the right place. I did something to the effect of:
make -C kernel O=/sources/aosp/out/target/product/s7/obj/KERNEL_OBJ ARCH=arm CROSS_COMPILE=arm-eabi-
Built module works fine and is the same version shipped with Android 2.2 (4.218.248.17).
The driver is actually eerily similar to the bcm4329 kernel 3.4 bcm4329 driver. So much so i figured out what caused the sdio timeout.
Offending code causing emulate domain manager error om 2.6.35 when removed, sdio timeout when added:
dhd_linux.c:
Code:
static int
dhd_watchdog_thread(void *data)
{
dhd_info_t *dhd = (dhd_info_t *)data;
/* This thread doesn't need any user-level access,
* so get rid of all our resources
*/
#ifdef DHD_SCHED
if (dhd_watchdog_prio > 0) {
struct sched_param param;
param.sched_priority = (dhd_watchdog_prio < MAX_RT_PRIO)?
dhd_watchdog_prio:(MAX_RT_PRIO-1);
setScheduler(current, SCHED_FIFO, ¶m);
}
#endif /* DHD_SCHED */
DAEMONIZE("dhd_watchdog");
/* Run until signal received */
while (1) {
if (down_interruptible (&dhd->watchdog_sem) == 0) {
offender---------> dhd_os_sdlock(&dhd->pub);
if (dhd->pub.dongle_reset == FALSE) {
For kernels : http://threader.zapto.org/experimental/s7/wifi/bcm4329-30-09-13.tar.bz2
I came across this site of a guy named Dan Rosenburg stating that he exploited the At&t and Verizon variants. Maybe this is helpful for exploiters I don't know but thought I'd post. :good:variants.http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html?m=1
Azimuth Security
Azimuth Security
Thursday, May 23, 2013
Exploiting Samsung Galaxy S4 Secure Boot
Launched in April 2013, the Samsung Galaxy S4 is expected to be one of the top-selling smartphones of the year, having sold 10 million units in its first month of sales. While the majority of released models include an unlocked bootloader, which allows users to flash custom kernels and make other modifications to the software on their own devices, AT&T and Verizon branded devices ship with a locked bootloader that prevents these types of modifications. In this post, I'll provide details on how Samsung implement this locking mechanism, and publish a vulnerability in the implementation that allows bypassing the signature checks to run custom unsigned kernels and recovery images.
Both the AT&T (SGH-I337) and Verizon (SCH-I545) models utilize the Qualcomm APQ8064T chipset. As described in my previous blog post on Motorola's bootloader, Qualcomm leverages software-programmable fuses known as QFuses to implement a trusted boot sequence. In summary, each stage of the boot process cryptographically verifies the integrity of the subsequent stage, with the trust root originating in QFuse values. After the early boot stages bootstrap various hardware components, Samsung's APPSBL ("Application Secondary Bootloader") is loaded and run. This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.
A quick glance at aboot (adopting the name of the partition on which this bootloader resides) revealed that it is nearly identical to the open source lk ("Little Kernel") project, which undoubtedly saved me many hours of tedious reverse engineering. By locating cross-references to strings found in both lk and aboot, I was able to quickly identify the functions that implement signature verification and booting of the Linux kernel.
The central logic to load, verify, and boot the Linux kernel and ramdisk contained in either the boot or recovery partitions is implemented in the boot_linux_from_mmc() function. First, the function determines whether it is booting the main boot partition, containing the Linux kernel and ramdisk used by the Android OS, or the recovery partition, which contains the kernel and ramdisk used by the Android recovery subsystem. Then, the first page of the appropriate partition is read into physical memory from the eMMC flash storage:
if (!boot_into_recovery) {
index = partition_get_index("boot");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No boot partition found\n");
return -1;
}
}
else {
index = partition_get_index("recovery");
ptn = partition_get_offset(index);
if (ptn == 0) {
dprintf(CRITICAL, "ERROR: No recovery partition found\n");
return -1;
}
}
if (mmc_read(ptn + offset, (unsigned int *) buf, page_size)) {
dprintf(CRITICAL, "ERROR: Cannot read boot image header\n");
return -1;
}
This code is straight out of lk's implementation. Next, after performing some sanity-checking of the boot image, which contains a custom header format, the function loads the kernel and ramdisk into memory at the addresses requested in the boot image header:
hdr = (struct boot_img_hdr *)buf;
image_addr = target_get_scratch_address();
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask) + 0x200;
imagesize_actual = (page_size + kernel_actual + ramdisk_actual);
memcpy(image_addr, hdr, page_size);
offset = page_size;
/* Load kernel */
if (mmc_read(ptn + offset, (void *)hdr->kernel_addr, kernel_actual)) {
dprintf(CRITICAL, "ERROR: Cannot read kernel image\n");
return -1;
}
memcpy(image_addr + offset, hdr->kernel_addr, kernel_actual);
offset += kernel_actual;
/* Load ramdisk */
if (mmc_read(ptn + offset, (void *)hdr->ramdisk_addr, ramdisk_actual)) {
dprintf(CRITICAL, "ERROR: Cannot read ramdisk image\n");
return -1;
}
memcpy(image_addr + offset, hdr->ramdisk_addr, ramdisk_actual);
offset += ramdisk_actual;
This is still essentially identical to lk's implementation, with the addition of code to copy the individual pieces of the boot image to the image_addr location. Finally, the function performs signature verification of the entire image. If signature verification succeeds, the kernel is booted; otherwise, a tampering warning is displayed and the device fails to boot:
if (check_sig(boot_into_recovery))
{
if (!is_engineering_device())
{
dprintf("kernel secure check fail.\n");
print_console("SECURE FAIL: KERNEL");
while (1)
{
/* Display tampered screen and halt */
...
}
}
}
/* Boot the Linux kernel */
...
The is_engineering_device() function simply returns the value of a global variable that is set at an earlier stage in the boot process based on whether or not the chipset ID (an unchangeable hardware value) of the device indicates it is an engineering or production device.
Examining the check_sig() function in more detail revealed that aboot uses the open-source mincrypt implementation of RSA for signature validation. The bootloader uses an RSA-2048 public key contained in aboot to decrypt a signature contained in the boot image itself, and compares the resulting plaintext against the SHA1 hash of the boot image. Since any modifications to the boot image would result in a different SHA1 hash, it is not possible to generate a valid signed boot image without breaking RSA-2048, generating a specific SHA1 collision, or obtaining Samsung's private signing key.
The astute reader will have already noticed the design flaw present in the above program logic. Notice the order in which the steps are performed: first, aboot loads the kernel and ramdisk into memory at the addresses requested by the boot image header, and then signature validation is performed after this loading is complete. Because the boot image header is read straight from eMMC flash prior to any signature validation, it contains essentially untrusted data. As a result, it's possible to flash a maliciously crafted boot image whose header values cause aboot to read the kernel or ramdisk into physical memory directly on top of aboot itself!
Exploitation of this flaw proved to be fairly straightforward. I prepare a specially crafted boot image that specifies a ramdisk load address equal to the address of the check_sig() function in aboot physical memory. In my malicious boot image, I place shellcode where the ramdisk is expected to reside. I flash this image by leveraging root access in the Android operating system to write to the boot block device. When aboot reads the supposed ramdisk from eMMC flash, it actually overwrites the check_sig() function with my shellcode, and then invokes it. The shellcode simply patches up the boot image header to contain sane values, copies the actual kernel and ramdisk into appropriate locations in memory, and returns zero, indicating the signature verification succeeded. At this point, aboot continues the boot process and finally boots my unsigned kernel and ramdisk. Victory!
Check the date. I do believe that is the loki exploit.
It is Loki.... Doesn't work past MDK...
However if you check the other bootloader thread, Dan just released some stuff today that may lead to an exploit for us on builds later than that!
Jraider44 said:
It is Loki.... Doesn't work past MDK...
However if you check the other bootloader thread, Dan just released some stuff today that may lead to an exploit for us on builds later than that!
Click to expand...
Click to collapse
Oh ok thank for the reply mind sending me a link if his other thread? And hopefully we get the bootloader unlocked before 2015
instarichisdope said:
Oh ok thank for the reply mind sending me a link if his other thread? And hopefully we get the bootloader unlocked before 2015
Click to expand...
Click to collapse
The thread can be found here: http://forum.xda-developers.com/showthread.php?t=2500826
Yeah all hopes! Surge and the other guys working out of that thread are all great devs, and if anybody can do anything with the information released today, they can.
Closing this thread as the info is already out there.
Recently I have reverse engineered aboot (emmc_appsboot.mbn) from ROM riva_images_V8.5.7.0.NCKCNED_20171025.0000.00_7.1_cn ( en.miui.com/thread-1026306-1-1.html )(because this is my first post and I don't have permission to post outside link, you have to add http in those url), and discovered a way to bypass bootloader lock by using several bugs in Xiaomi customized aboot.
Xiaomi's aboot is based on Qualcomm's little kernel which is open sourced and can be download at source.codeaurora.org/quic/le/kernel/lk/ , so I will use function name inside those source file in discussion below even though some of those function have been modified by Xiaomi.
Relevant function to verify and boot linux is boot_linux_from_mmc, so I'll start from here:
boot_linux_from_mmc: call boot_verifier_init()
boot_verifier_init: set device state to GREEN boot_linux_from_mmc: call verify_signed_bootimg()
verify_signed_bootimg: call boot_verify_image()
boot_verify_image: call read_der_message_length() to get length of signature
boot_verify_image: if length of signature is too large, then boot_verify_image will return false to indicate verification failure
boot_verify_image: otherwise call and return verification result of verify_image_with_sig(inlined)
verify_image_with_sig: set device state to RED if image is not signed by Xiaomi. verify_signed_bootimg: call splash_screen_mmc() to show "The system has been destroyed" if verification failed
verify_signed_bootimg: shoudown device if splash_screen_mmc() succeed, otherwise continue boot boot_linux_from_mmc: call send_rot_command()
send_rot_command: check device state, if it's YELLOW or RED, than boot will failed because it try to read embedded cert which is not initialized by Xiaomi
To successfully bypass bootloader lock we need:
1. make sure device state is GREEN so that send_rot_command won't failed, this can be achieved by making read_der_message_length return a large value to avoid calling verify_image_with_sig.
one way to do this is to append[NOTE1] image with a large length encoded in der (eg. 0x30, 0x83, 0x19, 0x89, 0x64)
2. make sure splash_screen_mmc() failed so that booting process can be continued.
this can be achieved by change the magic number in the header of splash partition from "SPLASH!!" to any other value (eg. "19890604")
Steps to bypass:
0 note that all those steps can be done offline, so no information will send to Xiaomi or anyone
0 in this tutorial I'll demonstrate how to use twrp recovery with locked bootloader
1 using test point to enter EDL mode(will void your warranty!!!)
2 unzip MiFlash, you should see QSaharaServer.exe and fh_loader.exe
3 create a sub folder called "tmp"
4 extract prog_emmc_firehose_8917_ddr.mbn & rawprogram0.xml & splash.img from riva_images_V8.5.7.0.NCKCNED_20171025.0000.00_7.1_cn and put them into "tmp"
5 append a 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64 to twrp-3.2.1-0-riva.img then put the resulting file to "tmp" and rename it to "recovery.img"
6 change the first 8 byte in splash.img to "19890604"
7 create "hack_splash.xml" inside "tmp", then copy&paste relevant section from rawprogram0.xml to "hack_splash.xml", the resulting file should look like this:
Code:
<?xml version="1.0" ?>
<data>
<program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="splash.img" label="splash" num_partition_sectors="40960" physical_partition_number="0" size_in_KB="20480.0" sparse="false" start_byte_hex="0x14000000" start_sector="655360" />
</data>
8 create "twrp.xml" inside "tmp", then copy&paste relevant recovery section from rawprogram0.xml to "twrp.xml", the resulting file should look like this:
Code:
<?xml version="1.0" ?>
<data>
<program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="recovery.img" label="recovery" num_partition_sectors="131072" physical_partition_number="0" size_in_KB="65536.0" sparse="false" start_byte_hex="0x1c200000" start_sector="921600" />
</data>
9 run "QSaharaServer.exe -p \\.\COM10 -s 13rog_emmc_firehose_8917_ddr.mbn -b tmp" to initialize firehose. (replace COM10 with the COM port of you phone, the same as below)
10 run "fh_loader.exe --search_path=tmp --port=\\.\COM10 --sendxml=hack_splash.xml" to flash modified splash
11 run "fh_loader.exe --search_path=tmp --port=\\.\COM10 --sendxml=twrp.xml" to flash twrp recovery
12 done
If you want flash custom ROM, you just need to append[NOTE1] boot.img
NOTE1: append should work in most case, but not always. the corrected place to write 0x30, 0x83, 0x19, 0x89, 0x64 is calculate from image header, it's defined as:
Code:
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned dt_size; /* device_tree in bytes */
unsigned unused; /* future expansion: should be 0 */
....
};
and then calculate:
Code:
if (hdr->page_size && (hdr->page_size != page_size)) {
page_size = hdr->page_size;
page_mask = page_size - 1;
}
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask);
second_actual = ROUND_TO_PAGE(hdr->second_size, page_mask);
dt_size = hdr->dt_size;
dt_actual = ROUND_TO_PAGE(dt_size, page_mask);
imagesize_actual = (page_size + kernel_actual + ramdisk_actual + second_actual + dt_actual);
imagesize_actual is the place to write
NOTE2: There may be a easier way to enter EDL considering there are so many bug(eg. uninitialized stack variable, buffer overrun, missing bound check) in Xiaomi's modification, but I haven't bothered to check since my goal is achieved.
NOTE3: I suspect other model from Xiaomi may have similar bugs that bootloader lock can be bypassed using this method, but I don't have other phones to confirm my belief.
xaacnz said:
Xiaomi's aboot is based on Qualcomm's little kernel which is open sourced and can be download at source.codeaurora.org/kernel/lk/
Click to expand...
Click to collapse
Did you meant: source.codeaurora.org/quic/le/kernel/lk
abdihaikal said:
Did you meant: source.codeaurora.org/quic/le/kernel/lk
Click to expand...
Click to collapse
Yes, they must have removed the original url.
Code:
[email protected]:~/lk$ git remote show origin | head
* remote origin
Fetch URL: https://source.codeaurora.org/kernel/lk/
Push URL: https://source.codeaurora.org/kernel/lk/
HEAD branch (remote HEAD is ambiguous, may be one of the following):
aosp/master
github-kernel_lk/aosp/master
Remote branches:
APSS.FSM.3.0 tracked
APSS.FSM.3.0.r5.1.1 tracked
APSS.FSM.3.0.r6 tracked
Thank you for the method.
I tried ot and flashed TWRP only, but when I use it to flash custom ROMS, the device wont boot. It will show for a millisecond a picture of penguin and then goes off.
Any ideas??
Thanks
xaacnz said:
Recently I have reverse engineered aboot....
If you want flash custom ROM, you just need to append[NOTE1] boot.img
NOTE1: append should work in most case, but not always. the corrected place to write 0x30, 0x83, 0x19, 0x89, 0x64 is calculate from image header, it's defined as:.
Click to expand...
Click to collapse
You need to patch boot.img inside those ROMS by appending 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64
utumno00 said:
Thank you for the method.
I tried ot and flashed TWRP only, but when I use it to flash custom ROMS, the device wont boot. It will show for a millisecond a picture of penguin and then goes off.
Any ideas??
Thanks
Click to expand...
Click to collapse
I am amazed and I dont know how to tell that I thank you. Can you help me? I patch and i flash what?
xaacnz said:
You need to patch boot.img inside those ROMS by appending 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64
Click to expand...
Click to collapse
Let's say you want flash https://forum.xda-developers.com/android/development/rom-crdroid-v3-8-5-redmi-5a-t3752066
1 download crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
2 extract boot.img from crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
3 patch the extracted boot.img just like what you did with twrp-3.2.1-0-riva.img
4 put the patched boot.img back in crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
5 flash the modified crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
utumno00 said:
I am amazed and I dont know how to tell that I thank you. Can you help me? I patch and i flash what?
Click to expand...
Click to collapse
Success!!
I tried with Viper ROM though, as it was the one I had already downloaded.
Is the crDroid the one that you suggest?
Have you tried the Oreo one?
I want to thank you one more time for the help.
Greetings from Greece and Colombia.
xaacnz said:
Let's say you want flash https://forum.xda-developers.com/android/development/rom-crdroid-v3-8-5-redmi-5a-t3752066
1 download crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
2 extract boot.img from crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
3 patch the extracted boot.img just like what you did with twrp-3.2.1-0-riva.img
4 put the patched boot.img back in crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
5 flash the modified crDroidAndroid-7.1.2-20180218-riva-v3.8.5.zip
Click to expand...
Click to collapse
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
utumno00 said:
Success!!
I tried with Viper ROM though, as it was the one I had already downloaded.
Is the crDroid the one that you suggest?
Have you tried the Oreo one?
I want to thank you one more time for the help.
Greetings from Greece and Colombia.
Click to expand...
Click to collapse
Can you share your own rom base on LOS 15.1? Please
xaacnz said:
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
Click to expand...
Click to collapse
It's has some custom modifications like swapping back & recent app buttons as I'm left handed, I will try to build a more generic one once I get some free time.
boyrobbie said:
Can you share your own rom base on LOS 15.1? Please
Click to expand...
Click to collapse
@xaacnz
That's a very informative post :good:
Perhaps you can dump the firmware related partitions before and after unlocking the bootloader 'officially', so that it can be easier for us to find (possible) ways to unlock (not bypass) devices based on Xiaomi's implementation of Qualcomm LK.
I'm tagging @osm0sis to take part in the discussion.
xaacnz said:
It's has some custom modifications like swapping back & recent app buttons as I'm left handed, I will try to build a more generic one once I get some free time.
Click to expand...
Click to collapse
Thanks for your kindness, i'm waiting for that
Titokhan said:
@xaacnz
That's a very informative post :good:
Perhaps you can dump the firmware related partitions before and after unlocking the bootloader 'officially', so that it can be easier for us to find (possible) ways to unlock (not bypass) devices based on Xiaomi's implementation of Qualcomm LK.
I'm tagging @osm0sis to take part in the discussion.
Click to expand...
Click to collapse
All stages of bootloader except PBL can be found in fastboot ROM, and PBL can be obtained by using testpoint: https://alephsecurity.com/2018/01/22/qualcomm-edl-1/
The 'official' unlocking process is:
1 submit cpuid which is eFused in soc to Xiaomi.
2 Xiaomi sign the cpuid with it's private RSA key.
3 write the signature to 'devinfo' partition at offset 0xE4.
The verification process is:
1 read the signature from 'devinfo' partition.
2 verify it using public key embedded in aboot.
3 decode the verification result as base64.
4 compare the decoded value with cpuid read from soc, bootloader is unlocked if it's the same.
There are some bugs in verification process:
1 signature is padded using PKCS #1 v1.5, but verification process didn't check plaintext size, thus any plaintext starts with desired prefix will unlock bootloader, effectively reducing the complexity of brute force.
2 any value outside of base64's 64 characters table is treated as 'A', this reduce brute force complexity further.
3 base64 decode will not terminate until '=' is encountered, this create opportunity for buffer overrun, though input(RSA verification result) is hard to control.
4 base64 decode is skipped if first byte of PKCS #1 v1.5 payload is zero, this resulting in comparison of uninitialized stack value to cpuid and maybe exploitable to unlock phone.
I'm shocked that one can write so many bugs in such short function.
xaacnz said:
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
Click to expand...
Click to collapse
Bro! we have been using the build you uploaded on android file host on may 16 2018. The build you uploaded has all bugs fixed in lineage OS 15.1. Some developers of Redmi 5a(RIVA) has been trying to contact you. They need the source of your ROM and kernel you uploaded on 16 may. Please reply.
xaacnz said:
I'm glad I was able to help.
I have used neither of them, so I can't speak for them.
Currently, I'm using a custom build ROM based on LineageOS 15.1
Click to expand...
Click to collapse
Would you mind sharing your device and kernel sources which you are using? We all have issues with audio which are related to kernel.
It would be great for development on Redmi 5A in general if you could share your sources with the community.
If you don't want to share them for any reason, you could maybe help us fixing the speaker bug on our sources: https://github.com/redmidevs/android_kernel_xiaomi_msm8917
boyrobbie said:
Can you share your own rom base on LOS 15.1? Please
Click to expand...
Click to collapse
LordShenron said:
Bro! we have been using the build you uploaded on android file host on may 16 2018. The build you uploaded has all bugs fixed in lineage OS 15.1. Some developers of Redmi 5a(RIVA) has been trying to contact you. They need the source of your ROM and kernel you uploaded on 16 may. Please reply.
Click to expand...
Click to collapse
33bca said:
Would you mind sharing your device and kernel sources which you are using? We all have issues with audio which are related to kernel.
It would be great for development on Redmi 5A in general if you could share your sources with the community.
If you don't want to share them for any reason, you could maybe help us fixing the speaker bug on our sources: https://github.com/redmidevs/android_kernel_xiaomi_msm8917
Click to expand...
Click to collapse
Here it is: lineage-15.1-20180515-UNOFFICIAL-riva.zip
Kernel source: https://github.com/xaacnz/android_kernel_xiaomi_msm8917
I tried to post this ROM on https://forum.xda-developers.com/xiaomi-redmi-5a/development , but my account don't have permission to do that, so I have to post it here in case anyone is interested.
xaacnz said:
Here it is: lineage-15.1-20180515-UNOFFICIAL-riva.zip
Kernel source: https://github.com/xaacnz/android_kernel_xiaomi_msm8917
I tried to post this ROM on https://forum.xda-developers.com/xiaomi-redmi-5a/development , but my account don't have permission to do that, so I have to post it here in case anyone is interested.
Click to expand...
Click to collapse
We have been trying to get around a bug in our builds. Your sources will be a great help for whole riva community Thank you so much.
Thanks
xaacnz said:
Here it is: lineage-15.1-20180515-UNOFFICIAL-riva.zip
Kernel source: https://github.com/xaacnz/android_kernel_xiaomi_msm8917
I tried to post this ROM on https://forum.xda-developers.com/xiaomi-redmi-5a/development , but my account don't have permission to do that, so I have to post it here in case anyone is interested.
Click to expand...
Click to collapse
Thanks again.
xaacnz said:
5 append a 4k block which begins with 0x30, 0x83, 0x19, 0x89, 0x64 to twrp-3.2.1-0-riva.img then put the resulting file to "tmp" and rename it to "recovery.img"
If you want flash custom ROM, you just need to append[NOTE1] boot.img
NOTE1: append should work in most case, but not always. the corrected place to write 0x30, 0x83, 0x19, 0x89, 0x64 is calculate from image header, it's defined as:
Code:
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned dt_size; /* device_tree in bytes */
unsigned unused; /* future expansion: should be 0 */
....
};
and then calculate:
Code:
if (hdr->page_size && (hdr->page_size != page_size)) {
page_size = hdr->page_size;
page_mask = page_size - 1;
}
kernel_actual = ROUND_TO_PAGE(hdr->kernel_size, page_mask);
ramdisk_actual = ROUND_TO_PAGE(hdr->ramdisk_size, page_mask);
second_actual = ROUND_TO_PAGE(hdr->second_size, page_mask);
dt_size = hdr->dt_size;
dt_actual = ROUND_TO_PAGE(dt_size, page_mask);
imagesize_actual = (page_size + kernel_actual + ramdisk_actual + second_actual + dt_actual);
imagesize_actual is the place to write
NOTE2: There may be a easier way to enter EDL considering there are so many bug(eg. uninitialized stack variable, buffer overrun, missing bound check) in Xiaomi's modification, but I haven't bothered to check since my goal is achieved.
NOTE3: I suspect other model from Xiaomi may have similar bugs that bootloader lock can be bypassed using this method, but I don't have other phones to confirm my belief.
Click to expand...
Click to collapse
Hello!
I am not very familliar with programming or ROM development.
Could you please explain a bit more specific about NOTE1, how to append 4K block?
I don't quite understand where should I add it. At the beginning of the image, at the end or at the specific place in that file?
And 4k block means 4 kilobytes? Like 4096 bytes?
And if I need to flash custom room should I change something in xml files to? Or just append will be sufficient?
Please help, I need to flash that Riva finally!
Basically, there has been an app ported to Android that allows even unrooted(stock) devices to deliver a bootrom exploit to the Nintendo Switch via USB-OTG and a USB cable (or C-to-C). USB 3.0 (xHCI) devices have no issues and deliver the exploit just fine. Apparently it is not even a USB 2.0 problem but rather how the EHCI performs, as certain USB 2.0 phones actually have the xHCI controller and can run the exploit just fine. What happens is that although it can detect the connected Switch in Tegra Recovery Mode, it just doesn't do anything and gives an error in the logs, "SUMBITURB failed".
On Linux desktop systems it is similar, but the exploit can still work with a kernel patch provided by a hacking group that discovered the exploit in the first place:
Code:
--- linux-4.14.27/drivers/usb/host/ehci-hcd.c.old 2018-04-17 18:00:00.000000000 +0000
+++ linux-4.14.27/drivers/usb/host/ehci-hcd.c 2018-04-17 18:00:00.000000000 +0000
@@ -873,14 +873,6 @@
INIT_LIST_HEAD (&qtd_list);
switch (usb_pipetype (urb->pipe)) {
- case PIPE_CONTROL:
- /* qh_completions() code doesn't handle all the fault cases
- * in multi-TD control transfers. Even 1KB is rare anyway.
- */
- if (urb->transfer_buffer_length > (16 * 1024))
- return -EMSGSIZE;
- /* FALLTHROUGH */
- /* case PIPE_BULK: */
default:
if (!qh_urb_transaction (ehci, urb, &qtd_list, mem_flags))
return -ENOMEM;
The author of the Android port had also written a Python "hotpatch" script for desktop Linux systems:
Code:
#!/usr/bin/env python3
import os
"""
Cursed Code.
This code literally patches your kernel memory, proceed at your own risk.
Tested on Ubuntu 17.10 and Arch, x86_64. Should work on other distros, maybe even other architectures!
Run fusee-launcher.py with the "--override-checks" argument.
If you'd rather patch your drivers properly:
https://github.com/fail0verflow/shofel2/blob/master/linux-ehci-enable-large-ctl-xfers.patch
"""
ksyms = {
line[2]: int(line[0], 16)
for line in
map(lambda l: l.strip().split(),
open("/proc/kallsyms", "r").readlines())}
print(hex(ksyms["ehci_urb_enqueue"]))
patch_c = """
#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/pgtable.h>
static u32 ORIG_MAX = 16*1024;
static u32 NEW_MAX = 0x1000000;
/* borrowed from MUSL because I'm lazy AF */
static char *fourbyte_memmem(const unsigned char *h, size_t k, const unsigned char *n)
{
uint32_t nw = n[0]<<24 | n[1]<<16 | n[2]<<8 | n[3];
uint32_t hw = h[0]<<24 | h[1]<<16 | h[2]<<8 | h[3];
for (h+=3, k-=3; k; k--, hw = hw<<8 | *++h)
if (hw == nw) return (char *)h-3;
return 0;
}
static pte_t* (*lookup_addr)(unsigned long, unsigned int*) = (void *) PLACE2;
static void set_addr_rw(unsigned long addr) {
unsigned int level;
pte_t *pte = lookup_addr(addr, &level);
set_pte_atomic(pte, pte_mkwrite(*pte));
}
int init_module(void) {
void * ehci_urb_enqueue_start = (void *) PLACEHOLDER;
u32 * patch_addr;
printk(KERN_INFO "Patch module loaded\\n");
patch_addr = (u32 *) fourbyte_memmem(ehci_urb_enqueue_start, 0x400, (void *)&ORIG_MAX);
if (patch_addr == NULL) {
printk(KERN_INFO "Failed to find patch site :(\\n");
return -1;
}
printk(KERN_INFO "patch_addr: 0x%px\\n", patch_addr);
set_addr_rw((unsigned long)patch_addr);
*patch_addr = NEW_MAX;
printk(KERN_INFO "Patching done!\\n");
return -1;
}
""".replace("PLACEHOLDER", hex(ksyms["ehci_urb_enqueue"])).replace("PLACE2", hex(ksyms["lookup_address"]))
makefile = """
obj-m += patch.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
"""
with open("patch.c", "w") as patchfile:
patchfile.write(patch_c)
with open("Makefile", "w") as mf:
mf.write(makefile)
os.system("make")
print("About to insert patch module, 'Operation not permitted' means it probably worked, check dmesg output.")
os.system("insmod patch.ko")
I tried to see if running it in Termux would do anything but I got the following error:
Code:
0x0
Traceback (most recent call last):
File "ehci_patch.py", line 70, in <module>
" " ".replace("PLACEHOLDER", hex(ksyms["ehci_urb_enqueue"])).replace("PLACE2" hex(ksyms["lookup_address"]))
KeyError: 'lookup_address'
I know that script isn't meant for use on Android anyway but maybe it can lead to a solution. The author of it does not know how to go about it at this time either, but believes an entire recompile of the kernel would be necessary. I am hoping that something like a systemless Magisk module would be the easiest solution for users but do not know if that is possible. I am only guessing it might be possible to create a Magisk module because of audio drivers like VIPER4Android. If indeed a custom kernel is needed, does anyone know how to go about it? It could be difficult to implement for everyone because not everyone has a device where the source to the kernel is available, etc. I am willing, however, to test anything on my tablet which is USB 2.0 and gives the error in the app. Any advice for how to go about this will be greatly appreciated.
I feel ya man, i need this stuff too. NXLoader doesn't work on my Galaxy Grand Prime (G530T) and i really need it to Dx