yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], maybe have a look at fota-ua from p10.107 fw - the sub_41F5EC seems to check compression type having "Faulty compression %d\n" error log inside.

Function at 0x401708 maps fota update package block ranges into memory into a continuous memory address range (implemented by sub function at 0x401C04) - mmap syscall is at 0x0578A18.

Please find a strace from the first phase of fota-ua run in PM - it does verification and updates only fotakernel in order to reboot into it for the main update phase. The advantage is that this strace is only 11MB in size, but reads the update package, extracts fotakernel update data and patches fotakernel partition to update it. It is certainly easier to grep than the big 630MB strace file doing the full update.

From this strace you can see the fota update block ranges are mapped into memory:

03-main-p10.107-0x77665502-UAS-none/recovery/block.map
/dev/block/bootdevice/by-name/userdata
420897111 4096
2
5312512 5343232
5345280 5417319

i.e. 5312512 * 4096 = 0x511000000,

5345280 * 4096 = 0x519000000

$ grep 'userdata\|mmap' 03-main-p10.107-0x77665502-UAS-none/fota-strace/fota-ua.902
openat(AT_FDCWD, "/dev/block/bootdevice/by-name/userdata", O_RDONLY) = 4
mmap(0x71ca776000, 125829120, PROT_READ, MAP_PRIVATE|MAP_FIXED, 4, 0x511000000) = 0x71ca776000
mmap(0x71d1f76000, 295071744, PROT_READ, MAP_PRIVATE|MAP_FIXED, 4, 0x519000000) = 0x71d1f76000

The function at 0x417098 is ua_package_read(), it calls the above mentioned memory mapping of block ranges, effectively getting the whole fota package into memory (i.e. package read). The function calling it (sub_403184) is higher level handling metadata and update states. It gets the package context structure pointer into

__int64 v442; // [xsp+130h] [xbp-720h]

it's stack variable. That structure contains also a pointer to the whole update package mapped into memory.

Following the context and the pointer to the mapping may possibly reveal some decompression or decryption routines.

In the strace, you can see following:

$ grep 'ANDROID!' fota-ua.902
read(8, "ANDROID!\35\254\363\0\0\200\0\0002Q\263\0\0\0\0\1\0\0\0\0\0\0\360\0"..., 2048) = 2048
write(9, "ANDROID!\35\254\363\0\0\200\0\0002Q\263\0\0\0\0\1\0\0\0\0\0\0\360\0"..., 2048) = 2048
write(9, "ANDROID!\346\257\363\0\0\200\0\0\36Q\263\0\0\0\0\1\0\0\0\0\0\0\360\0"..., 2048) = 2048
read(9, "ANDROID!\346\257\363\0\0\200\0\0\36Q\263\0\0\0\0\1\0\0\0\0\0\0\360\0"..., 2048) = 2048
write(8, "ANDROID!\346\257\363\0\0\200\0\0\36Q\263\0\0\0\0\1\0\0\0\0\0\0\360\0"..., 2048) = 2048

The \35\254\363 corresponds to fotakernel from 10.107 fw, while \346\257\363 is the updated one from 11.228. Checking the calls around it may also reveal some internals.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Very hard. lookig into function which does compression identification is so hard. I'm found some track but hit to the wall. I'm still believe decompression need to be done with LzmaDec_DecodeToBuf , fot that we do not need to have lzma header but need to know extraction size? I'm preparing to try that function, but one which I found is newer one from 7z but it contain header parsing, probably need to find an old which do not have header parsing as described here https://asawicki.info/news_1368_lzma_sdk_-_how_to_use.html
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Just to lets you know, uncompress done! :) Have no more free time now to update unpack tool but next day I will do that.

Edit:

On first look its seems binary diff file but seems not a standard bsdiff file, it do not have BSDIFF header, need to be investigated.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] maplefzh:
hi,

My device is XZ1 Dual G8342. I restored TA. Though there's some ERROR in "service menu -> security", camera and video image enhancement work normally in 47.1.A.2.281_CE1. But after i flash 47.2.A.11.228 and restore TA many times ,video image enhancement still doesn't work. I don't know what I did wrong.

I noticed that persist_X-FLASH-ALL-42E5.sin should be removed. I used newflasher last year before read your post, so i'm not sure whether I flashed persist_X-FLASH-ALL-42E5.sin last year. Does it affect backup TA?

English poor, please forgive

thanks
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I'm discovered that 24 days ago, can't tell you much but thing which I know its related to device attestation key if I'm not wrong? Hope somebody point you to the right direction related to your problem.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] maplefzh:
I solved my problem. I didn't read "11.OPTIONAL step" hours ago. After i flashed "secd_ignore_unlock", they work well. :) Thank you for your reply.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=10270873]maplefzh[/MENTION], why you do not use the kernel hiding bootloader unlock? With that and your restored TA all drm functions would work, without patching anything else in the firmware.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] maplefzh:
thank you for your advice. i'm learning it
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
As promised here is updated tool. Don't wanted to compile tool with 7z lzma but I have mannaged to create real lzma dumps which you can open as a regular lzma archive, later I will use liblzma. Time for analyzing uncompressed files. It might be xdelta? Or striped bsdiff?

Edit:

Not bsdiff definitelly. Uncompressed bsdiff patch file have alsmost the same size like original file, in our case after looking into package_10 its definitelly not a bsdiff since ext4 partition starts with 0x400 bytes zero but our patch start as non zero. Might be imgdiff imgdiff2? Anybody have experience with android imagediff? It would be great if somebody upload an example
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mirhl:
Could this help?

https://source.android.com/devices/tech/ota/tools

https://github.com/cyxx/extract_android_ota_payload

https://gist.github.com/ius/42bd02a5df2226633a342ab7a9c60f15
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Thanks, Our ota which I'm testing is not from a/b device, its xz1c which do not have a/b, but I will check that! I'm tried some allready: minibsdiff (uncompessed binary diff), bsdiff, open-vcdiff, detools, xdelta, xdelta3, xdiff. No one produce at least similar format! One which I didn't tried is imgdiff and imgdiff2, for that I need to clone whole android repo but I don't have disk space for that. I'm believing format here is an specific format, pure RedBend delta format or probably some sony variant of RedBend delta format which I'm unable to find any source code. Even I had deep look into uncomressed lzma archive, looking for offsets to get an logic how it work, its nonsense totaly. One block from uncompressed package_1 offset 0x3360E7 with size 0x100A) match data from fotakernel 228 partition dump, got offset size of the block inside first 0x200 bytes of the package_1 (offset 0x24 size 4 bytes seems describe size of the that block. Unable to find offset position of the block at offset 0x0x3360E7 inside first 0x200 bytes which seems indication header is not inside irst 0x200 bytes) and when I thinked I got track on it I found that only 1 block match to dump of the fotakernel updated 228 partition, the rest I'm unable to find at least 4 bytes unable to find inside package_1. How it working I apsolutly have no idea right now, this might be the most hardest part I need to figure out :(

Edit:

Hey hey, it might be courgette format! Look for sequence of data e.g. 20 bytes 0xF0 (fota 228 do not have that, which is some indication for possible courgette format) inside uncompressed package_1 and compare with https://chromium.googlesource.com/chromium/src/courgette/+/refs/heads/master/testdata/ setup1-setup2.v1.bsdiff file, it looks very similar! :) One thing package_1 missing magic bytes, the rest is very similar, booth have similar structure. All tools which I'm tried do not produce sequence of that 0xf0 bytes :)

Edit:

Now questionable is how can we do this in case we have courgette format without GBSDIF42 magic bytes, how can we reconstruct missing header in case courgette format?

Edit:

It have sense why I see some blocks match inside patch in comparation to package_1 , this explains that:

Thats constant strings which I see, the rest I do not see because it is assebly. It have sense. Now question is how can we do our final step? I need help for this!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
[MENTION=4418980]j4nn[/MENTION] parameter "c" at the end of command fota-ua enables console whatewer that mean, I didn't tested without "c" but I have started android logd inside my virtual machine and I se now fota-ua logcat. Didn't tried without "c" but I will try next day. One thing which I have found using fota-ua with "c" it activate line (l_ctx->use_console: 1) in report log file. Without "c" report log have this line (l_ctx->use_console: 0). I'm believing without "c" it just do not write to logcat? I will confirm that next day. One interesting thing which I found is sub_41CBCC , did you seee that ? its seems very fine logging, it print whole delta structure, seems fine debug log, do you have idea how can we enable that fine logging without patching fota-ua?

Edit:

Seems write to /dev/tty ?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], I have not tested without 'c' parameter. I cannot tell about console, the only way I tested fota-ua was the start via android service which did not have a console set. Concerning logcat - I've tested to start logd service before "fota-ua c" service, got nearly nothing into logd - I've even posted it here, there has been only something with some probably unimportant ta unit.

Maybe the 'c' parameter directs logging into console, which is lost in case of service and if we remove the parameter, it would log into logd?

Or try to setup console for "fota-ua c" service (or if it can be run simply from command line, try that).

Concerning sub_41CBCC - I am not sure. It calls some big functions. In my opinion, it seems to check integrity of the update package?

At the end it verifies sony signature on it?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Just tested with and without "c". Booth working in logd, booth write android log message into logcat.

Witthout "c":

l_ctx->use_console: 0

With "c"

l_ctx->use_console: 1

What that mean I have no idea. Nothing in dmesg, didn't found any new interface in /dev/ , it seems have some special purpose, I'm unable to figure out :( Even I'm unable to fully decompile fota-ua, fail to decompile 1000 functions

Edit:

fota-ua read something from TA partition, might be that it read ta unit 9A9 to check if console is enabled?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
This should be a function pointer, it call the function at the address specified in pointer pfunc418 int the struct a1(pfunc should stand for function pointer), this function return an __int64, and take no argument (void), the ((__int64 (*)(void)) is the cast that specifies that is a function that takes no argument and the address of the funtion is 64bit

Are you asking this? Or are you referring to what it does in the sony code?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
[MENTION=4120742]munjeni[/MENTION]

the Problem is here

if ( *(_QWORD *)(a1.qword420 + 16LL) < (unsigned __int64)a1.pfunc418() )

return 0;

It check if a1.qword420 il less than the value returned by the function called by reference, but the reference il loaded from a static file (update_package_renamed ) , so the address pointed by pfunc418 is not present in your address space, thus generating a segmentation fault. Probably the Fota kernel is flashed before updating, so the address in the update_package is correct.

I think you should write a function which does the same as the function at the address pfunc418 (print that address , watch what function is at that address in the origina program) and manually overwrites the pfunc418 to point to the new written function

edit: For generating pseudo code, you could try https://ghidra-sre.org/, it's free and does a pretty good job
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Thanks, but how? Any example?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
After

if ((fread(&a1, 1, sizeof(struct struct_a1_1), fp)) != sizeof(struct struct_a1_1)) {
printf("Error, short read!\n");
return 0;
}

add

printf("fpun418 is %p: \n", a1.pfunc418);

Take that address, fire up your decompiler (IDA I think),load the binary from you extracted the other piece of code, go to that address(in ida the G key should be the shortcut) and decompile that function ((hoping no strange reference, and that the code is not loaded from other places (if this case a dump of the original memory could be useful))),

next, make a function

uint64_t My_Strange_func(){

//Code from HexRay
}

and finally after

if ((fread(&a1, 1, sizeof(struct struct_a1_1), fp)) != sizeof(struct struct_a1_1)) {
printf("Error, short read!\n");
return 0;
}

add

a1.pfunc418=&My_Strange_func;

And try to compile.

If it doesn't work, could you upload the (binary update_binary and the update package)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Thanks! Update_package_renamed is inside this post https://xdaforums.com/showpost.php?p=80591375&postcount=1328

and fota-ua binary is in attachment
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
fpun418 is 0x5780259f44deb663

But it just print data at offset 0x418 - 0x41f 8 bytes, its not pointer to the function
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
it is supposed t print that byte, if my supposition is right at this address in the memory there's a funtion. To be quite sure, could you post the bare disassembly(from ida) corresponding to the (unsigned __int64)((__int64 (*)(void))a1->pfunc418)() ) pseudo code.

(

Here's is the ghidra pseudo core for the function at 0x416304

undefined8 FUN_00416304(int *param_1)

{
ushort uVar1;
uint uVar2;
ulonglong uVar3;
longlong lVar4;
undefined8 uVar5;
char *pcVar6;
ulonglong *puVar7;

if ((param_1 == (int *)0x0) || (*(longlong *)(param_1 + 0x108) == 0)) {
FUN_00409000(0,0,0xe2,0,"ERROR","package info is not initialised\n");
}
else {
if (param_1[1] == 1) {
if (param_1[3] == 0x10000) {
if (param_1[4] != 0) {
uVar2 = 0;
puVar7 = (ulonglong *)(param_1 + 6);
do {
if (0x3f < *(uint *)((longlong)puVar7 + -4)) {
pcVar6 = "increments[%d] type is unexpected (0x%x)\n";
uVar5 = 0xfe;
LAB_00416504:
FUN_00409000(0,0,uVar5,0,"ERROR",pcVar6);
return 0;
}
if (*(ulonglong *)(*(longlong *)(param_1 + 0x108) + 0x10) < *puVar7) {
pcVar6 = "increments[%d] size is bigger than package (0x%llx)\n";
uVar5 = 0x105;
LAB_004164dc:
FUN_00409000(0,0,uVar5,0,"ERROR",pcVar6);
return 0;
}
if ((puVar7[2] & 3) == 0) {
pcVar6 = "increments[%d] is not FS or image update (0x%llx)\n";
uVar5 = 0x10d;
goto LAB_004164dc;
}
if (2 < *(int *)(puVar7 + 3) - 1U) {
pcVar6 = "increments[%d] has not been generated by valid generator (0x%x)\n";
uVar5 = 0x116;
goto LAB_00416504;
}
uVar2 = uVar2 + 1;
puVar7 = puVar7 + 4;
} while (uVar2 < (uint)param_1[4]);
}
uVar3 = (**(code **)(param_1 + 0x106))(param_1,2);
if (*(ulonglong *)(*(longlong *)(param_1 + 0x108) + 0x10) < uVar3) {
return 0;
}
uVar3 = (**(code **)(param_1 + 0x106))(param_1,4);
if (*(ulonglong *)(*(longlong *)(param_1 + 0x108) + 0x10) < uVar3) {
return 0;
}
uVar3 = (**(code **)(param_1 + 0x106))(param_1,5);
if (*(ulonglong *)(*(longlong *)(param_1 + 0x108) + 0x10) < uVar3) {
return 0;
}
lVar4 = *(longlong *)(*(longlong *)(param_1 + 0x108) + 8);
if (*(short *)(lVar4 + (ulonglong)(*param_1 - 4)) != 0) {
return 0;
}
uVar1 = *(ushort *)(lVar4 + (ulonglong)(*param_1 - 2));
uVar2 = FUN_00415288();
if ((uVar2 & 0xffff) != (uint)uVar1) {
return 0;
}
return 1;
}
pcVar6 = "RedBend sector size is unexpected (0x%x)\n";
uVar5 = 0xf5;
}
else {
pcVar6 = "package header type is unexpected (0x%x)\n";
uVar5 = 0xed;
}
FUN_00409000(0,0,uVar5,0,"ERROR",pcVar6);
}
return 0;
}
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
my supposition is right that is a funtion pointer

look at this

ROM:0000000000016390 LDR X8, [X19,#0x418]
ROM:0000000000016394 MOV W1, #2
ROM:0000000000016398 MOV X0, X19
ROM:000000000001639C BLR X8

The X19 holds some reference to particular part of the STACK POINTER

it loads in X8 the value at *(X19+ 0x418) (ida took the pfunc418 name from here)

then load 2 into the register W1,

it copies the X19, in the X0,

and finally, it branches to it, (the BLR do this PC=X8, X30=PC+4;)

So effectively it jumps at the address of pfunc418.

The question is, the address read from update ota is right?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
0x5780259f44deb663 is address, so I will need to dump memory at address 0x5780259f44deb663 and put into ida? Is this possible on virtual machine while running fota-ua? How can I know right momenat to do that? I think I will leave this and delete from my hard disk finaly :)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
you could run fota-ua through gdb, add a breakpoint at the address right before the jump, and read the content of X8(we get the address), also dumping the memory starting from the address at X8 is a good idea. (So we can decompile it eventually)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I'm sorry I'm not at that level of knownlegde, never used gdb :( Even I have no idea why printf("fpun418 is %p: \n", a1.pfunc418); gaved me address 0x5780259f44deb663 which is 6305080844 giga bytes
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
I don't know, the address may be wrong, or in fota kernel, this is a virtual address.

If you can add a link between your qemu and windows (thrught net or similar) might be wort try to run the ida android_server_64,

if we get it running we could trace/debug all program flow throud ida.

Are you able to get a virtual qemu net to communicate with fota kernel?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I have net on qemu but I don't own device, my device is xperia go :o

---------- Post added at 10:41 PM ---------- Previous post was at 10:31 PM ----------

If you are interested I can make tutorial for making fota-ua completely working under qemu virtual machine? I done sucesfull update from xz1c 117 firmware to 228 firmare under qemu with fota-ua. I must go now, if you need let me know!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Only working qemu with net is needed.

Yes, a tutorial would be nice.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Ok, in our 3 steps you can install qemu, xz1c partitions, fota-ua working.

step 1. (start.sh with 4 steps, this must be done NOT in qemu virtual machine, our step downloads qemu image and create stufs. Look into script, you need to extract 3 partition images from partition.sin file):

- step 1 (install ubuntu aarch64 qemu virtual cloud image): ./start.sh download_ubuntu_cloud

- step 2 (create Sony Xperia XZ1C disk): ./start.sh create_xz1c_disk

- step 3 (Boot it): ./start.sh boot

- step 4: when qemu virtual machine start until login screen, start another terminal window and do: ssh -v -p 2222 your_user_name_here@localhost

step 2. (install xz1c stufs, this must be done on qemu virtual machine, this step install things from sin files to partitions):

- step 1: run ./lunsetup.sh first-time (argument first-time is needed only one time and never again, all future callls to ./lunsetup is without argument first-time), on first prompt folow text! Firmware which is compatible with j4nn update_package_renamed is here -> https://mega.nz/#!EAQW0YYD!19h8NixAvqcG-RXjO-3W9ln1deut04XVY-8Fc1KeyRA , on first prompt upload sin files to /data partition folowing prompt text.

step 3. (run patched fota-ua):

lunsetup.sh (run it without arguments)

- update_package_renamed must be uploaded to /data

mkdir -p /cache/recovery/fota

rm -rf /fota_kernel

echo -n -e "\x06\x00\x00\x00\x09\x00\x00\x00\x00" >/cache/recovery/fota/ua_status

echo "--update_package=@/cache/recovery/block.map" > /cache/recovery/command

echo "--locale=en_GB" >> /cache/recovery/command

/system/bin/uncrypt /data/update_package_renamed /cache/recovery/block.map

./fota-ua c

---------------------------

- on next boot

lunsetup.sh (run it without arguments)

- update_package_renamed must be uploaded to /data

mkdir -p /cache/recovery/fota

touch /fota_kernel

hexdump -C /cache/recovery/fota/ua_status (if previous step is succed it will be 03 00 00 00 00 00 00 00 and you are ready for our step - flash system partitions and ...etc, if not 0300000000000000 it will fail our step!)

echo "--update_package=@/cache/recovery/block.map" > /cache/recovery/command

echo "--locale=en_GB" >> /cache/recovery/command

/system/bin/uncrypt /data/update_package_renamed /cache/recovery/block.map

./fota-ua c

If all gone right all partitions will be updated to android version 228. hexdump -C /cache/recovery/fota/status must display 00000000 that mean all is right. You can check uncrypt status with /system/bin/logcat . Done.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ruar:
Is this vulnerability valid for docomo?

security patch level 2017-9-1

build number 47.1.B.0.542
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
[MENTION=7543898]Blu-eyes[/MENTION] tutorial is done.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Thank a lot, in the next days I will try to analyze the fota-ua decrypt function
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Runing gdb for the first time, nice tool , got register x8 address pointer, it point to the function at offset 0x415f44 :) Can you tell me how can I set ida to have ram address instead of rom address?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
If the function is self contained in the executable it should be the sam as the rom(If ida base address is right).

Or better now that you get gdb running you cold run gdb server and connect into IDA as debugger and debug from there so you can use all the power of IDA

Edit:

Just checked the address 0x415f44 lead to a valid (very long) function
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
It will be much harder than I thinked, zlib deflating and zlib_slow deflating is used here, offset calculating and many more huge functions is used here. Gdb is great tool, it print function names, single stepping, instruction stepping...etc I didn't know that. Seems I have to learn a lot here :) Have no idea how to connect to gdb with ido. I must go now, see you, thanks!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
(gdb)
0x000000000041639c in package_info_is_sane ()
(gdb)
0x0000000000415f44 in calculate_offset ()

function at 0x415f44
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kaleyaki:
I followed this tutorial successfully, x reallity works again, if I no longer want OTA Updates can I disable them in some way? I just followed this tutorial to make x reallity work again
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
For IDA <-> GDB Connection

On the target machine

gdbserver 0.0.0.0:1234 futa_ua c (or other Arguments)

On ida

Load the Binary

On Degub Menu -> Select Debugger (F9)

Select Remote GDB

On Debugger Menu -> Process Option

On Hostname set the IP of the target machine

On Port Set The port(1234) in the code above

Set a breakpoint on the code using F2, The run The software on target machine using The Play Button, and Have Fun

Happy Hunting, Blu-Eyes

Or if you really like gdb, you could enhance it thought https://gef.readthedocs.io/en/master/
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
[MENTION=7543898]Blu-eyes[/MENTION] this is the time from fw_backup with zero size until the end of flashing fotakernel https://pastebin.com/7XNJKw81 , a lot of work understanding and almost imposible backporting I think :) What you think, is it possible reverse enginering? At least decompression.

Edit:

I must go to bed now after 6 hours on this :eek: