Learning About AVB Android Verified Boot (Boot.img dtb.img, vbmeta.img, and the "staging blob")

Search This thread

jenneh

Senior Member
@Renate Good Morning and Sorry about that! Thank you for your patience with me. Here are the addresses!!
1670247319083.png

Maybe this one Renate?
1670248556497.png

Could we change that to not branch to the mini jail? Like I see the adb external storage gives the option to branch to LAB_00404fb8 or the minijail address, so maybe make them both point to LAB_00404fb8 somehow? or is that not what we are looking for? Or would we maybe use a different address? Sorry I am just trying to imagine what to do.. Or maybe that LAB_004057b4? would we replace the bl minijail_new with that maybe?
 
Last edited:

Renate

Recognized Contributor / Inactive Recognized Dev
Could we change that to not branch to the mini jail?
No, we want to bypass a lot of stuff. I gave you the start and the end address of all that.

So, let's do this in an educational way (i.e not the most efficient).
You know that you want to modify "404fc8" but that address is not the file offset.
Your disassembler is using some load address.
So, make a copy of adbd. Find 5a 84 01 94 (I presume that they mean 0x9401845a).
If it finds more than one then search for 5a 84 01 94 28 08 00 f0 (and so on)
Now you know the file offset. It should probably end in fc8 like 0x123fc8
Then you want to try to change the instruction (as 32 bit) at that offset to 0x14000010, i.e. 10 00 00 14
We see from your last line of the previous post that a branch is 0x14000005, which is skipping 5 instructions.
I'm using 0x14000010 which skips 16 instructions.
Now, disassemble the modified file and you will see that minijail_new is now a branch.
Undoubtedly it falls short of 405xxx (whatever I said).
You can count how want instructions it falls short and add that number (in hexadecimal) to your original 0x14000010.
Then disassemble that. Were you right? No, adjust it.
 
  • Wow
Reactions: jenneh

jenneh

Senior Member
Hi @Renate Thank you for taking the time to Teach me!
1.PNG

So I think you want me to point to "access" specifically?

What I am having trouble with, is this step:
change the instruction (as 32 bit) at that offset to 0x14000010, i.e. 10 00 00 14
Which I think is a teachable moment to get me to play to get to access?

However... I cannot seem to see these instructions: " 0x123fc8" "0x14000005" I understand they are examples, but I cannot understand how to get to this view to be able to play or modify anything.

What I can do is right click, and "patch instruction"
Like in the case of the minijail_new
3.PNG

when I highlight 5a 84 01 94 that lets me see this
4.PNG

can I replace it with this address here from access?
2.PNG


Oh and I did make a copy of adbd!
had to select this button to add more views in byte mode
1670316174997.png

I wish I had spent more time studying about CPUs and what they actually do other than just run programs...

 
Last edited:

Renate

Recognized Contributor / Inactive Recognized Dev
  • Love
Reactions: jenneh

jenneh

Senior Member
Whelp it only took me half an hour to figure it out, but bytes mode is apparently the hex debugger in ghidra. Thank You, Renate! I have to pause here for the day but I promise tomorrow I will write back that I did it, all thanks to you!
1.PNG
 
Last edited:

jenneh

Senior Member
@Renate Good Morning!!

Well I had a strange error with Ghidrah and was unable to find help on it, specifically in the bytes view, trying to use the edit feature.
2.PNG

It is telling me the address I want to edit has an instruction that exists... Well obviously it does!
1.PNG

So I read a few guides and they did show you could edit in the "listing" view of ghidra, by using the patch instructions option
3.PNG

I copied the information from the address you showed me and typed it into the mini_jail new address
4.PNG

Doing the modification that way, Ghidra was able to modify the hex for us. So it seems Ghidra is able to do a lot!

I saved it like this as an elf (i think that was right since you said elf many times?)
5.PNG

and it created this guy! I am going to test now! Maybe I made a mistake, I am not sure but gosh I never would have made it this far without your help!!
6.PNG

edit well i must have done something wrong but i'm getting closer!
1670338806761.png


edit--- i see where it made it not be a "d" and put an "f" so maybe that's the problem x.x
 
Last edited:

Renate

Recognized Contributor / Inactive Recognized Dev
First of all, what I suggested as a patch is NOT the correct patch.
You were supposed to modify the copy of adbd, then VERIFY that the branch was to the correct place.
You never show that the instruction was modified correctly.
Of course it's not going to work and you need not bother showing me any details of it not working.
 
  • Like
Reactions: jenneh

Renate

Recognized Contributor / Inactive Recognized Dev
Just to recap...

Let's say you have a section of code with 5 instructions:
Code:
insn1
insn2
insn3
insn4
insn5
And you determine that the middle section (insn2, insn3, insn4) does something that you do not want to happen:
Code:
insn1
insn2 ; BAD!
insn3 ; BAD!
insn4 ; BAD!
insn5
You still want insn1 and insn5 to do their stuff. So you put in a branch instruction to branch around insn2, insn3, insn4.
On some planet you could stick in an instruction after insn1, but before insn2 to branch directly to insn5 (which you still want).
Unfortunately, we don't live on that 4th dimensional planet.
But, if we are (somehow) branching around insn2, insn3, insn4 then we don't need those instruction and that space could be used for something else. Like a branch.
Code:
insn1
xxxxx branch to insn5
insn3
insn4
insn5
So, of course we don't touch insn1 and insn5 (which we like).
But since we're branching around that middle place we actually have 3 spots to put in whatever instructions we like.
We could also do it this way using the "nop" instruction which does nothing.
Code:
insn1
xxxxx nop
xxxxx nop
xxxxx nop
insn5
It's just is that if we want to skip a big chunk, which is easier: writing 27 nops or 1 branch instruction?
Or we could even use that space to do something unrelated for something we want done elsewhere but we don't have the room:
Code:
insn1
xxxxx branch to insn5
xxxxx calculate pi
xxxxx return
insn5
TLDR: So you always want to change the instruction after the last instruction that you like.
 
  • Wow
Reactions: jenneh

jenneh

Senior Member
@Renate Good Morning and Thank You for taking the time to explain all this.. I feel like you are a mind reader haha.

So I think I have a new problem?

And let me apologize in advance, I am not trying to detour what you are trying to teach me, I just want to show you what I tried already and how it failed.

I was trying to just learn how to even make edits in hxd, so I followed this guide we read before https://harrisonsand.com/posts/patching-adb-root/

I was able to locate these offsets in ghidrah:
2.PNG
3.PNG


then in hxd under these views i found the offsets:
4.PNG


I made the NOP edits as shown below and saved
5.PNG


However I get this error.
6.PNG


The reason I think there is something more going on here is because when I go to replace the modded binary with the original system binary, adb still rejects my attempts to connect with the same error message and code.

I tried to do some research and without outright saying it, stuff is pointing to SELINUX, but I am wayyy out of my element and seemingly just prodding in the dark at this point.

Lastly, I had been using the binary from the uninstalled firmware image at first. This time I adb pulled the binary from a preinstalled system image incase that made a difference, and as far as running the modded bin. it did not.

Do you know what could be causing the system to reject the modded binary? Thank you for your time as always
 
Last edited:

Renate

Recognized Contributor / Inactive Recognized Dev
There are four steps here:
  1. Determine what you want to remove
  2. Modify the code to do that
  3. Verify what you did is what you think you did
  4. Actually try to run the modified code
I gave you a head start, I told you what you want to remove.

I told you how to remove an entire chunk.
You've gone and said, "Look, something says uid, I'll just remove that instead!"
You can't do that, it 's not going to work.

Moreover, removing a function call might be a lot more than replacing one instruction.
A function call needs arguments, that is, some registers or the stack set up with the correct values.
A function call is often checked afterwards to see if it succeeded.
When the function call itself is removed there will be no return code and this check will often fail.

minijail_new is the first instruction that we're calling "bad".
Since minijail_new takes no arguments we don't have to intervene with any earlier instructions.

access is the first function call that we're calling "good"
access requires two arguments so we have to include those arguments if we want access to work.
The first argument is set up with the two instruction adrp/add
The second argument is set up with the instruction mov.
So when we refer to the function call of access we mean all four instructions (including the bl).
In any case, we just want the address of the adrp.
We don't want to modify anything at all in this area.

The point of this whole exercise is to just change 32 bits of one instruction at one location.
That location is the location of the bl minijail_new instruction.
 
  • Wow
Reactions: jenneh

jenneh

Senior Member
@Renate Thank You for helping me to understand by providing all this Context. Now I get why that example i shared was failing and wouldn't or couldn't work. I really had no idea how everything is so device specific up to and including the binaries. Again sorry for a tangent, it just helps me to learn. Now that I know how to edit, I will start working in the area as you have said many times and report back. Sorry it didn't register until just now. Thank you Miss Renate!!!
 
  • Like
Reactions: tnomtlaw and Renate

Renate

Recognized Contributor / Inactive Recognized Dev
Am I understanding correctly...
Nope.
minijail_new is something bad. It's the first bad instruction. You want to replace that with a branch.
The adrp 0x4f7000 (on the bottom) is where you want to branch to. It's innocent. You neither want to modify it or to copy it to somewhere else.

(Note: This would be easier if you didn't hide the addresses. They are important when you are dealing with things at this level. Also, your disassembler is not particularly being helpful when it says "param_1". Since this is aarch64 I presume that they mean x0, but it could just as well be w0 if I didn't know any better. Also, your disassembler printing out 32 bit instructions as bytes in byte order is pedantic, but not helpful. The instruction that you mentioned is 0xd0000780, that's little-endian.)

The point that I was trying to make is that if you had an assembler or knew how to build an instruction you could just replace it with the correct branch. If you didn't, you could just replace it with any branch, then verify that it landed at the right place and if it didn't you could adjust the instruction until it did.
 
  • Love
Reactions: jenneh

jenneh

Senior Member
(Note: This would be easier if you didn't hide the addresses. They are important when you are dealing with things at this level. Also, your disassembler is not particularly being helpful when it says "param_1". Since this is aarch64 I presume that they mean x0, but it could just as well be w0 if I didn't know any better. Also, your disassembler printing out 32 bit instructions as bytes in byte order is pedantic, but not helpful. The instruction that you mentioned is 0xd0000780, that's little-endian.)
Thank you Renate for telling me all this.. Sorry for hiding the addresses, was working on not showing too much in my posts and I hit the other extreme. x.x

"The point that I was trying to make is that if you had an assembler or knew how to build an instruction you could just replace it with the correct branch. If you didn't, you could just replace it with any branch"

I will find me an assembler now! Honestly, when you mentioned assembler in the past, I thought it was being used interchangeably with the disassembler which seems (and is) stupid now that I think about it. There are so many moving parts here... I had no clue. This is a very humbling exercise and I really thank you for taking me this far.

these are things i am reading and watching so I can learn how to talk about things
 
Last edited:

Renate

Recognized Contributor / Inactive Recognized Dev
I don't know the disassembler you have, it probably does single instruction assembly.

Take your adbd, make a copy.
Find the actual address of the minijail_new call in the file.
You can do that by searching, you can do that by calculating offset, whatever.
Change that instruction to 0x14000077. That's a branch to some random place forward.
Stick that modified file in your disassembler and verify the effect that you made.
Is minijail_new gone? No: then you modified the wrong place.
Is the branch to the adrp in the setup for the access call? No: change the 77 part of the instruction to a higher value if you are short or a lower value if you went past.
 
  • Love
Reactions: jenneh

jenneh

Senior Member
Dan Walsh explains Selinux in the best way I have ever seen
It really helps to understand it as "a labeling system"

His website https://danwalsh.livejournal.com/

He says you can create a policy module towards the end of the video to allow your app the access you need without setting selinux to setenforce=0
amazing fix with VOLATAGE on XBOX
nes version of what i want to do with an android device
 
Last edited:

Renate

Recognized Contributor / Inactive Recognized Dev
He says you can create a policy module...
Yes, of course.
SE policy is usually written in .te files by the OEM.
But there is also "CIL" Common Intermediate Language.
You'll find them on your device. (You won't find any .te files.)
When Android boots it checks the dates and signatures on the CIL files.
If there is a need it recompiles sepolicy using secilc (the compiler) and all the CIL files.
You can also write your own rules in CIL and compile them with all the original CIL files.
 
  • Wow
Reactions: jenneh

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    Magisk and its variants just start from a stock boot image.
    You can swap the modified image with friends as long as the original boot images were compatible.
    2
    I found the mini jail now...
    Nope. You found the text string "minijail_changing_gid".
    If you changed that it would only change the text printed in the log.
    You want to find where that string is being used.
    For that you need to disassemble.
    Code:
        2110:	f0ffffe0 	adrp	x0, 1000 ; "ADB_EXTERNAL_STORAGE"
        2114:	91204000 	add	x0, x0, #0x810
        2118:	940004e6 	bl	34b0 ; getenv()@plt
        211c:	b40000e0 	cbz	x0, 2138
        2120:	aa0003e1 	mov	x1, x0
        2124:	f0ffffe0 	adrp	x0, 1000 ; "EXTERNAL_STORAGE"
        2128:	911cf000 	add	x0, x0, #0x73c
        212c:	320003e2 	orr	w2, wzr, #0x1
        2130:	940004e4 	bl	34c0 ; setenv()@plt
        2134:	14000005 	b	2148
        2138:	f0000008 	adrp	x8, 5000 ; 00005000
        213c:	f9418d08 	ldr	x8, [x8,#792]
        2140:	39400108 	ldrb	w8, [x8]
        2144:	37004908 	tbnz	w8, #0, 2a64
        2148:	140000e1 	b	24cc
    Yours will, of course, be different.
    2
    I was wondering if you have ever experienced lag in the adb shell?
    No, I've found ADB to be pretty efficient when using multiple shells or adbsync.exe or adbgrab.exe
    Still, Google gets no credit for an adb.exe that takes over a second to start. I guess they just put lots of delays in to work around some race condition on an i386.
    2
    @Renate Thank You for helping me to understand by providing all this Context. Now I get why that example i shared was failing and wouldn't or couldn't work. I really had no idea how everything is so device specific up to and including the binaries. Again sorry for a tangent, it just helps me to learn. Now that I know how to edit, I will start working in the area as you have said many times and report back. Sorry it didn't register until just now. Thank you Miss Renate!!!
    2
    And Are these images actually stored on the device physically Twice?
    No, that -> tells you that they are just symbolic links.
    On some devices the "friendly names" are cryptic. On others some of them are more descriptive.
    Code:
    $ cd /dev/block/by-name/
    $ ls -l
    total 0
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 abl_a -> /dev/block/mmcblk0p19
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 abl_b -> /dev/block/mmcblk0p20
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 apdp -> /dev/block/mmcblk0p58
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 bluetooth_a -> /dev/block/mmcblk0p32
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 bluetooth_b -> /dev/block/mmcblk0p33
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 boot_a -> /dev/block/mmcblk0p36
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 boot_b -> /dev/block/mmcblk0p37
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 carrier -> /dev/block/mmcblk0p56
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 cid -> /dev/block/mmcblk0p53
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 cmnlib64_a -> /dev/block/mmcblk0p13
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 cmnlib64_b -> /dev/block/mmcblk0p14
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 cmnlib_a -> /dev/block/mmcblk0p11
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 cmnlib_b -> /dev/block/mmcblk0p12
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 ddr -> /dev/block/mmcblk0p29
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 devcfg_a -> /dev/block/mmcblk0p23
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 devcfg_b -> /dev/block/mmcblk0p24
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 devinfo -> /dev/block/mmcblk0p57
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 dhob -> /dev/block/mmcblk0p46
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 dsp_a -> /dev/block/mmcblk0p34
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 dsp_b -> /dev/block/mmcblk0p35
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 dtbo_a -> /dev/block/mmcblk0p38
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 dtbo_b -> /dev/block/mmcblk0p39
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 frp -> /dev/block/mmcblk0p52
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 fsc -> /dev/block/mmcblk0p71
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 fsg_a -> /dev/block/mmcblk0p69
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 fsg_b -> /dev/block/mmcblk0p70
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 hw -> /dev/block/mmcblk0p72
    lrwxrwxrwx 1 root root 20 1970-04-18 05:37 hyp_a -> /dev/block/mmcblk0p9
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 hyp_b -> /dev/block/mmcblk0p10
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 keymaster_a -> /dev/block/mmcblk0p15
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 keymaster_b -> /dev/block/mmcblk0p16
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 kpan -> /dev/block/mmcblk0p45
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 limits -> /dev/block/mmcblk0p65
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 logfs -> /dev/block/mmcblk0p60
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 logo_a -> /dev/block/mmcblk0p54
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 logo_b -> /dev/block/mmcblk0p55
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 metadata -> /dev/block/mmcblk0p50
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 misc -> /dev/block/mmcblk0p51
    lrwxrwxrwx 1 root root 18 1970-04-18 05:37 mmcblk0 -> /dev/block/mmcblk0
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 modem_a -> /dev/block/mmcblk0p30
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 modem_b -> /dev/block/mmcblk0p31
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 modemst1 -> /dev/block/mmcblk0p67
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 modemst2 -> /dev/block/mmcblk0p68
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 msadp -> /dev/block/mmcblk0p47
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 padA -> /dev/block/mmcblk0p74
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 padB -> /dev/block/mmcblk0p76
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 persist -> /dev/block/mmcblk0p48
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 prodpersist -> /dev/block/mmcblk0p49
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 prov_a -> /dev/block/mmcblk0p17
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 prov_b -> /dev/block/mmcblk0p18
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 qupfw_a -> /dev/block/mmcblk0p25
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 qupfw_b -> /dev/block/mmcblk0p26
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 recovery_a -> /dev/block/mmcblk0p40
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 recovery_b -> /dev/block/mmcblk0p41
    lrwxrwxrwx 1 root root 20 1970-04-18 05:37 rpm_a -> /dev/block/mmcblk0p7
    lrwxrwxrwx 1 root root 20 1970-04-18 05:37 rpm_b -> /dev/block/mmcblk0p8
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 sp -> /dev/block/mmcblk0p73
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 spunvm -> /dev/block/mmcblk0p59
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 ssd -> /dev/block/mmcblk0p42
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 storsec_a -> /dev/block/mmcblk0p27
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 storsec_b -> /dev/block/mmcblk0p28
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 super -> /dev/block/mmcblk0p75
    lrwxrwxrwx 1 root root 20 1970-04-18 05:37 tz_a -> /dev/block/mmcblk0p5
    lrwxrwxrwx 1 root root 20 1970-04-18 05:37 tz_b -> /dev/block/mmcblk0p6
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 uefisecapp_a -> /dev/block/mmcblk0p21
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 uefisecapp_b -> /dev/block/mmcblk0p22
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 uefivarstore -> /dev/block/mmcblk0p66
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 userdata -> /dev/block/mmcblk0p77
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 utags -> /dev/block/mmcblk0p43
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 utagsBackup -> /dev/block/mmcblk0p44
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 vbmeta_a -> /dev/block/mmcblk0p61
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 vbmeta_b -> /dev/block/mmcblk0p62
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 vbmeta_system_a -> /dev/block/mmcblk0p63
    lrwxrwxrwx 1 root root 21 1970-04-18 05:37 vbmeta_system_b -> /dev/block/mmcblk0p64
    lrwxrwxrwx 1 root root 20 1970-04-18 05:37 xbl_a -> /dev/block/mmcblk0p1
    lrwxrwxrwx 1 root root 20 1970-04-18 05:37 xbl_b -> /dev/block/mmcblk0p2
    lrwxrwxrwx 1 root root 20 1970-04-18 05:37 xbl_config_a -> /dev/block/mmcblk0p3
    lrwxrwxrwx 1 root root 20 1970-04-18 05:37 xbl_config_b -> /dev/block/mmcblk0p4
    $