mateor / auto-patcher

smali patcher for Android code injection
MIT License
74 stars 42 forks source link

PDroid patch fails on CM7 #250

Closed joeblow789 closed 10 years ago

joeblow789 commented 10 years ago

Auto-Patcher v3.6.7 says it successfully creates original (syat) PDroid patches for CM7, but the original (syat) PDroid app reports the patch isn't installed. I also tried Auto-Patcher 2.5.0 without success. There's a few similar reports in the XDA thread. I saw your past troubles with CM7, but the changelog suggests you got it working at least in v2.4.6. Of course, syat's original patcher does produce working patches.

Honestly, the only reason I'm trying to use Auto-Patcher is because FFU5y says in the 1st post of the OpenPDroid thread (January 2013): "...Two major security issues are fixed, which allow apps to bypass many or all PDroid or PDroid 2.0 settings. (We are in the process of notifying CollegeDev of these issues, and sample code will not be released for at least a week to give him a chance to fix the problems in PDroid 2.0. Fixes have been added to PDroid in auto-patcher, so if you are using PDroid please consider re-patching your ROM)..." http://forum.xda-developers.com/showthread.php?p=36678558#post36678558 Is that inaccurate? Thanks!

CM7 ROMs in question are available below: https://www.copy.com/s/MJF3SBySoJvj or http://download.cyanogenmod.org/?device=droid2

Successful patch log is here -for what it's worth ;) : http://pastebin.com/FxbtVj9A

mateor commented 10 years ago

Allow me to take a look at the CM7 stuff...we changed a bunch of stuff as of 3.0 and 3.1. But the fact that the Auto-patcher 2.5 isn't working is a bit troublesome...I have had reports of people using this on Cm7 more recently than that...I did get it working sometime around 2.4.6, but I will need to look.

But as for the note from FFU5y, backporting those fixes to Pdroid turned out to break the roms...they were indeed useful fixes, but they addressed a very unlikely attack vector. At that point in OpenPdroid/PDroid?PDroid2.0's development, it wasn't out of the realm of possibility that an attacker would fashion something specifically to circumvent our protection. I do not consider that likely anymore, we are a minor concern and of no importance to malware purveyors.

So consider those bugfixes to be irrelevant. I would. But I will take a look at the PDroid patches. Last I heard they were working, but I haven't personally looked at them in a long time.

mateor commented 10 years ago

Okay, sorry for the confusion. I cleaned up a number of things that would have caused problems and now you can go ahead and use the auto-patcher. I have tested everything short of flashing the new update zips, because I do not have a CM7 capable device.

But the problem was that the autopatcher was simply decompiling and recompiling without actually applying the patches. That was because, at some point way back there, I had established that each mod requested (pdroid, v6supercharger, tabletUI etc) would go through a "build_query" function, which matches the build date of the rom with the existing patches and matches the best date. It parses the UTC in the build date. CM7 doesn't have a UTC, so I had set it to use the latest patches. But as the build_query got more and more sophisticated, the 2.3 roms got left behind and some needed variables were never set for those roms.

If I had my stuff together enough to have built an even moderate test suite, this would have been caught. Oh well.

Should be okay now, thanks for reporting the issue.

joeblow789 commented 10 years ago

Mateor, huge thanks for the quick response & the clarification of FFU5y's comment. Unfortunately, I'm not able to even generate a PDroid patch now with Auto-Patcher 3.7, lots of permission denied errors. This is on XPproSP3 through ApG 2.6.0.2 & manually through cygwin. Maybe I'm just using a path cygwin doesn't like? I uploaded both the ApG & AP logs here as there seems to be some difference between the two: http://pastebin.com/FK6EKmy8 http://pastebin.com/0knEPNp0

Honestly, since all I'm interested in is PDroid and I still have syat's patcher available, if you don't want to spend the time trying to get this working, that's OK with me. But, if you're game, I'll be happy to test it out.

Edit: Oh and yes, I'm running as admin. ;)

mateor commented 10 years ago

Well, this is a change on your end I think? I changed almost nothing in the script...here is my diff between your two runs: (code block is not working? hopefully clear enough. The only non-whitespace changes are the MODS_LIST and PATCH_DATE_LIST explicit assignment for 2.3)

        # pass variables to children
        @@ -1139,7 +1140,9 @@ else
               case $ANDR in
               2.3)
                    # CM7 roms do not have UTC time stamp- so no build query.
        -           BID=latest;
        +          BID=latest
        +          MODS_LIST=${PID[@]}
        +          PATCH_DATE_LIST=$BID
                    echo "*** CM7 roms default to latest patches. If using  an older rom ***"
                    echo "*** specify patch date on command line. Use -h to  see available patches ***"
                    ;;
         @@ -1912,9 +1915,8 @@ for ((i=0; i < ${#PID[@]}; i++)); do
                    printtask "... deleting $FILE ..."
                    \rm -rf ./$FILE
               done
         -     [[ -n ${JARS[@]} ]] && printtask "### jar patch $P/$A ###"
         -

         +     [[ -n ${JARS[@]} ]] && printtask "### jar patch $P/$A ###"
               # Iterate through jars and patch. If fails, try other  patches and prepatched provisionals.
               for (( current_jar=0; current_jar < ${#JARS[@]}; current_jar++)); do
                    FILE=${JARS[$current_jar]}

I generally see this with cygwin when someone is trying to use it on an NTFS or networked partition. Also, sometimes with ApG (if you are using it) it doesn't treat it very gently and sometimes needs to be deleted and reinstalled (just the auto-patcher directory). It is hard for me to debug, as I don't have a Windows box and wasn't the one who added cygwin support.

The long and the short of it is that generally, some combination of deleting the autopatcher directory and using it on a fat32 partition is what fixes your problem. But if svyat's patcher is working for you still, then I wouldn't worry about it. The Auto-patcher is technically a better solution, but that is only because it works on all open-source roms, whereas svyat's patcher fails for some. But since it works for you, you should be set. I am confident that the problems you reported were fixed in my update, so any using it in the future can thank you for bringing it to my attention.

Thanks!

joeblow789 commented 10 years ago

Just to follow up, per your suggestion, I started fresh from a fat32 usb drive & produced a successful syat flavored PDroid patch for CM7 using ApG. One question though, Auto-Patcher's patched core.jar, framework.jar, & services.jar are smaller than those created by syat's patcher, but seem to work fine. I guess y'all are just more refined & efficient? Patches are here if you want to look at them: http://d-h.st/W7J http://d-h.st/9No (The originating ROM is one I originally linked to with the Master Key patched core.jar copied in from that same link.) Regardless thanks for indulging me & for making such a fantastic tool!

mateor commented 10 years ago

I am glad it worked! The size is just a matter of the recompilation, it is usual when decompiling, recompiling. We use m=way more advanced smali binaries at this point. You might could just drop the newer ones in svyat's, although I dont know if he ever set the API flag.

Glad it is working, I appreciated the heads up it was broken.