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.
Related
I'm running an android app (custom) that scans for nearby Bluetooth low energy devices, and I am noticing that some devices have longer advertised packets than specifications provision for. The scanning device is a Nexus 5 running Android 6.0.
I am using the following line on a ScanResult object result.getScanRecord().getBytes(); to get the byte array
I know that the ScanRecord's byte array is actually constructed of the advertised data (mac address not included) and the scan response, so I expect 31 bytes each for a total of 62 bytes in the array. This is the size of the total array that I receive, but it looks like the advertised data makes it into the response portion of the array. The format follows the specification, where the first byte of a GAP is the length, next byte is GAP type, and next length-1 bytes is data.
But with this format, the devices in question have data fields that extend over into the response portion. Here's an example of the array in hex, with each GAP on a different line:
02 01 06 (flags)
0D FF DF 00 57 30 46 30 30 33 43 45 56 5A (manufacturer specific data)
11 07 6D 69 73 66 69 74 A6 34 4A 7D 7F 95 01(<-expected end of advertise) 00 DA 3D (UUID, 128-bit)
07 09 46 6F 73 73 69 6C (device name)
03 03 12 18 (UUID, 16-bit)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (leftover bytes)
I don't really care about the scan response data, but I am confused as to how a BLE device could send advertisement packets larger than 31 bytes if it is on 4.2 specification (I know Bluetooth 5 allows larger packets, but the manufacturer states it uses 4.2). I can also see the name of the device showing as it should, but in the response portion.
Would anyone know why this is the case here? Thanks.
Probably those devices simply don't follow the specification (which requires an entry not to cross the packet boundaries). So your device might send
02 01 06 0D FF DF 00 57 30 46 30 30 33 43 45 56 5A 11 07 6D 69 73 66 69 74 A6 34 4A 7D 7F 95
as the Advertising Data and
01 00 DA 3D 07 09 46 6F 73 73 69 6C 03 03 12 18
as the Scan Response Data. You can see for example in the HCI log if this is correct. If it is so, you should complain to the manufacturer of that BLE device.
I have an audio recording app on android, and I've encountered a strange issue on a friend's phone.
One of the recordings did not work and throws:
E/MediaPlayer-JNI(5996): QCMediaPlayer mediaplayer NOT present
E/MediaPlayer(5996): Unable to create media player
E/com.audioRec.player.MediaPlayer(5996): setDataSourceFD failed.: status=0x80000000
E/com.audioRec.player.MediaPlayer(5996): java.io.IOException: setDataSourceFD failed.: status=0x80000000
but it is playing with success on windows media player, vlc player, etc !!!!!!!!!
Could someone take a look over the header of the "RecordingNotOk.wav" file?
Here are both recordings
For the RecordingNotOk.wav file, it sounds like the specified size of the data chunk is bigger than the file size:
00 F8 0A 00 in little endian is 718848 bytes while the whole file size is only 716844 and the actual data size available for this chunk is only 716800
This number can be found here (3rd line after 'data'):
52 49 46 46 24 F0 0A 00 57 41 56 45 66 6D 74 20 RIFF $ð?? WAVE fmt
10 00 00 00 01 00 02 00 80 3E 00 00 00 FA 00 00 ???? ???? >?? ?ú??
04 00 10 00 64 61 74 61 00 F8 0A 00 00 00 00 00 ???? data ?ø?? ????
Basically it seems that your file has been truncated. Some players might ignore this and try to play whatever is available up to the end of the file. I guess on Android it tries to read the whole file first according to the expected size hence the IOException
I tried create an OBB file and then, dump this file to see all works fine.
I have a folder called "HOLA" in C:\Users\abreu20011\Desktop\HOLA with the next distribution:
HOLA
\_>hola.txt (i wrote "hello world" inside)
\_>emulator-arm.exe
\_>emulator-mips.exe
\_>emulator-x86.exe
I put emulators file, because when I trying to compress with the text file only, I received the next error when I write the sentence:
jobb -pn es.test.test -pv 1 -d C:\Users\abreu20011\Desktop\HOLA -o hola.obb
Slop:0 Directory Overhead: 0
Slop:289 Directory Overhead: 224
java.io.IOException: no data clusters
at de.waldheinz.fs.fat.Fat.<init>(Fat.java:129)
at de.waldheinz.fs.fat.Fat.create(Fat.java:96)
at de.waldheinz.fs.fat.Fat.SuperFloppyFormatter.format(SuperFloppyFormatter.java:236)
at com.android.jobb.Main.main(Main.java:414)
So, I fattened the directory with this emulators, and the jobb tool worked fine:
Slop:0 Directory Overhead: 0
Slop:2453 Directory Overhead: 608
But the real problems arise when I try to dump the obb file. Since the jobb tool creates the obb file in the same directory of the tool, I wrote the dump sentence:
jobb -dump hola.obb -d C:\Users\abreu20011\Desktop
The program extracts a partial file of emulator-arm.exe and wrote the next error:
Package Name: es.test.test
Package Version: 1
LFN = emulator-arm.exe / SFN = ShortName [/☺[←►▬←☺ifl -- 2f 1 5b 1b 10 16 1b 1 6 9 66 6c ]
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2335
at de.waldheinz.fs.fat.ClusterChain.readData(ClusterChain.java:225)
at de.waldheinz.fs.fat.FatFile.read(FatFile.java:126)
at com.android.jobb.Main.dumpDirectory(Main.java:137)
at com.android.jobb.Main.main(Main.java:315)
Why I can't create an obb file of his size is smaller?
and why I can't dump the original file?
Thanks for your help and for your time! :)
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.
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.