I appreciate the time you are taking to read this. I searched a lot, but could not find an answer to my problem.
I am trying to implement a recent patch to bidi text rendering that was created for CM rom and runs on Nexus 1. I downloaded the vanilla source code to 2.1, and compiled it with and without the patch. Then I disassembled framework.jar and compared the smali files, to discover that the following ones were modified:
android/graphics/Canvas.smali
android/graphics/Canvas$EdgeType.smali
android/graphics/Canvas$VertexMode.smali
android/text/Layout.smali
android/text/SpannableStringBuilder.smali
android/text/Styled.smali
android/widget/TextView$CharWrapper.smali
My idea was that if I run baksmali on the framework.jar file from my Desire, replace these files with the new ones, run smali on the result, repack it as framework.jar and upload it to the device - the fix will be implemented.
This actually worked very well for a previous fix, which involved only the file StaticLayout.smali. It worked without having to sign framework.jar; however, that fix did not change the file size, whereas the current one does change it - especially for Canvas.smali. I did not try to sign framework.jar - I don't really know how to and if it is necessary.
The result was a bootloop. Logcat showed that the device is unable to load a native library:
Code:
D/AndroidRuntime( 103): --- registering native functions ---
W/dalvikvm( 103): Unable to register: not native: Landroid/graphics/Canvas;.drawText (Ljava/lang/String;FFLandroid/graphics/Paint;)V
E/JNIHelp ( 103): RegisterNatives failed for 'android/graphics/Canvas'
E/AndroidRuntime( 103): Unable to register all android natives
This is where I am stuck. What I really wanted to do was to create a script-based fix that would work on any device running 2.1. It was possible for the StaticLayout fix. Now I'll settle for figuring out how to make it work for the Desire.
I am attaching Canvas.smali, the file I think is responsible for the problem, in 2 forms: vanilla is compiled from source with no modification, patched is compiled from source after the patch. It seems that the other Canvas files were unchanged by the modification.
Thank you very much in advance!
I am a fool - you would need, of course, the smali file that actually works on the device. Attached here.
ClassicalDude said:
I am a fool - you would need, of course, the smali file that actually works on the device. Attached here.
Click to expand...
Click to collapse
this is a bit off topic but how to change in .jar file? thanks
jullejul said:
this is a bit off topic but how to change in .jar file? thanks
Click to expand...
Click to collapse
http://www.villainrom.co.uk/viewtopic.php?f=61&t=921&start=0
this will teach you how to patch a jar file..
hi thanxxxx
Related
Apologize for possible OT, but I can't find an always working (and stable) SSH daemon app for the Zenfone2's Lollipop
This is what I tried, any of them PAID apps:
QuickSSHd - too old, not even starts
SSHDroid Pro - sometime starts, only first time after reboot, but only without root and higher ports (>1024)
RRooted SSH/SFTP Daemon - always refusing connections
Ssh Server Pro (olive tree) - seems promising, but very poor of binaries
The Dropbear service hanging issue seems the root of this problem
Thanks for any hint
I can't even find a proper ssh binary. I just tried sshd from an x86 cyanogen port (RAZRi, I think). Got this after loading appropriate library in lib (same as client)
1|[email protected]:/ # sshd
CANNOT LINK EXECUTABLE: could not load library "libssh.so" needed by "sshd"; caused by cannot locate symbol "EVP_ripemd160" referenced by "libssh.so"...
Good luck sir
Blades said:
I can't even find a proper ssh binary. I just tried sshd from an x86 cyanogen port (RAZRi, I think). Got this after loading appropriate library in lib (same as client)
1|[email protected]:/ # sshd
CANNOT LINK EXECUTABLE: could not load library "libssh.so" needed by "sshd"; caused by cannot locate symbol "EVP_ripemd160" referenced by "libssh.so"...
Good luck sir
Click to expand...
Click to collapse
Hi,
I followed the following guide which you can get from googling "Compiling-Dropbear-for-a-Nexus-7-tablet". Sorry, I can't post any links yet as my post counts are still below 10
The difference with the info from the website above is that we don't need to cross compile if you're compiling in a Linux x86-64 system. Just need to make a static binary.
Let me know if you have any questions and I'll try to help out.
Cheers.
wolfdude said:
The difference with the info from the website above is that we don't need to cross compile if you're compiling in a Linux x86-64 system. Just need to make a static binary.
Let me know if you have any questions and I'll try to help out.
Click to expand...
Click to collapse
Thanks for your answer.
Sorry but I can't get the exact entry-point, bypassing all the NDK / X-compiling stuff, as we're on a x86_64 architecture
Referring to the "simplified" version of your link (here: https://nerdoftheherd.com/articles/cross-compiling-dropbear-rsync-android/ ),
how should I compile the Dropbear source ?
Something like this ?
Code:
./configure \
--disable-zlib --disable-largefile --disable-loginfunc --disable-shadow --disable-utmp --disable-utmpx --disable-wtmp \
--disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog \
CFLAGS='-Os -W -Wall -fPIE' LDFLAGS='[COLOR="Red"]-static[/COLOR] -fPIE -pie'
... right before make-ing ?
Thanks for any further hint in the right direction
Hi,
I didn't refer to that site you have posted BUT that site does have a link at the bottom to the site where I followed.
From that site, what I did was :-
1) Download dropbear v58 (dropbear-2013.58.tar.bz2). I know this is older but the patch available is based on this version.
2) Download patch (dropbear-patch2) from that site.
3) Apply patch to the original dropbear (v58) source.
4) Run configure :-
./configure --disable-zlib --disable-largefile --disable-loginfunc \
--disable-shadow --disable-utmp --disable-utmpx --disable-wtmp \
--disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog
5) Run make :-
STATIC=1 MULTI=1 SCPPROGRESS=0 PROGRAMS="dropbear dropbearkey scp dbclient" make strip
6) You should end up with "dropbearmulti" which is a static binary that you can then copy over the the phone & go on from there.
There are some issues with that version of the code (v58+patch). Namely the "scp" doesn't work (but I have found the offending code in scp.c and found a workaround).
Let me know if you need more details. If I have some time, I might look at getting the latest dropbear version & working out a patch for it to get it to work on android x86.
Cheers.
wolfdude said:
Hi,
I didn't refer to that site you have posted BUT that site does have a link at the bottom to the site where I followed.
[...]
There are some issues with that version of the code (v58+patch). Namely the "scp" doesn't work (but I have found the offending code in scp.c and found a workaround).
Let me know if you need more details. If I have some time, I might look at getting the latest dropbear version & working out a patch for it to get it to work on android x86.
Cheers.
Click to expand...
Click to collapse
Yes of course. The main link you weren't able to post is:
http://blog.xulforum.org/index.php?post/2013/12/19/Compiling-Dropbear-for-a-Nexus-7-tablet
Actually that procedure seemed too complex as mostly dealing with the cross-compiling issue, which didn't apply to x86 case.
So I named the derivative one
Thanks for pointing out the static compiling is done within MAKE and not CONFIGURE phase... I'm quite newbie in those flags so I do appreciate any of your words
About issues, what about using the latest v67 for Dropbear sources ? (see here)
If the patch doesn't work for such different version, I guessed commenting out the interactive password line would be enough
I'm trying to compile it this way and - for instance - replace the binaries in one of the SSHD packages I named in the OP...
Thank you again for your time
Val3r10 said:
About issues, what about using the latest v67 for Dropbear sources ? (see here)
If the patch doesn't work for such different version, I guessed commenting out the interactive password line would be enough
I'm trying to compile it this way and - for instance - replace the binaries in one of the SSHD packages I named in the OP...
Thank you again for your time
Click to expand...
Click to collapse
Hi,
Yes, the patch for v58 does not work for v67. I think one just have to go through the patch and "adjust" it slightly for the newer v67. Hopefully there isn't much changes from v58 to v67. There may be more than just commenting out the password prompt as there are certain functions that don't work in Android as in *NIX. When I have some time, I will attempt to patch v67 meanwhile, I'm running v58 fine on my ZE550ML so no complains there.
Cheers.
Hi,
I've created a guide on compiling the latest dropbear (2015.67) :-
http://forum.xda-developers.com/zenfone2/general/compiling-dropbear-2015-67-zenfone-2-t3142222
Hope it helps.
Cheers.
wolfdude said:
I've created a guide on compiling the latest dropbear (2015.67)
Click to expand...
Click to collapse
Thanks a lot.
Do you think the same process (STATIC build, of course, not patching) could be likely used for other small binaries too ?
Val3r10 said:
Thanks a lot.
Do you think the same process (STATIC build, of course, not patching) could be likely used for other small binaries too ?
Click to expand...
Click to collapse
Of course. I've managed to compile tcpdump, iperf, gdbserver, etc... successfully and working fine on the Zenfone 2.
Cheers.
I found that "Servers Ultimate" SSH/SFTP modules work on the Zenfone2 once properly configured. Its not working 100% but its already more then most solutions out there.
I've observed that some modules source code have system package specific imports
example:
Code:
import com.android.systemui.statusbar.BaseStatusBar;
import com.android.systemui.statusbar.NotificationData;
import com.android.systemui.statusbar.NotificationData.Entry;
I've picked this code from serajr blurred systemui module.
I'm using android studio but even in eclipse I cant import them
but I've tried lots of methods but I coudn't find a way for importing it, it says that it's not there, can someone help me please?
thank you
Depends on the SDK version you're targeting.
If I recall correctly before Lollipop (or maybe KitKat?) you could simply import system classes by adding private Andoid libraries to classpath in your IDE.
But for never Androids you need to move all your Class loading to handleLoadPackage in the module because of ClassLoader changes, or else your module isn't gonna work even if it compiles right.
XspeedPL said:
Depends on the SDK version you're targeting.
If I recall correctly before Lollipop (or maybe KitKat?) you could simply import system classes by adding private Andoid libraries to classpath in your IDE.
But for never Androids you need to move all your Class loading to handleLoadPackage in the module because of ClassLoader changes, or else your module isn't gonna work even if it compiles right.
Click to expand...
Click to collapse
I solved it by adding the hidden libs and decompiling systemui, picking the dex file, converting it to jar and adding provide dependency on android studio, but thanks anyway
Xiaomi Poco F1 [ROM] [8.1.0] ResurrectionRemix v6.2.1
I installed xposed v90beta3, I can not start the module, it gives an error.
Help solve the problem
zygote64(3278): ClassLoaderContext size mismatch. expected=1, actual=2 (PCL[] | PCL[];PCL[/data/dalvik-cache/xposed_XResourcesSuperClass.dex*2802528989:/data/dalvik-cache/xposed_XTypedArraySuperClass.dex*708326108])
I am new to Xposed development. I figured out that we can override most methods in android. And from a famous tutorial I found out a way to change the clock to a smiley. Now, that android source code was different and My device's source code is different. I have a sony xperia z5. How do I reasearch my z5's 6.0.1 java code so that i can come up with a new xposed module??? Like where do I find my device's source code?
Please helpp......
thetitanium said:
I am new to Xposed development. I figured out that we can override most methods in android. And from a famous tutorial I found out a way to change the clock to a smiley. Now, that android source code was different and My device's source code is different. I have a sony xperia z5. How do I reasearch my z5's 6.0.1 java code so that i can come up with a new xposed module??? Like where do I find my device's source code?
Please helpp......
Click to expand...
Click to collapse
If OEM of your device does not provide source code repositories, the only way is to use apktool to decompile existing system components (e.g. SystemUI.apk for status bar). You'll get decompiled source in smali format which is quite hard to read and makes reverse engineering complicated. There are also tools which can convert smali to better looking representation which is close to java code but you still won't get the exact source code from which system was built. But it should give you basic info where your hooks have to be applied. In the past, I tried using Virtuous Ten Studio which is an all-in-one tool for reverse engineering but it was a long time ago thus not sure what the current state of the project is.
C3C076 said:
If OEM of your device does not provide source code repositories, the only way is to use apktool to decompile existing system components (e.g. SystemUI.apk for status bar). You'll get decompiled source in smali format which is quite hard to read and makes reverse engineering complicated. There are also tools which can convert smali to better looking representation which is close to java code but you still won't get the exact source code from which system was built. But it should give you basic info where your hooks have to be applied. In the past, I tried using Virtuous Ten Studio which is an all-in-one tool for reverse engineering but it was a long time ago thus not sure what the current state of the project is.
Click to expand...
Click to collapse
Thanks a lot! Ya I decompiled the apks and found some pointers that helped me a lot. Ya, sony provides developer sources but I was unable to convert the code into readable format... Can you help me with that?
Here is the link.... https://developer.sonymobile.com/do...rchives/open-source-archive-for-44-1-a-0-169/
thetitanium said:
Thanks a lot! Ya I decompiled the apks and found some pointers that helped me a lot. Ya, sony provides developer sources but I was unable to convert the code into readable format... Can you help me with that?
Here is the link.... https://developer.sonymobile.com/do...rchives/open-source-archive-for-44-1-a-0-169/
Click to expand...
Click to collapse
I'm not sure what that package contains since I did not download it due to its size but it's a packed image. You have to unzip and untar to get to the files.
Got it! Thanks anyways @C3C3C076. All I had to do was pull boot.oat and then use oat2dex. This gave me several dex files, and then there was this beautiful framework.dex and framework-classes.dex. The two things I needed to do look into.
Hello decompilers
I am a long-time hobby VTS user. Since "stock" VTS is quite outdated, I have updated the included binaries to support decompiling of newer apks. Base version is the latest available, 3.6.30.14100.
updated binaries:
apk tool
smali and baksmali
procyon java decompiler
adb
dex2jar
since apktool has changed commandline arguments, I had to modify VTS itself (ToolWrapper.dll). Therefore this version only works with newer versions of apktool
If you have trouble opening it, you will probably have to bypass signature checking (will help on request, as I don't remember how to do it)
Full updated VTS: (106.5 MB)
https://mega.nz/file/m4oAGYbC#GfD-xo9bHMgWUXCncJg_YegfFzJK-KTTcBiGXamuUok
Update patch: (51.2 MB)
https://mega.nz/file/Lt4SjIiT#IcGkqT259M95DbpVIhShR-nTSvZuWvOkMm-cF7SLQpc
Thanks for the modification, really sad to see it not getting updates anymore :/
For some reasons though, when I try to create a new project, I cant press on "finish", no matter which configuration I choose.
I set the Java-path in the settings, I also added a framework and tried to replace the apktool and smali jars you provided with freshly downloaded ones, but this did not seem to work.
I also dont get any error in the logs, so Im pretty much out of ideas. Is this error know to you or do you have asolution?
trogper said:
Hello decompilers
I am a long-time hobby VTS user. Since "stock" VTS is quite outdated, I have updated the included binaries to support decompiling of newer apks. Base version is the latest available, 3.6.30.14100.
updated binaries:
apk tool
smali and baksmali
procyon java decompiler
adb
dex2jar
since apktool has changed commandline arguments, I had to modify VTS itself (ToolWrapper.dll). Therefore this version only works with newer versions of apktool
If you have trouble opening it, you will probably have to bypass signature checking (will help on request, as I don't remember how to do it)
Full updated VTS: (106.5 MB)
https://mega.nz/file/m4oAGYbC#GfD-xo9bHMgWUXCncJg_YegfFzJK-KTTcBiGXamuUok
Update patch: (51.2 MB)
https://mega.nz/file/Lt4SjIiT#IcGkqT259M95DbpVIhShR-nTSvZuWvOkMm-cF7SLQpc
Click to expand...
Click to collapse
Thanks for this update
But there is a problem that I hope you will solve.
The problem is that when decompiling the apk, the program only decompiling the main classes.dex.. but classes2.dex and classes3.dex do not unpack it.
Dark_Lion64 said:
Thanks for the modification, really sad to see it not getting updates anymore :/
For some reasons though, when I try to create a new project, I cant press on "finish", no matter which configuration I choose.
I set the Java-path in the settings, I also added a framework and tried to replace the apktool and smali jars you provided with freshly downloaded ones, but this did not seem to work.
I also dont get any error in the logs, so Im pretty much out of ideas. Is this error know to you or do you have asolution?
Click to expand...
Click to collapse
In the import wizard, there is one step where you set path where to save the project. There are 4 input fields (project name, solution name, something, path). You have to fill them all. I have spent some time on this issue too...
abo2sadam said:
Thanks for this update
But there is a problem that I hope you will solve.
The problem is that when decompiling the apk, the program only decompiling the main classes.dex.. but classes2.dex and classes3.dex do not unpack it.
Click to expand...
Click to collapse
Sorry, I don't use VTS anymore. I have found a replacement, APK Lab for visual studio code.
Hello folks,
I am a beginner. Sorry if it's a stupid question.
I want to include a file when compiling a custom rom with Lineage OS. It should be under "/sys/module/dwc3/parameters", named "aca_enable" and contain a "Y".
How can I build this into the sources so that it is already there after flashing?
I've already searched the web, but couldn't find anything.
Thanks for replies in advance!
This is not a normal file. Kernel modules expose flags under /sys/module/<module-name> which can be changed by file operations. Pretty common under linux to have such interfaces (e.g. procfs).
I can't give you a complete answer, but can probably point you in the right direction: You need to do some research on init.rc. Basically you need to set a rule in an .rc file in /system/etc/init. (Or compile a new kernel / the dwc3 module and set a new default value)
sn00x said:
This is not a normal file. Kernel modules expose flags under /sys/module/<module-name> which can be changed by file operations. Pretty common under linux to have such interfaces (e.g. procfs).
I can't give you a complete answer, but can probably point you in the right direction: You need to do some research on init.rc. Basically you need to set a rule in an .rc file in /system/etc/init. (Or compile a new kernel / the dwc3 module and set a new default value)
Click to expand...
Click to collapse
Hello, many thank you for the answer!
Yes I understand. These files are created and modified at runtime. Then I know where to look. An example would be best. "Copy and Paste" is a popular method. ;-)
First try - quick and dirty - did not work.
I put the following lines into the system/core/rootdir/init.usb.rc (lineageos sources):
# Set /sys/module/dwc3/parameters/aca_enable to "Y"
write /sys/module/dwc3/parameters/aca_enable Y
After compiling the ROM, flashing it on the device and boot the device the file /sys/module/dwc3/parameters/aca_enable contain a "N".
On the Spartphone the file /etc/init/hw/init.usb.rc contains the modified lines.
In the modified file dwc3_otg.c i can't find anything that write a "N".
Maybe someone has an idea or an alternative?
(Here is the source code of dwc3_otg.c https://github.com/sollapse/opo_dwc3_otg/)
Well, just change 0 to 1 in line 42.
sn00x said:
Well, just change 0 to 1 in line 42.
Click to expand...
Click to collapse
Hello, oh yes - I had tomatoes on my eyes. Thank you very much for the tip!
sn00x said:
Well, just change 0 to 1 in line 42.
Click to expand...
Click to collapse
It works!
Thank you so much for making the effort.
fyi: Another option would be here.