What I am doing is trying to build a script that can be flashed in a custom android recovery like TWRP or ClockWorkMod.
The beginning: So using this command at a ADB shell prompt will modify the partition in which the locked or unlocked flag lives for the bootloader on many HTC devices-
echo -ne '\x00\x00\x00\x00' | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
I am trying to be able to do the same thing from recovery (Aroma script, but shouldn't matter)
The issue is that while CWM recovery can use these 2 simple lines to complete it:
echo -ne "\000\000\000\000" > /tmp/data_new
dd if=/tmp/data_new of=/dev/block/mmcblk0p3 bs=1 seek=33796 conv=notrunc
TWRP environment cannot. The issue seems to be with the quotes and/or the backslashes in the echo.
To get around this I have tried to package a file called data_new with the output of the echo (which is just 4 nul bytes) and then use the DD command, but it doesn't read the data_new correctly because I get 0+0 records in and 0+0 records out. I have also tried writing a shell script to execute the commands, but same issue in TWRP.
To add a layer of complexity the commands in the aroma script are quoted like this:
run_program("/sbin/busybox", "dd", "if=/tmp/data_new", "of=/dev/block/mmcblk0p3" etc
I have tried many combinations of single and double quotes and leading backticks but still fails.
Bottom line - Is there a different way of expressing 4 zeroed out hex values?
The reverse is not a problem because it's echo to Lock is this: (no backticks and quotes on HTCU don't come into play, since echo output is the same with or without)
echo -ne "HTCU" | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
The issue is in getting a DD command to change the HTCU values to 4 zeroes without using backticks in the echo.
Can anyone help?
PS - I think that this could be done by pulling the partition with DD to /tmp and then find the HTCU string (48 54 43 55) and replace with 00 00 00 00, but the partition is large with only a small amount of data actually in it so the process would take a while and the script would be more complicated than I think I could write, as yes I am a noob to coding.
Thanks
EDIT: I tried using /dev/null as that seems like a good idea and a way to avoid echo altogether. However that fails as well. Same result as using a preloaded 4 nul byte file. I know it is not the recovery as the /dev/null method produced the same failure in a ADB shell.
0+0 records in
0+0 records out
0 bytes copied
Here is the full string of code:
run_program("/sbin/busybox", "dd", "if=/dev/null", "of=/dev/block/mmcblk0p3", "bs=1", "count=4", "seek=33796", "conv=notrunc")
After dd, what might be the best alternate way to do a quick hex edit?
This is my requirement:
writting into parttion mmcblk0p3 at offset 0x8404. HTCU for unlocked, HTCL for relocked or 0x00000000 for locked
Thanks again
Could you not read directly from /dev/null reading 4 bytes; I believe the syntax is:
dd if=/dev/null of=/dev/block/mmcblk0p3 bs=1 count=4 seek=33796 conv=notrunc
Please double check the above code, I've not used dd in a while.
Update
After playing around with dd I managed to get it to write 4 null bytes to a position I specified within a file:
Firstly create the example file:
$ dd if=/dev/urandom of=randomfile bs=64 count=1
1+0 records in
1+0 records out
64 bytes (64 B) copied, 4.5401e-05 s, 1.4 MB/s
$ od -b randomfile
0000000 105 342 131 116 213 371 352 344 217 236 320 106 010 154 074 375
0000020 360 215 014 203 030 357 144 053 302 265 012 310 217 362 236 303
0000040 156 033 266 035 303 061 262 055 253 102 222 037 372 105 230 321
0000060 117 277 322 277 166 174 316 176 010 202 302 151 120 045 120 334
0000100
Then zeroing 4 bytes, skipping the first two bytes:
$ dd if=/dev/zero of=randomfile seek=2 bs=1 count=4 conv=notrunc
4+0 records in
4+0 records out
4 bytes (4 B) copied, 4.4779e-05 s, 89.3 kB/s
$ od -b randomfile
0000000 105 342 000 000 000 000 352 344 217 236 320 106 010 154 074 375
0000020 360 215 014 203 030 357 144 053 302 265 012 310 217 362 236 303
0000040 156 033 266 035 303 061 262 055 253 102 222 037 372 105 230 321
0000060 117 277 322 277 166 174 316 176 010 202 302 151 120 045 120 334
0000100
This should extend to your larger file.
dd if=/dev/null of=/dev/block/mmcblk2p3 bs=1 count=4 seek=33796 conv=notrunc
This above Ans worked for me... Thanks for the Ans.
dd if=/dev/null of=/dev/block/mmcblk2p3 bs=1 count=4 seek=33796
without conv=notrunc argument it used to give
dd: ftruncate: Invalid argument error.
Related
adb pull many many files
win10 android7.1 microUsb
┌[seair] [⚡]
└[C:\Windows\system32]> adb shell
QK1801:/ $ exit
┌[seair] [⚡]
└[C:\Windows\system32]> adb pull /storage/emulated/0/PixivPictures/ E:\Pictures\Phone
[ 2%] /storage/emulated/0/PixivPictures/74591273_p0.jpeg: 53%
// 74591273_p0.jpeg is 20M size
when start, speed is fast. but once a file size is >=15M
it suspend and just wait, Transmission schedule not change.
I try adb pull many times, once a file size is >=15M, it suspend.
How deal with it ? ?
I don't have this problem, BUT I may have some solutions.
For a single file, the following:
adb shell cat /sdcard/chex3.wad > chex3.wad
Then, download HxD or similar hex editor, use it to open the file, and replace all hex 0D0D0A with 0A, then save. (Search -> Replace... -> Hex-values)
I've done that on two binary files, one large, and the sha256 sums came out the same as pulling them. (Also, I could open the image.)
If you want multiple files, try the following similar solution:
adb shell tar -c /sdcard/Documents > docs.tar
Do the same thing; replace all 0D0D0A with 0A as before, but then ALSO delete the following bytes, right at the beginning: 72 65 6D 6F 76 69 6E 67 20 6C 65 61 64 69 6E 67 20 27 2F 27 20 66 72 6F 6D 20 6D 65 6D 62 65 72 20 6E 61 6D 65 73 0A, which looks like text removing leading '/' from member names., but note that the final byte is a carriage return or something. The file should then start immediately with the folder you tarred up, I think, such as sdcard/Documents/. Save the file.
Now you should be able to extract the tar file with 7-Zip or whatever.
Note that since you're having problems transferring large files, it's still possible it will freeze. But it's transferring things in a different way, so it also might not.
I have the output result from "adb shell top" in a .txt file. I want to get only the CPU usage for my testing app and display it as a table:
Time cpu %
1 18
2 20
3 15
4 19
I have tried cat top.txt | grep Cpu | nl > cpu.txt (followed the instructions from here link), but the file is empty.
Do you have any idea how can I start? I have never used regex and not sure will it help. Please, looking forward hearing any tips :)
User 23%, System 5%, IOW 0%, IRQ 0%
User 434 + Nice 0 + Sys 106 + Idle 1273 + IOW 10 + IRQ 0 + SIRQ 3 = 1826
PID PR CPU% S #THR VSS RSS PCY UID Name
1868 1 20% S 50 1394620K 175176K fg u0_a174 com.test.app
1841 6 2% S 11 1897824K 48632K fg shell uiautomator
4794 1 1% S 148 2334708K 130924K fg system system_server
447 1 1% S 14 422152K 17476K fg system /system/bin/surfaceflinger
29195 1 1% S 21 369676K 20040K fg media
Given your top.txt sample, I would do the following, step by step:
First, select only the lines for your app com.test.app with grep:
grep com.test.app top.txt
Take the third field (delimited by spaces, so this is the CPU usage) by piping into awk:
grep com.test.app top.txt | awk '{ print $3; }'
Add line numbering by piping into nl (the -nln is for left justification):
grep com.test.app top.txt | awk '{ print $3; }' | nl -nln
Finally, just prepend your header with echo (-e and double quotes are needed for newline \n):
echo -e "Time cpu %\n" && grep com.test.app top.txt | awk '{ print $3; }' | nl -nln
This will give you for the sample top.txt:
Time cpu %
1 20%
I'm using shared object libraries in Android application. These shared object libraries are in .aar file.
One of library is crashing. In order to check crash logs and exact line no. I am using ndk-stack took.
Usage of ndk-stack is
$ adb logcat | ndk-stack -sym <Path to your shared libraries>
Now How can I get a path of shared libraries in AAR file?
You should keep in mind that not every .so file is useful for ndk-stack. Android NDK produces two kinds of .so files: stripped and non-stripped. The most difference is that last ones contain debug information, that is needed for ndk-stack and first ones don't. readelf may help to check if particular file is stripped or not:
$ readelf <non-stripped-lib> -S | grep debug
[23] .debug_info PROGBITS 00000000 00302c 0052d9 00 0 0 1
[24] .debug_abbrev PROGBITS 00000000 008305 000879 00 0 0 1
[25] .debug_loc PROGBITS 00000000 008b7e 001aa7 00 0 0 1
[26] .debug_aranges PROGBITS 00000000 00a628 000088 00 0 0 8
[27] .debug_ranges PROGBITS 00000000 00a6b0 0000d0 00 0 0 1
[28] .debug_line PROGBITS 00000000 00a780 0009de 00 0 0 1
[29] .debug_str PROGBITS 00000000 00b15e 002387 01 MS 0 0 1
[30] .debug_frame PROGBITS 00000000 00d4e8 0003d0 00 0 0 4
$
$ readelf <stripped-lib> -S | grep debug
$
As you see not-stripped ELF has a lot of .debug_* sections, that indeed contain line numbers, private / static function names, etc.
Next, .aar files, both debug and release ones, has only stripped binaries. So they are useless for ndk-stack.
AFAIK, the only place where non-stripped binaries may be found is a obj/ dir. Its location depends slightly on used build system:
for ndk-build it is under <module_name>/build/intermediates/ndk
for CMake-based it is under <module_name>/build/intermediates/cmake
Also it looks like out-of-the-box android gradle plugin offers no way to pack unstripped libraries to your aar, so the only way here is some custom task in your build.gradle.
when I try to unzip a encrypted obb file using the jobb tool jumps me the following error:
jobb -dump /temp/obb-output/ -o my-app-assets.obb -k secret-key
Package Name: com.example.sample
Package Version: 1
SALT: -63dddd10f3a63bb
29eb26a5c9227f6efeab677fc53a7348
[LFN = video.avi / SFN = ShortName [/> ifl -- 5 2f 1d 10 3 3e c 1d 69 66 6c ]]
Alignment off reading from sector: 2433
Partial read from sector: 2433
Exception in thread "main" java.nio.BufferOverflowException
at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:183)
at java.nio.ByteBuffer.put(ByteBuffer.java:832)
at com.android.jobb.EncryptedBlockFile$EncryptedBlockFileChannel.readDecryptedSector(EncryptedBlockFile.java:292)
at com.android.jobb.EncryptedBlockFile$EncryptedBlockFileChannel.read(EncryptedBlockFile.java:142)
at de.waldheinz.fs.util.FileDisk.read(FileDisk.java:118)
at de.waldheinz.fs.fat.ClusterChain.readData(ClusterChain.java:214)
at de.waldheinz.fs.fat.FatFile.read(FatFile.java:126)
at com.android.jobb.Main.dumpDirectory(Main.java:137)
at com.android.jobb.Main.dumpDirectory(Main.java:112)
at com.android.jobb.Main.main(Main.java:315)
Can anyone help me?
It is to do with expansion file version numbers. I just needed to increment versionCode in my manifest and in the obb file. Android doesn't seem to like you updating with a new obb file with the same version number, Hope it helps.
I have a multi-threaded application(C++,C and pthread library) and I will like to know how much resources(CPU and memory) each thread uses. Is there a way to find out these details on Android?
I have tried
$ adb shell ps -p -t
But, this gives information in the below format,
USER PID PPID VSIZE RSS PRIO NICE RTPRI SCHED WCHAN PC NAME
root 1 0 476 312 20 0 0 0 c037c0e0 000087bc S /init
root 2 0 0 0 20 0 0 0 c031f114 00000000 S kthreadd
root 3 2 0 0 20 0 0 0 c030e5d0 00000000 S ksoftirqd/0
root 4 2 0 0 -100 0 99 1 c033fc50 00000000 S watchdog/0
root 5 2 0 0 20 0 0 0 c031b4b4 00000000 S events/0
root 6 2 0 0 20 0 0 0 c031b4b4 00000000 S khelper
Any way to know which threads are running along with their parent's id will be really helpful.
using
$ adb logcat -v threadtime
prints info about the running process (PID) and the thread (TID).
But, its not enough for my purpose. I want to know how much resources is a particular thread consuming. Any pointers.
ps command in android seems to be very limited compared to linux.
You could try:
ps -t -c APP_NAME
This will show you threads(-t) and the CPU assigned to the thread (-c)
Example:
ps -t -c -p com.whatsapp
-p is thread priority(linux nice value)