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.
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.