[General Questions and Answers] Renate:
Well, here's a file I recently modded. This is a list of the sections of the ELF file:

elfview /v libscp.so
# Name Type Flags Size Offset Address
-- ------------------------ --------- ----- -------- ------ --------
program header table 256 000034
1 .note.android.ident note 2 152 000134 00000134
2 .note.gnu.build-id note 2 36 0001cc 000001cc
3 .dynsym dynsym 2 5760 0001f0 000001f0
4 .dynstr strtab 2 27972 001870 00001870
5 .gnu.hash hash 2 2680 0085b4 000085b4
6 .hash hash 2 2500 00902c 0000902c
7 .gnu.version versym 2 720 0099f0 000099f0
8 .gnu.version_d verdef 2 28 009cc0 00009cc0
9 .gnu.version_r verneed 2 64 009cdc 00009cdc
10 .rel.dyn rel 2 112 009d1c 00009d1c
11 .rel.plt rel 42 320 009d8c 00009d8c
12 .plt progbits 6 500 009ecc 00009ecc
13 .text progbits 6 10854700 00a0c0 0000a0c0
14 .ARM.exidx 7.0.1 82 264 a641ec 00a641ec
15 .rodata progbits 2 415972 a642f8 00a642f8
16 .ARM.extab progbits 2 60 ac9bdc 00ac9bdc
17 .data.rel.ro progbits 3 4 ac9df4 00acadf4
18 .fini_array fini 3 8 ac9df8 00acadf8
19 .init_array init 3 4 ac9e00 00acae00
20 .dynamic dynamic 3 296 ac9e04 00acae04
21 .got progbits 3 212 ac9f2c 00acaf2c
22 .data progbits 3 0 aca000 00acb000
23 .bss nobits 3 215816 aca000 00acb000
24 .comment progbits 30 220 aca000 00000000
25 .note.gnu.gold-version note 0 28 aca0dc 00000000
26 .ARM.attributes 7.0.3 0 54 aca0f8 00000000
27 .shstrtab strtab 0 283 aca12e 00000000
section header table 1120 aca24c
end of file afeb08

You want to extend the .rodata section for your string but you'd have to move everything up.

You could add another section (but before the section header table) but that's complicated too.

I think that you should save these techniques for where you have to add a large function somewhere.

Ok, so you want to have an automated way to have this all work on an updated version of this file.

When files get updated 99% stays the same but almost all addresses move around.

To change the text, it's pretty easy, just search for eels and change the text.

You still haven't got around to even manually finding where your string is referenced.

You may find that it's not some easy, single instruction reference.

That could even be difficult if they use some table of error messages with relative offsets.

Here's a simple case (in armeabi-v7a Thumb) where an instruction references a PC relative offset:

ab7d4:	4954	ldr	r1, [pc, #336] ; ab928

ab928: Offset -> 00a66d17

a66d17: String(9) "removeListener"

Yes, you can just search for 00a66d17 in the code.

(Actually, it's not really an offset. It's an absolute address that gets fixed up by the loader.)

Here's a more complicated case (in arm64-v8a):

ab7ec:	f0008963	adrp	x3, 11da000
ab7f0:	d0008964	adrp	x4, 11d9000
ab7f4:	9111a000	add	x0, x0, #0x468
ab7f8:	910af842	add	x2, x2, #0x2be
ab7fc:	910a6463	add	x3, x3, #0x299

11da299: String(9) "removeListener"

You see that x3 is loaded with PC+0x11da000, but then four instructions later 0x299 is added for the actual address!

You will not be able to search for 011da299 in the code, it's not there.

Then there's armeabiv7a Thumb code doing it this way:

388802:	4e07	ldr	r6, [pc, #28]
388804:	f104 0170	add.w	r1, r4, #112
388808:	6001	str	r1, [r0, #0]
38880a:	447e	add	r6, pc

388820: Offset -> 00b42230

The first instruction loads a constant. Why?

Then we see the fourth instruction adding in the PC.

Oh, it's not just a constant, it's an address.