Support needed for 4K devices. ( In more understandable terms, "old" devices )
Is it possible if we can get an explanation on what defines a "4K device", "16k device", etc.?
After a quick google search, I have a feeling it might have to do with the size of the memory pages (http://stackoverflow.com/questions/21552747/strange-behavior-on-64bit-ios-devices-when-retrieving-vm-statistics/33574804)
/*
* page size -> used to know how many pages the ipc ports zone will use per block so we can guess task port addresses
>*/
.....
int page_size = getpagesize();
.....
if (page_size == 0x1000) // running with 4k pages
.......
else if (page_size == 0x4000) // running with 16k pages
.....
Yes, 4K and 16K are memory pages per block of memory allocated to zones. Reading a comment and few lines of code from Ian Beer's mach_portal (kernel_sploit.c) also explains what is meant by 4K and 16K and for what it is used.
Original article & code:
https://bugs.chromium.org/p/project-zero/issues/detail?id=965#c2
How are we supposed to debug a kernel panic on these devices?
Here's the device log for an attempted JB on an iP6:
Jan 26 15:51:01 Julians-iPhone yalu102[540] <Notice>: found corruption 38403
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: found kernel text at fffffff022c04000
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: got tfp0 -> e07
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: found procs at fffffff004c56850
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __TEXT
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __DATA_CONST
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __TEXT_EXEC
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __KLD
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __LAST
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __DATA
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __PRELINK_TEXT
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __PLK_TEXT_EXEC
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __PRELINK_DATA
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __PLK_DATA_CONST
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __PLK_LINKEDIT
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __PRELINK_INFO
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: seg: __LINKEDIT
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: fffffff021ccc000 - fffffff023494000
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: ffffffff03cd4000
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: fffffff022c715a0
Jan 26 15:51:08 Julians-iPhone yalu102[540] <Notice>: pmap: fffffff023120850
Could panic here: https://github.com/kpwn/yalu102/blob/master/yalu102/jailbreak.m#L266
Possibly change that to 0x1000?
@meyer9 I can test?
sure, but I'm just taking a wild guess here
alright, that helped I think?
2017-01-26 16:11:45.462718 yalu102[252:9458] debug: test point 1
2017-01-26 16:11:45.462881 yalu102[252:9458] debug: test point 2
2017-01-26 16:11:45.462966 yalu102[252:9458] debug: test point 3
2017-01-26 16:11:45.463140 yalu102[252:9458] debug: test point 4
2017-01-26 16:11:45.463253 yalu102[252:9458] debug: test point 5
2017-01-26 16:11:45.463326 yalu102[252:9458] debug: test point 6
2017-01-26 16:11:45.463387 yalu102[252:9458] debug: test point 7
2017-01-26 16:11:45.463568 yalu102[252:9458] got phys at 802dd2000 for virt fffffff00088f000
2017-01-26 16:11:45.463692 yalu102[252:9458] found cpu 0
2017-01-26 16:11:45.463725 yalu102[252:9458] found physz: fffffff012693000
2017-01-26 16:11:45.463806 yalu102[252:9458] found cpu 1
2017-01-26 16:11:45.463873 yalu102[252:9458] found physz: fffffff012693000
2017-01-26 16:11:45.463997 yalu102[252:9458] fffffff012793574 - fffffff0127933a8
2017-01-26 16:11:45.465377 yalu102[252:9458] ttbr0: 802ab9000 fffffff012671590
Still gets stuck though :P
It got further @meyer9
yeah
2017-01-26 16:19:00.212362 yalu102[222:4858] debug: test point 8
2017-01-26 16:19:00.212397 yalu102[222:4858] debug: test point 9
2017-01-26 16:19:00.212481 yalu102[222:4858] debug: test point 10
2017-01-26 16:19:00.212515 yalu102[222:4858] debug: test point 2
2017-01-26 16:19:00.213501 yalu102[222:4858] got a cpacr
https://github.com/kpwn/yalu102/pull/26#issuecomment-275486662
@meyer9 we need to fix whats causing corruption ;/
found corruption XXXXX
that's not normal?
I didn't think so, it might be? @meyer9
I believe it is. The problem stems from this function:
```
pagestuff_64((address) & (~PMK), ^(vm_address_t tte_addr, int addr) {\
uint64_t tte = ReadAnywhere64(tte_addr);\
if (!(TTE_GET(tte, TTE_IS_TABLE_MASK))) {\
NSLog(@"breakup!");\
uint64_t fakep = physalloc(PSZ);\
uint64_t realp = TTE_GET(tte, TTE_PHYS_VALUE_MASK);\
TTE_SETB(tte, TTE_IS_TABLE_MASK);\
for (int i = 0; i < PSZ/8; i++) {\
TTE_SET(tte, TTE_PHYS_VALUE_MASK, realp + i * PSZ);\
WriteAnywhere64(fakep+i*8, tte);\
}\
TTE_SET(tte, TTE_PHYS_VALUE_MASK, findphys_real(fakep));\
WriteAnywhere64(tte_addr, tte);\
}\
uint64_t newt = physalloc(PSZ);\
copyin(bbuf, TTE_GET(tte, TTE_PHYS_VALUE_MASK) - gPhysBase + gVirtBase, PSZ);\
copyout(newt, bbuf, PSZ);\
TTE_SET(tte, TTE_PHYS_VALUE_MASK, findphys_real(newt));\
TTE_SET(tte, TTE_BLOCK_ATTR_UXN_MASK, 0);\
TTE_SET(tte, TTE_BLOCK_ATTR_PXN_MASK, 0);\
WriteAnywhere64(tte_addr, tte);\
NSLog(@"level %llx - %llx", tte_addr, TTE_GET(tte, TTE_PHYS_VALUE_MASK));\
}, level1_table, 2);
Doesn't look like an easy fix
I'm at the same place as you @meyer9
Check out pte_stuff
These possibly need adjusting?
typedef union VMA_4K {
struct {
uint64_t block_off : 12;
uint64_t level3_index : 9;
uint64_t level2_index : 9;
uint64_t level1_index : 9;
uint64_t level0_index : 9;
uint64_t ttbr_selector : 16;
} __attribute__((packed)) vm_info;
uint64_t vmaddr;
} VMA_4K;
Tell me if you get the correct values 👍
Just an after thought if those are the 16K device strings or same as won't the 4K values be a quater of the 16K values ?
Probably not since all of them aren't divisible by 4, but I have no clue
I'm guessing if it was an easy fix it would already have been added :p
Probably, but it's still fun to look
Yeah
Just leave a comment if you find / fix something else
If I put NSLog(@"calling back %llu %d", tteaddr, level); just before pagestuff_64_callback in pte_stuff.h, I get calling back 18446743970915550384 2. But it does not run the callback...
Can someone do this on a verified working JB and see what it gives them? The level may be different.
Ive been trying to look for successful logs but haven't found them
I haven't tried this yet, and that's because I don't have a jailbreak working. Despite my lack of memory-management knowledge, I'll see if I can do anything.
I just forgot that I didn't plug in my iPhone yet. Also, @Mila432's latest commit does not support the TSMC iPhone 6s and SE (which has S8003 at the end, and not S8000).
Just tried to run the jailbreak. No output. Just a crash and reboot.
On what device?
I'd like someone to add that debug line I described above and paste the output on a working JB.
The iPhone 6.
Got it. That's pretty expected. We're looking for comparison with a different device.
I'll try to fix this problem. At the same time, I'll be trying to find a way to make this code a bit easier to read (and this is by using more "if" statements with u.machine to better define which set of offsets are for which device).
kernel panic:
panic(cpu 1 caller 0xfffffff01d3969e8): Kernel data abort. (saved state: 0xfffffff16943b350)
x0: 0xfffffff001e274d8 x1: 0xffffffe81b600748 x2: 0x0000000000000000 x3: 0xfffffff001e274d8
x4: 0xfffffff16943b838 x5: 0xfffffff16943b988 x6: 0x0000000010000003 x7: 0xfffffff004b4bf00
x8: 0xfffffff01d79a868 x9: 0xfffffff01d79a868 x10: 0xfffffff001e274d8 x11: 0xfffffff001e274d8
x12: 0xfffffff01d766380 x13: 0x00000000000014f9 x14: 0xaaaaaaaaaaaaaaab x15: 0x0000000000000018
x16: 0xfffffff01d748f10 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0xfffffff11cd5a920
x20: 0x0000000000000008 x21: 0xfffffff001e274d8 x22: 0xffffffe81b600748 x23: 0x0000000000000020
x24: 0x0000000000000000 x25: 0xffffffe81b600750 x26: 0xffffffe81b600748 x27: 0x0000000000000001
x28: 0xfffffff16943b838 fp: 0xfffffff16943b6a0 lr: 0xfffffff01d32f9bc sp: 0xfffffff16943b6a0
pc: 0xfffffff01d28e034 cpsr: 0x60000304 esr: 0x96000004 far: 0xffffffe81b600748
Debugger message: panic
Memory ID: 0x1
OS version: 14C92
Kernel version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4\/RELEASE_ARM64_T7000
KernelCache UUID: E241E5E5848A662ECF7751CB6E36E94D
iBoot version: iBoot-3406.30.8
secure boot?: YES
Paniclog version: 6
Kernel slide: 0x0000000016200000
Kernel text base: 0xfffffff01d204000
Epoch Time: sec usec
Boot : 0x588a933b 0x000b0c5c
Sleep : 0x00000000 0x00000000
Wake : 0x00000000 0x00000000
Calendar: 0x588a93ad 0x000729f0
Panicked task 0xfffffff00253a000: 8941 pages, 6 threads: pid 224: yalu102
Panicked thread: 0xfffffff002b534f0, backtrace: 0xfffffff16943af90
lr: 0xfffffff01d39bbc0 fp: 0xfffffff16943b000
lr: 0xfffffff01d2b6e70 fp: 0xfffffff16943b050
lr: 0xfffffff01d3969e8 fp: 0xfffffff16943b240
lr: 0xfffffff01d39709c fp: 0xfffffff16943b330
lr: 0xfffffff01d2901f0 fp: 0xfffffff16943b340
lr: 0xfffffff01d28e034 fp: 0xfffffff16943b6a0
lr: 0xfffffff01d32f9bc fp: 0xfffffff16943b6e0
lr: 0xfffffff01d33cf70 fp: 0xfffffff16943b820
lr: 0xfffffff01d365f20 fp: 0xfffffff16943b870
lr: 0xfffffff01d304f1c fp: 0xfffffff16943b8b0
lr: 0xfffffff01d29ef18 fp: 0xfffffff16943ba20
lr: 0xfffffff01d2af3c8 fp: 0xfffffff16943bad0
lr: 0xfffffff01d3983f0 fp: 0xfffffff16943bba0
lr: 0xfffffff01d396d0c fp: 0xfffffff16943bc90
lr: 0xfffffff01d2901f0 fp: 0xfffffff16943bca0
I can tell this is a kernel panic. What does the rest mean?
I believe they are the values of the registers?
Also, the tte_addr is thought to be ffffffe8110004b0 according to the callback where it fails.
I think we're looking at this wrong. It probably fails earlier and then only crashes later since there should be no reason it's crashing at that specific spot.
I'm not sure how to look at this. I only learned a little bit of memory management, but that was because I was learning how a buffer overflow works.
Quick question: How do I access the device logs?
When you run the app with XCode Open the Console
I'm getting no output from the console.
are you running from Xcode?
did you run the app with xcode and let it open automatically?
It's also in Impactor under Device > Watch Log
No. I set Xcode to not run the app automatically, but to wait for me to launch the app to start debugging.
same as me on my iPad Air 2,
sysname: Darwin
nodename: Augustas-iPad-Air-2-Silver
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:09 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7001
machine: iPad5,3
2017-01-27 11:49:16.463734 yalu102[224:8076] found corruption 38303
2017-01-27 11:49:16.774413 yalu102[224:8076] found kernel text at fffffff008604000
2017-01-27 11:49:16.776410 yalu102[224:8076] got tfp0 -> 38403
2017-01-27 11:49:16.777854 yalu102[224:8076] found procs at fffffff10d428c18
2017-01-27 11:49:16.781215 yalu102[224:8076] seg: __TEXT
2017-01-27 11:49:16.781268 yalu102[224:8076] seg: __DATA_CONST
2017-01-27 11:49:16.781305 yalu102[224:8076] seg: __TEXT_EXEC
2017-01-27 11:49:16.781337 yalu102[224:8076] seg: __KLD
2017-01-27 11:49:16.781371 yalu102[224:8076] seg: __LAST
2017-01-27 11:49:16.781404 yalu102[224:8076] seg: __DATA
2017-01-27 11:49:16.781435 yalu102[224:8076] seg: __PRELINK_TEXT
2017-01-27 11:49:16.781484 yalu102[224:8076] seg: __PLK_TEXT_EXEC
2017-01-27 11:49:16.781518 yalu102[224:8076] seg: __PRELINK_DATA
2017-01-27 11:49:16.781548 yalu102[224:8076] seg: __PLK_DATA_CONST
2017-01-27 11:49:16.781578 yalu102[224:8076] seg: __PLK_LINKEDIT
2017-01-27 11:49:16.781610 yalu102[224:8076] seg: __PRELINK_INFO
2017-01-27 11:49:16.781640 yalu102[224:8076] seg: __LINKEDIT
2017-01-27 11:49:16.781666 yalu102[224:8076] fffffff007670000 - fffffff008ea0000
2017-01-27 11:49:16.815980 yalu102[224:8076] ffffffff045d0000
2017-01-27 11:49:16.852228 yalu102[224:8076] fffffff0086715a0
2017-01-27 11:49:16.887973 yalu102[224:8076] pmap: fffffff008b20850
2017-01-27 11:49:16.924006 yalu102[224:8076] got phys at 0 for virt fffffff1b7790000
2017-01-27 11:49:16.924117 yalu102[224:8076] found cpu 0
2017-01-27 11:49:16.924150 yalu102[224:8076] found physz: fffffff008693000
2017-01-27 11:49:16.924188 yalu102[224:8076] found cpu 1
2017-01-27 11:49:16.924218 yalu102[224:8076] found physz: fffffff008693000
2017-01-27 11:49:16.924255 yalu102[224:8076] found cpu 2
2017-01-27 11:49:16.924282 yalu102[224:8076] found physz: fffffff008693000
2017-01-27 11:49:16.924323 yalu102[224:8076] fffffff008793714 - fffffff008793548
2017-01-27 11:49:16.925590 yalu102[224:8076] ttbr0: 802ac5000 fffffff008671590
2017-01-27 11:49:16.926011 yalu102[224:8076] got a cpacr
Yeah this seems like a race condition for the logs, so those are basically useless.
It's something before that.
If I add an exit(0) before the cpacr code, the device does not panic.
It does panic before RemapPage
Panics on: WriteAnywhere64(ReadAnywhere64(find_kernel_pmap()), level1_table);
This comes from patchfinder64, a proprietary library by @kpwn.
Disassembled:
int _find_kernel_pmap() {
r7 = (sp - 0xc) + 0x4;
r4 = sp - 0x40;
asm { bfc r4, #0x0, #0x3 };
sp = r4;
r0 = _find_string_reference("\"pmap_map_bd\"", 0x0);
stack[2042] = r0;
if ((r0 | 0x0) == 0x0) {
_NSLog(@"couldn't reference pmap_map_bd");
r0 = _abort();
}
else {
r0 = _get_data_for_mode(0x0, 0x0, 0x0);
*(sp + 0x4) = 0xd8b;
*sp = 0x0;
r0 = _find_prev_instruction_matching(r0, stack[2042], 0x0, 0x20, stack[2032], stack[2033]);
stack[2041] = stack[2042];
stack[2040] = r0;
if ((r0 | stack[2042]) == 0x0) {
_NSLog(@"pmap: couldn't reference prev_bl");
r0 = _abort();
}
else {
r0 = _get_data_for_mode(0x0, 0x0, 0x0);
*(sp + 0x4) = 0x2;
*sp = *0x2974;
r0 = _find_register_value(r0, stack[2040], stack[2041], *0x2970, stack[2032], stack[2033]);
}
}
return r0;
}
P.S. @kpwn, if you are reading this, thank you so much for everything. I'm not sure if I helped you at all, but hopefully someone can figure this one out.
the problem isn't in patchfinder64. patchfinder64 was used in yalu 10.1 too.
@parrotgeek1, I never saw 4K Device Support in Yalu 10.1.1 either.
Oops. My bad.
On Jan 26, 2017 11:16 PM, "Nicholas Gibbons" notifications@github.com
wrote:
@parrotgeek1 https://github.com/parrotgeek1, I never saw 4K Device
Support in Yalu 10.1.1 either.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kpwn/yalu102/issues/40#issuecomment-275603673, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABob3YPT7x9mqX7PlLXSiRkdNMiBo5btks5rWZnngaJpZM4LuV4j
.
I wonder if patchfinder has ever been used with 4k devices...
The issue is that pagetable layout is different on 4k devices, so pagestuff_64 is used improperly (i think).
This patchfinder was used for Yalu2 on 9.3.3, which was developed on a 64 bit 4k device.
Well that makes more sense. If you need any results just leave a comment :)
'i hope eta is son' kind of posts will be removed.
you are literally commenting on an issue in the entire code i am building
@kpwn can you ask qwertyuiop why the original mach_portal project works on 4K devices and why this doesn't, didn't the original mach_portal project also use pagestuff_64.
mach_portal doesn't use pagestuff64, mach_portal+yalu does, and it doesn't work on 4k. also i am qwerty.
note that pagestuff itself is fine. issue is in code that uses it.
Oh okay, and well that is embarrassing... walks out of room slowly
@kpwn can you point out exactly where it is being used that is wrong, or is it in one of the precompiled binaries?
The whole time I'm asleep, this place is active.
We all love you @kpwn, but this project is vulnerable to the hands of Stefan Esser. Should I add the license to that? xD
Let's see, so if level_1_table is wrong then I'm assuming something about this is wrong?
uint64_t ttbr0_real = find_register_value((uint32_t*)get_data_for_mode(0, SearchTextExec), idlesleep_handler + idx*4 - gadget_base + 24, text_exec_base, 1);
As in, it's not finding the correct location for 4k devices...
Wait so where does it panic?
Shouldn't you get NSLog(@"level %llx - %llx",
Yeah my guess is level_1
I seriously need to learn to understand this stuff.
I've got C and Objective-C programming books in my shopping list. I should buy them when I have the time.
@kpwn is weekend friday or saturday for you btw? I know with some people it differs.
I think he's asleep right now. He's in Europe.
@tangalbert919 its 5:44pm
It's only 5pm in U.K. ;)
Sent from my iPad
On 27 Jan 2017, at 16:44, Albert Tang notifications@github.com wrote:
I think he's asleep right now. He's in Europe.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
My sleep cycles are not normal, although it's almost 6pm here, I am still awake. Anyway my definition of weekend is do you really care this much
I didn't think they were normal lol, and yes, I have a paid tweak release coming up and I need to strategise, I'll refrain from future personal questions as they deviate from the this thread.
@kpwn pmsl lol 😂 your doing amazing job when it's dun it's dun life goes on 💩
@kpwn Some people may.
But a majority of us dont care when its fixed. We just care that you are taking a look at the problem and trying to fix it eventually. Thats all that really matters.
this thread is not for asking him when it will be fixed but instead for fixing the bug
I was never asking when, I was asking his perception on when a weekend starts
The level may indeed be the issue. Try to pass 1 rather than 2. Not sure, but i think it's that.
Note that findphys_real also has the same assumption, so that's why sometimes it may fail earlier.
I can try when I get home.
Well, the RemapPage is sending level 2 to the callback function, so I wouldn't be surprised if that was part of the problem. On iP7 is it returning level 1 in the callback or level 2? You can see the debug message I added above and the output.
If I put NSLog(@"calling back %llu %d", tteaddr, level); just before pagestuff_64_callback in pte_stuff.h, I get calling back 0xffffffe8110004b0 2. But it does not run the callback...
Good to know @kpwn is still awake.
I checked the offsets across device kernels that use the same CPU. They really are the same. I'll just wait until @kpwn does testing on 4K devices. Maybe I'll be one of them, because I'm bored and it sucks to do nothing.
changed this:
uint64_t ttbr0_real = find_register_value((uint32_t*)get_data_for_mode(0, SearchTextExec), idlesleep_handler + idx*4 - gadget_base + 24, text_exec_base, 1);
to:
uint64_t ttbr0_real = find_register_value((uint32_t*)get_data_for_mode(1, SearchTextExec), idlesleep_handler + idx*4 - gadget_base + 24, text_exec_base, 1);
this is the output when changing it:
sysname: Darwin
nodename: Andrews-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,2
2017-01-27 12:25:57.760413 yalu102[854:178086] found corruption 38003
2017-01-27 12:25:58.476276 yalu102[854:178086] found kernel text at fffffff00a004000
2017-01-27 12:25:58.478631 yalu102[854:178086] got tfp0 -> 1207
2017-01-27 12:25:58.480478 yalu102[854:178086] found procs at fffffff10b06e020
2017-01-27 12:25:58.485402 yalu102[854:178086] seg: __TEXT
2017-01-27 12:25:58.485498 yalu102[854:178086] seg: __DATA_CONST
2017-01-27 12:25:58.485532 yalu102[854:178086] seg: __TEXT_EXEC
2017-01-27 12:25:58.485566 yalu102[854:178086] seg: __KLD
2017-01-27 12:25:58.485598 yalu102[854:178086] seg: __LAST
2017-01-27 12:25:58.485629 yalu102[854:178086] seg: __DATA
2017-01-27 12:25:58.485660 yalu102[854:178086] seg: __PRELINK_TEXT
2017-01-27 12:25:58.485721 yalu102[854:178086] seg: __PLK_TEXT_EXEC
2017-01-27 12:25:58.485851 yalu102[854:178086] seg: __PRELINK_DATA
2017-01-27 12:25:58.485886 yalu102[854:178086] seg: __PLK_DATA_CONST
2017-01-27 12:25:58.485918 yalu102[854:178086] seg: __PLK_LINKEDIT
2017-01-27 12:25:58.485950 yalu102[854:178086] seg: __PRELINK_INFO
2017-01-27 12:25:58.485982 yalu102[854:178086] seg: __LINKEDIT
2017-01-27 12:25:58.486015 yalu102[854:178086] fffffff0090cc000 - fffffff00a894000
2017-01-27 12:25:58.544741 yalu102[854:178086] ffffffff03d98000
2017-01-27 12:25:58.591398 yalu102[854:178086] fffffff00a0715a0
2017-01-27 12:25:58.630298 yalu102[854:178086] pmap: fffffff00a520850
2017-01-27 12:25:58.669476 yalu102[854:178086] got phys at 0 for virt fffffff120f88000
2017-01-27 12:25:58.669623 yalu102[854:178086] found cpu 0
2017-01-27 12:25:58.669697 yalu102[854:178086] found physz: fffffff00a093000
2017-01-27 12:25:58.669741 yalu102[854:178086] found cpu 1
2017-01-27 12:25:58.669768 yalu102[854:178086] found physz: fffffff00a093000
2017-01-27 12:25:58.669882 yalu102[854:178086] fffffff00a193574 - fffffff00a1933a8
Can you try adding the debug statements I did?
I changed the wrong thing, give me a second I'm running again after i changed the right thing
this was the output after changing the right thing:
sysname: Darwin
nodename: Andrews-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,2
2017-01-27 12:31:50.903002 yalu102[235:4659] found corruption 38203
2017-01-27 12:31:55.836549 yalu102[235:4659] found kernel text at fffffff01be04000
2017-01-27 12:31:55.838888 yalu102[235:4659] got tfp0 -> d07
2017-01-27 12:31:55.839426 yalu102[235:4659] found procs at fffffff004e24810
2017-01-27 12:31:55.844557 yalu102[235:4659] seg: __TEXT
2017-01-27 12:31:55.844653 yalu102[235:4659] seg: __DATA_CONST
2017-01-27 12:31:55.844688 yalu102[235:4659] seg: __TEXT_EXEC
2017-01-27 12:31:55.844776 yalu102[235:4659] seg: __KLD
2017-01-27 12:31:55.844816 yalu102[235:4659] seg: __LAST
2017-01-27 12:31:55.844849 yalu102[235:4659] seg: __DATA
2017-01-27 12:31:55.844882 yalu102[235:4659] seg: __PRELINK_TEXT
2017-01-27 12:31:55.845092 yalu102[235:4659] seg: __PLK_TEXT_EXEC
2017-01-27 12:31:55.845129 yalu102[235:4659] seg: __PRELINK_DATA
2017-01-27 12:31:55.845297 yalu102[235:4659] seg: __PLK_DATA_CONST
2017-01-27 12:31:55.845333 yalu102[235:4659] seg: __PLK_LINKEDIT
2017-01-27 12:31:55.845366 yalu102[235:4659] seg: __PRELINK_INFO
2017-01-27 12:31:55.845437 yalu102[235:4659] seg: __LINKEDIT
2017-01-27 12:31:55.845489 yalu102[235:4659] fffffff01aecc000 - fffffff01c694000
2017-01-27 12:31:55.899988 yalu102[235:4659] ffffffff03d9c000
2017-01-27 12:31:55.944697 yalu102[235:4659] fffffff01be715a0
2017-01-27 12:31:55.983353 yalu102[235:4659] pmap: fffffff01c320850
2017-01-27 12:31:56.022341 yalu102[235:4659] got phys at 0 for virt fffffff000824000
2017-01-27 12:31:56.022479 yalu102[235:4659] found cpu 0
2017-01-27 12:31:56.022553 yalu102[235:4659] found physz: fffffff01be93000
2017-01-27 12:31:56.022591 yalu102[235:4659] found cpu 1
2017-01-27 12:31:56.022620 yalu102[235:4659] found physz: fffffff01be93000
2017-01-27 12:31:56.022833 yalu102[235:4659] fffffff01bf93574 - fffffff01bf933a8
2017-01-27 12:31:56.024233 yalu102[235:4659] ttbr0: 802ab9000 fffffff01be71590
2017-01-27 12:31:56.025501 yalu102[235:4659] got a cpacr
ok, that's what we got before so that specifically didn't help.
wait, am I replacing the level in pte or jailbreak.m?
try my branch with that change please: https://github.com/meyer9/yalu102
I have some debug statements added
This is what i got when i change it
sysname: Darwin
nodename: Keirs-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,1
2017-01-27 17:33:16.456749 yalu102[235:5155] found corruption 37c03
2017-01-27 17:33:21.304816 yalu102[235:5155] found kernel text at fffffff01bc04000
2017-01-27 17:33:21.306975 yalu102[235:5155] got tfp0 -> 1207
2017-01-27 17:33:21.308431 yalu102[235:5155] found procs at fffffff0047b7408
2017-01-27 17:33:21.312822 yalu102[235:5155] seg: __TEXT
2017-01-27 17:33:21.312899 yalu102[235:5155] seg: __DATA_CONST
2017-01-27 17:33:21.312935 yalu102[235:5155] seg: __TEXT_EXEC
2017-01-27 17:33:21.312968 yalu102[235:5155] seg: __KLD
2017-01-27 17:33:21.313001 yalu102[235:5155] seg: __LAST
2017-01-27 17:33:21.313054 yalu102[235:5155] seg: __DATA
2017-01-27 17:33:21.313167 yalu102[235:5155] seg: __PRELINK_TEXT
2017-01-27 17:33:21.313202 yalu102[235:5155] seg: __PLK_TEXT_EXEC
2017-01-27 17:33:21.313234 yalu102[235:5155] seg: __PRELINK_DATA
2017-01-27 17:33:21.313267 yalu102[235:5155] seg: __PLK_DATA_CONST
2017-01-27 17:33:21.313299 yalu102[235:5155] seg: __PLK_LINKEDIT
2017-01-27 17:33:21.313454 yalu102[235:5155] seg: __PRELINK_INFO
2017-01-27 17:33:21.313504 yalu102[235:5155] seg: __LINKEDIT
2017-01-27 17:33:21.313537 yalu102[235:5155] fffffff01accc000 - fffffff01c494000
2017-01-27 17:33:21.366759 yalu102[235:5155] ffffffff03e30000
2017-01-27 17:33:21.413297 yalu102[235:5155] fffffff01bc715a0
2017-01-27 17:33:21.453138 yalu102[235:5155] pmap: fffffff01c120850
2017-01-27 17:33:21.492678 yalu102[235:5155] got phys at 0 for virt fffffff00089f000
2017-01-27 17:33:21.492808 yalu102[235:5155] found cpu 0
2017-01-27 17:33:21.492846 yalu102[235:5155] found physz: fffffff01bc93000
2017-01-27 17:33:21.492882 yalu102[235:5155] found cpu 1
2017-01-27 17:33:21.492910 yalu102[235:5155] found physz: fffffff01bc93000
2017-01-27 17:33:21.492957 yalu102[235:5155] fffffff01bd93574 - fffffff01bd933a8
yeah it crashes at a random point in the log. we already knew that. add exit(0) instead of nslog statements so we can debug exactly where it panics.
@meyer9 can you please please merge your branch so it is not 16 commits behind
yeah 1 sec
done
pulling now
Yalu crashed? I got sent to the homescreen, here is the output:
sysname: Darwin
nodename: Andrews-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,2
2017-01-27 12:42:45.142462 yalu102[242:5523] found corruption 38503
2017-01-27 12:42:46.782259 yalu102[242:5523] found kernel text at fffffff00e004000
2017-01-27 12:42:46.784489 yalu102[242:5523] got tfp0 -> 38603
2017-01-27 12:42:46.786461 yalu102[242:5523] found procs at fffffff10f3c7080
2017-01-27 12:42:46.790893 yalu102[242:5523] seg: __TEXT
2017-01-27 12:42:46.790971 yalu102[242:5523] seg: __DATA_CONST
2017-01-27 12:42:46.791005 yalu102[242:5523] seg: __TEXT_EXEC
2017-01-27 12:42:46.791038 yalu102[242:5523] seg: __KLD
2017-01-27 12:42:46.791070 yalu102[242:5523] seg: __LAST
2017-01-27 12:42:46.791116 yalu102[242:5523] seg: __DATA
2017-01-27 12:42:46.791182 yalu102[242:5523] seg: __PRELINK_TEXT
2017-01-27 12:42:46.791235 yalu102[242:5523] seg: __PLK_TEXT_EXEC
2017-01-27 12:42:46.791268 yalu102[242:5523] seg: __PRELINK_DATA
2017-01-27 12:42:46.791299 yalu102[242:5523] seg: __PLK_DATA_CONST
2017-01-27 12:42:46.791330 yalu102[242:5523] seg: __PLK_LINKEDIT
2017-01-27 12:42:46.791363 yalu102[242:5523] seg: __PRELINK_INFO
2017-01-27 12:42:46.791475 yalu102[242:5523] seg: __LINKEDIT
2017-01-27 12:42:46.791531 yalu102[242:5523] fffffff00d0cc000 - fffffff00e894000
2017-01-27 12:42:46.844824 yalu102[242:5523] 1430803da0000
2017-01-27 12:42:46.887031 yalu102[242:5523] fffffff00e0715a0
2017-01-27 12:42:46.926864 yalu102[242:5523] pmap: fffffff00e520850
2017-01-27 12:42:46.965535 yalu102[242:5523] debug: test point 1
2017-01-27 12:42:46.965668 yalu102[242:5523] debug: test point 2
2017-01-27 12:42:46.965692 yalu102[242:5523] debug: test point 3
2017-01-27 12:42:46.965752 yalu102[242:5523] debug: test point 4
2017-01-27 12:42:46.965786 yalu102[242:5523] debug: test point 5
2017-01-27 12:42:46.965812 yalu102[242:5523] debug: test point 6
2017-01-27 12:42:46.965838 yalu102[242:5523] debug: test point 7
2017-01-27 12:42:46.965954 yalu102[242:5523] Indentified 4k device
2017-01-27 12:42:46.966014 yalu102[242:5523] calling back 18446744005240397312 1
2017-01-27 12:42:46.966045 yalu102[242:5523] calling back 2
2017-01-27 12:42:46.966071 yalu102[242:5523] calling back 3
2017-01-27 12:42:46.966119 yalu102[242:5523] got phys at 0 for virt fffffff000853000
2017-01-27 12:42:46.966326 yalu102[242:5523] found cpu 0
2017-01-27 12:42:46.966373 yalu102[242:5523] found physz: fffffff00e093000
2017-01-27 12:42:46.966408 yalu102[242:5523] found cpu 1
2017-01-27 12:42:46.966435 yalu102[242:5523] found physz: fffffff00e093000
2017-01-27 12:42:46.966483 yalu102[242:5523] fffffff00e193574 - fffffff00e1933a8
2017-01-27 12:42:46.967919 yalu102[242:5523] ttbr0: 802ab9000 fffffff00e071590
2017-01-27 12:42:46.967959 yalu102[242:5523] debug: test point 8
2017-01-27 12:42:46.968006 yalu102[242:5523] debug: test point 9
2017-01-27 12:42:46.968041 yalu102[242:5523] debug: test point 10
2017-01-27 12:42:46.968062 yalu102[242:5523] Indentified 4k device
2017-01-27 12:42:46.968095 yalu102[242:5523] calling back 18446744005240397312 1
2017-01-27 12:42:46.968169 yalu102[242:5523] calling back 2
2017-01-27 12:42:46.968213 yalu102[242:5523] calling back 3
2017-01-27 12:42:46.968235 yalu102[242:5523] debug: test point 11
2017-01-27 12:42:46.968319 yalu102[242:5523] debug: test point 12
2017-01-27 12:42:46.968528 yalu102[242:5523] debug: test point 13
2017-01-27 12:42:46.968596 yalu102[242:5523] debug: test point 14
2017-01-27 12:42:46.968625 yalu102[242:5523] debug: test point 15
2017-01-27 12:42:46.968653 yalu102[242:5523] debug: test point 16
2017-01-27 12:42:46.968692 yalu102[242:5523] debug: test point 17
2017-01-27 12:42:46.968713 yalu102[242:5523] Indentified 4k device
2017-01-27 12:42:46.968749 yalu102[242:5523] calling back 18446744005240397312 1
2017-01-27 12:42:46.968776 yalu102[242:5523] calling back 2
2017-01-27 12:42:46.968802 yalu102[242:5523] calling back 3
2017-01-27 12:42:46.968822 yalu102[242:5523] debug: test point 18
2017-01-27 12:42:46.968960 yalu102[242:5523] got a cpacr at 4462
2017-01-27 12:42:46.968981 yalu102[242:5523] debug ---
2017-01-27 12:42:46.969072 yalu102[242:5523] debug: test point 18z1
2017-01-27 12:42:46.969099 yalu102[242:5523] debug: test point 18z2
2017-01-27 12:42:47.045855 yalu102[242:5523] 18446744005230831720, 205520896
interesting that yours is on level 1 now when it calls back.
is that progress?
A little yeah
Possibly. I'm not an expert on memory management.
I changed this in jailbreak.m
NSLog(@"debug 18h");\
WriteAnywhere64(tte_addr, tte);\
NSLog(@"level %llx - %llx", tte_addr, TTE_GET(tte, TTE_PHYS_VALUE_MASK));\
}, level1_table, 1);
and this in pte.h:
uint64_t findphys_real(uint64_t virtaddr) {
__block uint64_t physvar = 0;
pagestuff_64(virtaddr, ^(vm_address_t tte_addr, int addr) {
uint64_t tte = ReadAnywhere64(tte_addr);
if (addr == 3) {\
physvar = TTE_GET(tte, TTE_PHYS_VALUE_MASK);
}
}, level1_table, 1);
return physvar;
}
this is the output in i only change things in pte.h:
sysname: Darwin
nodename: Andrews-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,2
2017-01-27 12:48:32.535260 yalu102[237:5130] found corruption 37c03
2017-01-27 12:48:36.300431 yalu102[237:5130] found kernel text at fffffff016e04000
2017-01-27 12:48:36.302602 yalu102[237:5130] got tfp0 -> 37d03
2017-01-27 12:48:36.304591 yalu102[237:5130] found procs at fffffff11bce6000
2017-01-27 12:48:36.308989 yalu102[237:5130] seg: __TEXT
2017-01-27 12:48:36.309084 yalu102[237:5130] seg: __DATA_CONST
2017-01-27 12:48:36.309119 yalu102[237:5130] seg: __TEXT_EXEC
2017-01-27 12:48:36.309159 yalu102[237:5130] seg: __KLD
2017-01-27 12:48:36.309190 yalu102[237:5130] seg: __LAST
2017-01-27 12:48:36.309221 yalu102[237:5130] seg: __DATA
2017-01-27 12:48:36.309252 yalu102[237:5130] seg: __PRELINK_TEXT
2017-01-27 12:48:36.309284 yalu102[237:5130] seg: __PLK_TEXT_EXEC
2017-01-27 12:48:36.309364 yalu102[237:5130] seg: __PRELINK_DATA
2017-01-27 12:48:36.309405 yalu102[237:5130] seg: __PLK_DATA_CONST
2017-01-27 12:48:36.309438 yalu102[237:5130] seg: __PLK_LINKEDIT
2017-01-27 12:48:36.309470 yalu102[237:5130] seg: __PRELINK_INFO
2017-01-27 12:48:36.309502 yalu102[237:5130] seg: __LINKEDIT
2017-01-27 12:48:36.309534 yalu102[237:5130] fffffff015ecc000 - fffffff017694000
2017-01-27 12:48:36.362998 yalu102[237:5130] 1430803d8c000
2017-01-27 12:48:36.404506 yalu102[237:5130] fffffff016e715a0
2017-01-27 12:48:36.443277 yalu102[237:5130] pmap: fffffff017320850
2017-01-27 12:48:36.482480 yalu102[237:5130] debug: test point 1
2017-01-27 12:48:36.482610 yalu102[237:5130] debug: test point 2
2017-01-27 12:48:36.482634 yalu102[237:5130] debug: test point 3
2017-01-27 12:48:36.482689 yalu102[237:5130] debug: test point 4
2017-01-27 12:48:36.482722 yalu102[237:5130] debug: test point 5
2017-01-27 12:48:36.482749 yalu102[237:5130] debug: test point 6
2017-01-27 12:48:36.482774 yalu102[237:5130] debug: test point 7
2017-01-27 12:48:36.482883 yalu102[237:5130] Indentified 4k device
2017-01-27 12:48:36.482922 yalu102[237:5130] calling back 18446744005389295104 1
2017-01-27 12:48:36.482982 yalu102[237:5130] calling back 2
2017-01-27 12:48:36.483020 yalu102[237:5130] calling back 3
2017-01-27 12:48:36.483074 yalu102[237:5130] got phys at 0 for virt fffffff000867000
2017-01-27 12:48:36.483200 yalu102[237:5130] found cpu 0
2017-01-27 12:48:36.483234 yalu102[237:5130] found physz: fffffff016e93000
2017-01-27 12:48:36.483269 yalu102[237:5130] found cpu 1
2017-01-27 12:48:36.483296 yalu102[237:5130] found physz: fffffff016e93000
2017-01-27 12:48:36.483347 yalu102[237:5130] fffffff016f93574 - fffffff016f933a8
2017-01-27 12:48:36.484836 yalu102[237:5130] ttbr0: 802ab9000 fffffff016e71590
2017-01-27 12:48:36.484884 yalu102[237:5130] debug: test point 8
2017-01-27 12:48:36.484917 yalu102[237:5130] debug: test point 9
2017-01-27 12:48:36.484956 yalu102[237:5130] debug: test point 10
2017-01-27 12:48:36.484976 yalu102[237:5130] Indentified 4k device
2017-01-27 12:48:36.485008 yalu102[237:5130] calling back 18446744005389295104 1
2017-01-27 12:48:36.485071 yalu102[237:5130] calling back 2
2017-01-27 12:48:36.485098 yalu102[237:5130] calling back 3
2017-01-27 12:48:36.485118 yalu102[237:5130] debug: test point 11
2017-01-27 12:48:36.485180 yalu102[237:5130] debug: test point 12
2017-01-27 12:48:36.485332 yalu102[237:5130] debug: test point 13
2017-01-27 12:48:36.485460 yalu102[237:5130] debug: test point 14
2017-01-27 12:48:36.485489 yalu102[237:5130] debug: test point 15
2017-01-27 12:48:36.485516 yalu102[237:5130] debug: test point 16
2017-01-27 12:48:36.485569 yalu102[237:5130] debug: test point 17
2017-01-27 12:48:36.485592 yalu102[237:5130] Indentified 4k device
2017-01-27 12:48:36.485624 yalu102[237:5130] calling back 18446744005389295104 1
2017-01-27 12:48:36.485762 yalu102[237:5130] calling back 2
2017-01-27 12:48:36.485816 yalu102[237:5130] calling back 3
2017-01-27 12:48:36.485839 yalu102[237:5130] debug: test point 18
2017-01-27 12:48:36.485990 yalu102[237:5130] got a cpacr at 4462
2017-01-27 12:48:36.486014 yalu102[237:5130] debug ---
2017-01-27 12:48:36.486035 yalu102[237:5130] debug: test point 18z1
2017-01-27 12:48:36.486055 yalu102[237:5130] debug: test point 18z2
2017-01-27 12:48:36.563533 yalu102[237:5130] 18446744005379729512, 354418688
OK, nevermind. That's pretty expected since it's just passed through, but I'd experiment with those different values.
I'm 99% sure the panic is happening on this line though: WriteAnywhere64(ReadAnywhere64(find_kernel_pmap()), level1_table);
Can we somehow find a level2_table?
With what different values?
I believe that it should be WriteAnywhere64(ReadAnywhere64(find_kernel_pmap()), level2_table); but we need to find level2_table somehow.
level1_table = physp - gPhysBase + gVirtBase; <-- somehow find level2
@kpwn any suggestions here?
here's some code from some random person that may help:
u64 section_l1t0, section_l1t1, section_l2t0, section_l2t1;
u64 *level0_table = (u64 *)CONFIG_SYS_FSL_OCRAM_BASE;
u64 *level1_table_0 = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x1000);
u64 *level1_table_1 = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x2000);
u64 *level2_table = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x3000);
u64 *level2_table_0 = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x3000);
u64 *level2_table_1 = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x4000);
so where should I stick this?
possibly here: copyout(level0_pte, bbuf, isvad == 0 ? 0x4000 : 0x1000); -> copyout(level0_pte, bbuf, 0x3000?); The argument needs to be different maybe? That's what level1_table is derived from.
output:
sysname: Darwin
nodename: Andrews-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,2
2017-01-27 13:02:11.238356 yalu102[261:8500] found corruption 37d03
2017-01-27 13:02:15.359192 yalu102[261:8500] found kernel text at fffffff016e04000
2017-01-27 13:02:15.361352 yalu102[261:8500] got tfp0 -> 37f03
2017-01-27 13:02:15.361718 yalu102[261:8500] found procs at fffffff119c24468
2017-01-27 13:02:15.365968 yalu102[261:8500] seg: __TEXT
2017-01-27 13:02:15.366047 yalu102[261:8500] seg: __DATA_CONST
2017-01-27 13:02:15.366089 yalu102[261:8500] seg: __TEXT_EXEC
2017-01-27 13:02:15.366122 yalu102[261:8500] seg: __KLD
2017-01-27 13:02:15.366233 yalu102[261:8500] seg: __LAST
2017-01-27 13:02:15.366296 yalu102[261:8500] seg: __DATA
2017-01-27 13:02:15.366331 yalu102[261:8500] seg: __PRELINK_TEXT
2017-01-27 13:02:15.366365 yalu102[261:8500] seg: __PLK_TEXT_EXEC
2017-01-27 13:02:15.366397 yalu102[261:8500] seg: __PRELINK_DATA
2017-01-27 13:02:15.366429 yalu102[261:8500] seg: __PLK_DATA_CONST
2017-01-27 13:02:15.366461 yalu102[261:8500] seg: __PLK_LINKEDIT
2017-01-27 13:02:15.366554 yalu102[261:8500] seg: __PRELINK_INFO
2017-01-27 13:02:15.366632 yalu102[261:8500] seg: __LINKEDIT
2017-01-27 13:02:15.366664 yalu102[261:8500] fffffff015ecc000 - fffffff017694000
2017-01-27 13:02:15.436597 yalu102[261:8500] 1430803da0000
2017-01-27 13:02:15.479727 yalu102[261:8500] fffffff016e715a0
2017-01-27 13:02:15.525128 yalu102[261:8500] pmap: fffffff017320850
2017-01-27 13:02:15.568142 yalu102[261:8500] debug: test point 1
2017-01-27 13:02:15.568275 yalu102[261:8500] debug: test point 2
2017-01-27 13:02:15.568299 yalu102[261:8500] debug: test point 3
2017-01-27 13:02:15.568362 yalu102[261:8500] debug: test point 4
2017-01-27 13:02:15.568397 yalu102[261:8500] debug: test point 5
2017-01-27 13:02:15.568424 yalu102[261:8500] debug: test point 6
2017-01-27 13:02:15.568450 yalu102[261:8500] debug: test point 7
2017-01-27 13:02:15.568500 yalu102[261:8500] Indentified 4k device
2017-01-27 13:02:15.568541 yalu102[261:8500] calling back 18446744005389295104 1
2017-01-27 13:02:15.568571 yalu102[261:8500] calling back 2
2017-01-27 13:02:15.568599 yalu102[261:8500] calling back 3
2017-01-27 13:02:15.568647 yalu102[261:8500] got phys at 0 for virt fffffff000896000
2017-01-27 13:02:15.568748 yalu102[261:8500] found cpu 0
2017-01-27 13:02:15.568781 yalu102[261:8500] found physz: fffffff016e93000
2017-01-27 13:02:15.568815 yalu102[261:8500] found cpu 1
2017-01-27 13:02:15.568843 yalu102[261:8500] found physz: fffffff016e93000
2017-01-27 13:02:15.568947 yalu102[261:8500] fffffff016f93574 - fffffff016f933a8
2017-01-27 13:02:15.571206 yalu102[261:8500] ttbr0: 802ab9000 fffffff016e71590
2017-01-27 13:02:15.571266 yalu102[261:8500] debug: test point 8
2017-01-27 13:02:15.571313 yalu102[261:8500] debug: test point 9
2017-01-27 13:02:15.571356 yalu102[261:8500] debug: test point 10
2017-01-27 13:02:15.571378 yalu102[261:8500] Indentified 4k device
2017-01-27 13:02:15.571413 yalu102[261:8500] calling back 18446744005389295104 1
2017-01-27 13:02:15.571494 yalu102[261:8500] calling back 2
2017-01-27 13:02:15.571544 yalu102[261:8500] calling back 3
2017-01-27 13:02:15.571565 yalu102[261:8500] debug: test point 11
2017-01-27 13:02:15.571697 yalu102[261:8500] debug: test point 12
2017-01-27 13:02:15.571855 yalu102[261:8500] debug: test point 13
2017-01-27 13:02:15.571921 yalu102[261:8500] debug: test point 14
2017-01-27 13:02:15.571948 yalu102[261:8500] debug: test point 15
2017-01-27 13:02:15.572002 yalu102[261:8500] debug: test point 16
2017-01-27 13:02:15.572056 yalu102[261:8500] debug: test point 17
2017-01-27 13:02:15.572080 yalu102[261:8500] Indentified 4k device
2017-01-27 13:02:15.572114 yalu102[261:8500] calling back 18446744005389295104 1
2017-01-27 13:02:15.572142 yalu102[261:8500] calling back 2
2017-01-27 13:02:15.572168 yalu102[261:8500] calling back 3
2017-01-27 13:02:15.572207 yalu102[261:8500] debug: test point 18
2017-01-27 13:02:15.572372 yalu102[261:8500] got a cpacr at 4462
2017-01-27 13:02:15.572471 yalu102[261:8500] debug ---
2017-01-27 13:02:15.572807 yalu102[261:8500] debug: test point 18z1
2017-01-27 13:02:15.572832 yalu102[261:8500] debug: test point 18z2
2017-01-27 13:02:15.659659 yalu102[261:8500] 18446744005379729512, 354418688
if I remove the exit 0 and remove the changed copy out this is my output:
sysname: Darwin
nodename: Andrews-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,2
2017-01-27 13:07:39.240015 yalu102[238:4734] found corruption 1407
2017-01-27 13:07:43.390688 yalu102[238:4734] found kernel text at fffffff017804000
2017-01-27 13:07:43.392884 yalu102[238:4734] got tfp0 -> 1807
2017-01-27 13:07:43.394518 yalu102[238:4734] found procs at fffffff11a862c58
2017-01-27 13:07:43.398977 yalu102[238:4734] seg: __TEXT
2017-01-27 13:07:43.399049 yalu102[238:4734] seg: __DATA_CONST
2017-01-27 13:07:43.399083 yalu102[238:4734] seg: __TEXT_EXEC
2017-01-27 13:07:43.399116 yalu102[238:4734] seg: __KLD
2017-01-27 13:07:43.399148 yalu102[238:4734] seg: __LAST
2017-01-27 13:07:43.399179 yalu102[238:4734] seg: __DATA
2017-01-27 13:07:43.399273 yalu102[238:4734] seg: __PRELINK_TEXT
2017-01-27 13:07:43.399326 yalu102[238:4734] seg: __PLK_TEXT_EXEC
2017-01-27 13:07:43.399357 yalu102[238:4734] seg: __PRELINK_DATA
2017-01-27 13:07:43.399389 yalu102[238:4734] seg: __PLK_DATA_CONST
2017-01-27 13:07:43.399420 yalu102[238:4734] seg: __PLK_LINKEDIT
2017-01-27 13:07:43.399452 yalu102[238:4734] seg: __PRELINK_INFO
2017-01-27 13:07:43.399604 yalu102[238:4734] seg: __LINKEDIT
2017-01-27 13:07:43.399647 yalu102[238:4734] fffffff0168cc000 - fffffff018094000
2017-01-27 13:07:43.456144 yalu102[238:4734] ffffffff03d90000
2017-01-27 13:07:43.504138 yalu102[238:4734] fffffff0178715a0
2017-01-27 13:07:43.542812 yalu102[238:4734] pmap: fffffff017d20850
2017-01-27 13:07:43.581285 yalu102[238:4734] debug: test point 1
2017-01-27 13:07:43.581408 yalu102[238:4734] debug: test point 2
2017-01-27 13:07:43.581431 yalu102[238:4734] debug: test point 3
2017-01-27 13:07:43.581490 yalu102[238:4734] debug: test point 4
2017-01-27 13:07:43.581524 yalu102[238:4734] debug: test point 5
2017-01-27 13:07:43.581551 yalu102[238:4734] debug: test point 6
2017-01-27 13:07:43.581577 yalu102[238:4734] debug: test point 7
2017-01-27 13:07:43.581597 yalu102[238:4734] Indentified 4k device
2017-01-27 13:07:43.581700 yalu102[238:4734] calling back 18446744005399780864 1
2017-01-27 13:07:43.581731 yalu102[238:4734] calling back 2
2017-01-27 13:07:43.581757 yalu102[238:4734] calling back 3
2017-01-27 13:07:43.581818 yalu102[238:4734] got phys at 0 for virt fffffff0008a2000
2017-01-27 13:07:43.581898 yalu102[238:4734] found cpu 0
2017-01-27 13:07:43.581926 yalu102[238:4734] found physz: fffffff017893000
2017-01-27 13:07:43.582054 yalu102[238:4734] found cpu 1
2017-01-27 13:07:43.582096 yalu102[238:4734] found physz: fffffff017893000
2017-01-27 13:07:43.582160 yalu102[238:4734] fffffff017993574 - fffffff0179933a8
2017-01-27 13:07:43.583539 yalu102[238:4734] ttbr0: 802ab9000 fffffff017871590
2017-01-27 13:07:43.583576 yalu102[238:4734] debug: test point 8
2017-01-27 13:07:43.583619 yalu102[238:4734] debug: test point 9
2017-01-27 13:07:43.583653 yalu102[238:4734] debug: test point 10
2017-01-27 13:07:43.583703 yalu102[238:4734] Indentified 4k device
2017-01-27 13:07:43.583779 yalu102[238:4734] calling back 18446744005399780864 1
2017-01-27 13:07:43.583866 yalu102[238:4734] calling back 2
2017-01-27 13:07:43.583904 yalu102[238:4734] calling back 3
2017-01-27 13:07:43.583926 yalu102[238:4734] debug: test point 11
2017-01-27 13:07:43.583991 yalu102[238:4734] debug: test point 12
2017-01-27 13:07:43.584144 yalu102[238:4734] debug: test point 13
2017-01-27 13:07:43.584252 yalu102[238:4734] debug: test point 14
2017-01-27 13:07:43.584287 yalu102[238:4734] debug: test point 15
2017-01-27 13:07:43.584316 yalu102[238:4734] debug: test point 16
2017-01-27 13:07:43.584354 yalu102[238:4734] debug: test point 17
2017-01-27 13:07:43.584467 yalu102[238:4734] Indentified 4k device
2017-01-27 13:07:43.584521 yalu102[238:4734] calling back 18446744005399780864 1
2017-01-27 13:07:43.584551 yalu102[238:4734] calling back 2
2017-01-27 13:07:43.584577 yalu102[238:4734] calling back 3
2017-01-27 13:07:43.584598 yalu102[238:4734] debug: test point 18
2017-01-27 13:07:43.584745 yalu102[238:4734] got a cpacr at 4462
2017-01-27 13:07:43.584767 yalu102[238:4734] debug ---
2017-01-27 13:07:43.584787 yalu102[238:4734] debug: test point 18z1
2017-01-27 13:07:43.584806 yalu102[238:4734] debug: test point 18z2
2017-01-27 13:07:43.662436 yalu102[238:4734] 18446744005390215272, 364904448
2017-01-27 13:07:43.662510 yalu102[238:4734] debug: test point 19
2017-01-27 13:07:43.662569 yalu102[238:4734] debug: test point 19a
2017-01-27 13:07:43.662591 yalu102[238:4734] debug 18*
2017-01-27 13:07:43.662613 yalu102[238:4734] Indentified 4k device
2017-01-27 13:07:43.662646 yalu102[238:4734] calling back 18446743970995244544 1
updated my logs with stuff it gets to 19 now
any other ideas? @meyer9
no, but sometimes it got to 19 for me too. the log crashes at some point after that writeanywhere call.
findphys_real must be changed as well.
uint64_t findphys_real(uint64_t virtaddr) {
__block uint64_t physvar = 0;
pagestuff_64(virtaddr, ^(vm_address_t tte_addr, int addr) {
uint64_t tte = ReadAnywhere64(tte_addr);
if (addr == 3) {\
physvar = TTE_GET(tte, TTE_PHYS_VALUE_MASK);
}
}, level1_table, 2);
return physvar;
}
I did change that
also the one in RemapPage? try different level values as well.
nevermind saw your other comment
Yes, I changed both, so what other levels would you suggest, like give me range
again, this is just a wild guess, but 0-4
0-3 I would assume they are cases for pte.h
yeah maybe
output for 3:
sysname: Darwin
nodename: Andrews-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,2
2017-01-27 14:19:15.555351 yalu102[238:5588] found corruption 37d03
2017-01-27 14:19:16.655918 yalu102[238:5588] found kernel text at fffffff00ba04000
2017-01-27 14:19:16.658090 yalu102[238:5588] got tfp0 -> 37e03
2017-01-27 14:19:16.660025 yalu102[238:5588] found procs at fffffff10fe33830
2017-01-27 14:19:16.664354 yalu102[238:5588] seg: __TEXT
2017-01-27 14:19:16.664450 yalu102[238:5588] seg: __DATA_CONST
2017-01-27 14:19:16.664485 yalu102[238:5588] seg: __TEXT_EXEC
2017-01-27 14:19:16.664525 yalu102[238:5588] seg: __KLD
2017-01-27 14:19:16.664566 yalu102[238:5588] seg: __LAST
2017-01-27 14:19:16.664598 yalu102[238:5588] seg: __DATA
2017-01-27 14:19:16.664629 yalu102[238:5588] seg: __PRELINK_TEXT
2017-01-27 14:19:16.664661 yalu102[238:5588] seg: __PLK_TEXT_EXEC
2017-01-27 14:19:16.664692 yalu102[238:5588] seg: __PRELINK_DATA
2017-01-27 14:19:16.664724 yalu102[238:5588] seg: __PLK_DATA_CONST
2017-01-27 14:19:16.664797 yalu102[238:5588] seg: __PLK_LINKEDIT
2017-01-27 14:19:16.664848 yalu102[238:5588] seg: __PRELINK_INFO
2017-01-27 14:19:16.664883 yalu102[238:5588] seg: __LINKEDIT
2017-01-27 14:19:16.664916 yalu102[238:5588] fffffff00aacc000 - fffffff00c294000
2017-01-27 14:19:16.718738 yalu102[238:5588] 1430803d8c000
2017-01-27 14:19:16.761309 yalu102[238:5588] fffffff00ba715a0
2017-01-27 14:19:16.800063 yalu102[238:5588] pmap: fffffff00bf20850
2017-01-27 14:19:16.838512 yalu102[238:5588] debug: test point 1
2017-01-27 14:19:16.838651 yalu102[238:5588] debug: test point 2
2017-01-27 14:19:16.838674 yalu102[238:5588] debug: test point 3
2017-01-27 14:19:16.838735 yalu102[238:5588] debug: test point 4
2017-01-27 14:19:16.838768 yalu102[238:5588] debug: test point 5
2017-01-27 14:19:16.838795 yalu102[238:5588] debug: test point 6
2017-01-27 14:19:16.838820 yalu102[238:5588] debug: test point 7
2017-01-27 14:19:16.838943 yalu102[238:5588] Indentified 4k device
2017-01-27 14:19:16.839005 yalu102[238:5588] calling back 18446744005200547992 3
2017-01-27 14:19:16.839034 yalu102[238:5588] calling back 2
2017-01-27 14:19:16.839060 yalu102[238:5588] calling back 3
2017-01-27 14:19:16.839110 yalu102[238:5588] got phys at 0 for virt fffffff000813000
2017-01-27 14:19:16.839312 yalu102[238:5588] found cpu 0
2017-01-27 14:19:16.839382 yalu102[238:5588] found physz: fffffff00ba93000
2017-01-27 14:19:16.839418 yalu102[238:5588] found cpu 1
2017-01-27 14:19:16.839444 yalu102[238:5588] found physz: fffffff00ba93000
2017-01-27 14:19:16.839490 yalu102[238:5588] fffffff00bb93574 - fffffff00bb933a8
2017-01-27 14:19:16.840962 yalu102[238:5588] ttbr0: 802ab9000 fffffff00ba71590
2017-01-27 14:19:16.841008 yalu102[238:5588] debug: test point 8
2017-01-27 14:19:16.841043 yalu102[238:5588] debug: test point 9
2017-01-27 14:19:16.841075 yalu102[238:5588] debug: test point 10
2017-01-27 14:19:16.841096 yalu102[238:5588] Indentified 4k device
2017-01-27 14:19:16.841143 yalu102[238:5588] calling back 18446744005200548216 3
2017-01-27 14:19:16.841211 yalu102[238:5588] calling back 2
2017-01-27 14:19:16.841238 yalu102[238:5588] calling back 3
2017-01-27 14:19:16.841259 yalu102[238:5588] debug: test point 11
2017-01-27 14:19:16.841321 yalu102[238:5588] debug: test point 12
2017-01-27 14:19:16.841536 yalu102[238:5588] debug: test point 13
2017-01-27 14:19:16.841591 yalu102[238:5588] debug: test point 14
2017-01-27 14:19:16.841618 yalu102[238:5588] debug: test point 15
2017-01-27 14:19:16.841644 yalu102[238:5588] debug: test point 16
2017-01-27 14:19:16.841747 yalu102[238:5588] debug: test point 17
2017-01-27 14:19:16.841789 yalu102[238:5588] Indentified 4k device
2017-01-27 14:19:16.841825 yalu102[238:5588] calling back 18446744005200548224 3
2017-01-27 14:19:16.841855 yalu102[238:5588] calling back 2
2017-01-27 14:19:16.841881 yalu102[238:5588] calling back 3
2017-01-27 14:19:16.841902 yalu102[238:5588] debug: test point 18
2017-01-27 14:19:16.842047 yalu102[238:5588] got a cpacr at 4462
2017-01-27 14:19:16.842069 yalu102[238:5588] debug ---
2017-01-27 14:19:16.842089 yalu102[238:5588] debug: test point 18z1
2017-01-27 14:19:16.842108 yalu102[238:5588] debug: test point 18z2
2017-01-27 14:19:16.919373 yalu102[238:5588] 18446744005190985832, 165675008
none of the others worked either btw
@meyer9 Here's another log, in case it helps you out. iPhone 6. Commit hash meyer9/7119956.
sysname: Darwin
nodename: Justins-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,2
2017-01-27 14:41:33.108588 yalu102[1044:256504] found corruption 38503
2017-01-27 14:41:34.313414 yalu102[1044:256504] found kernel text at fffffff00c204000
2017-01-27 14:41:34.315633 yalu102[1044:256504] got tfp0 -> 38603
2017-01-27 14:41:34.317190 yalu102[1044:256504] found procs at fffffff11034e0a0
2017-01-27 14:41:34.321773 yalu102[1044:256504] seg: __TEXT
2017-01-27 14:41:34.321863 yalu102[1044:256504] seg: __DATA_CONST
2017-01-27 14:41:34.321898 yalu102[1044:256504] seg: __TEXT_EXEC
2017-01-27 14:41:34.321957 yalu102[1044:256504] seg: __KLD
2017-01-27 14:41:34.322059 yalu102[1044:256504] seg: __LAST
2017-01-27 14:41:34.322212 yalu102[1044:256504] seg: __DATA
2017-01-27 14:41:34.322271 yalu102[1044:256504] seg: __PRELINK_TEXT
2017-01-27 14:41:34.322305 yalu102[1044:256504] seg: __PLK_TEXT_EXEC
2017-01-27 14:41:34.322383 yalu102[1044:256504] seg: __PRELINK_DATA
2017-01-27 14:41:34.322440 yalu102[1044:256504] seg: __PLK_DATA_CONST
2017-01-27 14:41:34.322474 yalu102[1044:256504] seg: __PLK_LINKEDIT
2017-01-27 14:41:34.322505 yalu102[1044:256504] seg: __PRELINK_INFO
2017-01-27 14:41:34.322537 yalu102[1044:256504] seg: __LINKEDIT
2017-01-27 14:41:34.322645 yalu102[1044:256504] fffffff00b2cc000 - fffffff00ca94000
2017-01-27 14:41:34.380066 yalu102[1044:256504] 1430803da0000
2017-01-27 14:41:34.428322 yalu102[1044:256504] fffffff00c2715a0
2017-01-27 14:41:34.467878 yalu102[1044:256504] pmap: fffffff00c720850
2017-01-27 14:41:34.509845 yalu102[1044:256504] debug: test point 1
2017-01-27 14:41:34.510014 yalu102[1044:256504] debug: test point 2
2017-01-27 14:41:34.510036 yalu102[1044:256504] debug: test point 3
2017-01-27 14:41:34.510085 yalu102[1044:256504] debug: test point 4
2017-01-27 14:41:34.510118 yalu102[1044:256504] debug: test point 5
2017-01-27 14:41:34.510146 yalu102[1044:256504] debug: test point 6
2017-01-27 14:41:34.510172 yalu102[1044:256504] debug: test point 7
2017-01-27 14:41:34.510221 yalu102[1044:256504] Indentified 4k device
2017-01-27 14:41:34.510263 yalu102[1044:256504] calling back 18446744005208936480 2
2017-01-27 14:41:34.510290 yalu102[1044:256504] calling back 2
2017-01-27 14:41:34.510316 yalu102[1044:256504] calling back 3
2017-01-27 14:41:34.510335 yalu102[1044:256504] calling back 4
2017-01-27 14:41:34.510355 yalu102[1044:256504] Indentified 4k device
2017-01-27 14:41:34.510386 yalu102[1044:256504] calling back 18446744005208990848 3
2017-01-27 14:41:34.510413 yalu102[1044:256504] calling back 2
2017-01-27 14:41:34.510475 yalu102[1044:256504] calling back 3
2017-01-27 14:41:34.510496 yalu102[1044:256504] calling back 5
2017-01-27 14:41:34.510550 yalu102[1044:256504] got phys at 80e652000 for virt fffffff000890000
2017-01-27 14:41:34.510652 yalu102[1044:256504] found cpu 0
2017-01-27 14:41:34.510681 yalu102[1044:256504] found physz: fffffff00c293000
2017-01-27 14:41:34.510715 yalu102[1044:256504] found cpu 1
2017-01-27 14:41:34.510742 yalu102[1044:256504] found physz: fffffff00c293000
2017-01-27 14:41:34.510814 yalu102[1044:256504] fffffff00c393574 - fffffff00c3933a8
2017-01-27 14:41:34.512092 yalu102[1044:256504] ttbr0: 802ab9000 fffffff00c271590
2017-01-27 14:41:34.512136 yalu102[1044:256504] debug: test point 8
2017-01-27 14:41:34.512189 yalu102[1044:256504] debug: test point 9
2017-01-27 14:41:34.512224 yalu102[1044:256504] debug: test point 10
2017-01-27 14:41:34.512245 yalu102[1044:256504] Indentified 4k device
2017-01-27 14:41:34.512278 yalu102[1044:256504] calling back 18446744005208936480 2
2017-01-27 14:41:34.513136 yalu102[1044:256504] calling back 2
2017-01-27 14:41:34.513171 yalu102[1044:256504] calling back 3
2017-01-27 14:41:34.513191 yalu102[1044:256504] calling back 4
2017-01-27 14:41:34.513210 yalu102[1044:256504] Indentified 4k device
2017-01-27 14:41:34.513243 yalu102[1044:256504] calling back 18446744005208992136 3
2017-01-27 14:41:34.513517 yalu102[1044:256504] calling back 2
2017-01-27 14:41:34.513566 yalu102[1044:256504] calling back 3
2017-01-27 14:41:34.513589 yalu102[1044:256504] calling back 5
2017-01-27 14:41:34.513631 yalu102[1044:256504] debug: test point 11
2017-01-27 14:41:34.513700 yalu102[1044:256504] debug: test point 12
2017-01-27 14:41:34.513841 yalu102[1044:256504] debug: test point 13
2017-01-27 14:41:34.513910 yalu102[1044:256504] debug: test point 14
2017-01-27 14:41:34.513938 yalu102[1044:256504] debug: test point 15
2017-01-27 14:41:34.513966 yalu102[1044:256504] debug: test point 16
2017-01-27 14:41:34.514001 yalu102[1044:256504] debug: test point 17
2017-01-27 14:41:34.514093 yalu102[1044:256504] Indentified 4k device
2017-01-27 14:41:34.514127 yalu102[1044:256504] calling back 18446744005208936480 2
2017-01-27 14:41:34.514153 yalu102[1044:256504] calling back 2
2017-01-27 14:41:34.514179 yalu102[1044:256504] calling back 3
2017-01-27 14:41:34.514198 yalu102[1044:256504] calling back 4
2017-01-27 14:41:34.514320 yalu102[1044:256504] Indentified 4k device
2017-01-27 14:41:34.514358 yalu102[1044:256504] calling back 18446744005208992144 3
2017-01-27 14:41:34.514386 yalu102[1044:256504] calling back 2
2017-01-27 14:41:34.514412 yalu102[1044:256504] calling back 3
2017-01-27 14:41:34.514451 yalu102[1044:256504] calling back 5
2017-01-27 14:41:34.514475 yalu102[1044:256504] debug: test point 18
2017-01-27 14:41:34.514694 yalu102[1044:256504] got a cpacr at 4462
2017-01-27 14:41:34.514718 yalu102[1044:256504] debug ---
2017-01-27 14:41:34.514737 yalu102[1044:256504] debug: test point 18z1
2017-01-27 14:41:34.514776 yalu102[1044:256504] debug: test point 18z2
2017-01-27 14:41:34.595429 yalu102[1044:256504] 18446744005199374440, 174063616
Seems to get to the same point as @andrewwiik 's previous log.
Commented out exit(0):
sysname: Darwin
nodename: Justins-iPhone
release: 16.3.0
version: Darwin Kernel Version 16.3.0: Tue Nov 29 21:40:08 PST 2016; root:xnu-3789.32.1~4/RELEASE_ARM64_T7000
machine: iPhone7,2
2017-01-27 14:54:44.455365 yalu102[1080:261920] found corruption 38203
2017-01-27 14:54:45.709770 yalu102[1080:261920] found kernel text at fffffff00c204000
2017-01-27 14:54:45.712442 yalu102[1080:261920] got tfp0 -> 38303
2017-01-27 14:54:45.713001 yalu102[1080:261920] found procs at fffffff11034ecb8
2017-01-27 14:54:45.717799 yalu102[1080:261920] seg: __TEXT
2017-01-27 14:54:45.717867 yalu102[1080:261920] seg: __DATA_CONST
2017-01-27 14:54:45.717907 yalu102[1080:261920] seg: __TEXT_EXEC
2017-01-27 14:54:45.717939 yalu102[1080:261920] seg: __KLD
2017-01-27 14:54:45.717971 yalu102[1080:261920] seg: __LAST
2017-01-27 14:54:45.718071 yalu102[1080:261920] seg: __DATA
2017-01-27 14:54:45.718110 yalu102[1080:261920] seg: __PRELINK_TEXT
2017-01-27 14:54:45.718142 yalu102[1080:261920] seg: __PLK_TEXT_EXEC
2017-01-27 14:54:45.718174 yalu102[1080:261920] seg: __PRELINK_DATA
2017-01-27 14:54:45.718206 yalu102[1080:261920] seg: __PLK_DATA_CONST
2017-01-27 14:54:45.718253 yalu102[1080:261920] seg: __PLK_LINKEDIT
2017-01-27 14:54:45.718285 yalu102[1080:261920] seg: __PRELINK_INFO
2017-01-27 14:54:45.718317 yalu102[1080:261920] seg: __LINKEDIT
2017-01-27 14:54:45.718397 yalu102[1080:261920] fffffff00b2cc000 - fffffff00ca94000
2017-01-27 14:54:45.797434 yalu102[1080:261920] ffffffff03da8000
2017-01-27 14:54:45.844027 yalu102[1080:261920] fffffff00c2715a0
2017-01-27 14:54:45.885785 yalu102[1080:261920] pmap: fffffff00c720850
2017-01-27 14:54:45.925183 yalu102[1080:261920] debug: test point 1
2017-01-27 14:54:45.925314 yalu102[1080:261920] debug: test point 2
2017-01-27 14:54:45.925373 yalu102[1080:261920] debug: test point 3
2017-01-27 14:54:45.925436 yalu102[1080:261920] debug: test point 4
2017-01-27 14:54:45.925592 yalu102[1080:261920] debug: test point 5
2017-01-27 14:54:45.925670 yalu102[1080:261920] debug: test point 6
2017-01-27 14:54:45.925804 yalu102[1080:261920] debug: test point 7
2017-01-27 14:54:45.925828 yalu102[1080:261920] Indentified 4k device
2017-01-27 14:54:45.925943 yalu102[1080:261920] calling back 18446744005208936480 2
2017-01-27 14:54:45.925979 yalu102[1080:261920] calling back 2
2017-01-27 14:54:45.926004 yalu102[1080:261920] calling back 3
2017-01-27 14:54:45.926128 yalu102[1080:261920] calling back 4
2017-01-27 14:54:45.926156 yalu102[1080:261920] Indentified 4k device
2017-01-27 14:54:45.926264 yalu102[1080:261920] calling back 18446744005208992728 3
2017-01-27 14:54:45.926328 yalu102[1080:261920] calling back 2
2017-01-27 14:54:45.926354 yalu102[1080:261920] calling back 3
2017-01-27 14:54:45.926423 yalu102[1080:261920] calling back 5
2017-01-27 14:54:45.926519 yalu102[1080:261920] got phys at 83144b000 for virt fffffff00097b000
2017-01-27 14:54:45.926634 yalu102[1080:261920] found cpu 0
2017-01-27 14:54:45.926671 yalu102[1080:261920] found physz: fffffff00c293000
2017-01-27 14:54:45.926704 yalu102[1080:261920] found cpu 1
2017-01-27 14:54:45.926731 yalu102[1080:261920] found physz: fffffff00c293000
2017-01-27 14:54:45.926852 yalu102[1080:261920] fffffff00c393574 - fffffff00c3933a8
2017-01-27 14:54:45.928191 yalu102[1080:261920] ttbr0: 802ab9000 fffffff00c271590
2017-01-27 14:54:45.928238 yalu102[1080:261920] debug: test point 8
2017-01-27 14:54:45.928314 yalu102[1080:261920] debug: test point 9
2017-01-27 14:54:45.928553 yalu102[1080:261920] debug: test point 10
2017-01-27 14:54:45.928583 yalu102[1080:261920] Indentified 4k device
2017-01-27 14:54:45.928725 yalu102[1080:261920] calling back 18446744005208936480 2
2017-01-27 14:54:45.928761 yalu102[1080:261920] calling back 2
2017-01-27 14:54:45.928786 yalu102[1080:261920] calling back 3
2017-01-27 14:54:45.928905 yalu102[1080:261920] calling back 4
2017-01-27 14:54:45.928942 yalu102[1080:261920] Indentified 4k device
2017-01-27 14:54:45.929010 yalu102[1080:261920] calling back 18446744005208992952 3
2017-01-27 14:54:45.929041 yalu102[1080:261920] calling back 2
2017-01-27 14:54:45.929160 yalu102[1080:261920] calling back 3
2017-01-27 14:54:45.929181 yalu102[1080:261920] calling back 5
2017-01-27 14:54:45.929201 yalu102[1080:261920] debug: test point 11
2017-01-27 14:54:45.929339 yalu102[1080:261920] debug: test point 12
2017-01-27 14:54:45.929447 yalu102[1080:261920] debug: test point 13
2017-01-27 14:54:45.929506 yalu102[1080:261920] debug: test point 14
2017-01-27 14:54:45.929534 yalu102[1080:261920] debug: test point 15
2017-01-27 14:54:45.929562 yalu102[1080:261920] debug: test point 16
2017-01-27 14:54:45.929597 yalu102[1080:261920] debug: test point 17
2017-01-27 14:54:45.929618 yalu102[1080:261920] Indentified 4k device
2017-01-27 14:54:45.929650 yalu102[1080:261920] calling back 18446744005208936480 2
2017-01-27 14:54:45.929676 yalu102[1080:261920] calling back 2
2017-01-27 14:54:45.929701 yalu102[1080:261920] calling back 3
2017-01-27 14:54:45.929721 yalu102[1080:261920] calling back 4
2017-01-27 14:54:45.929853 yalu102[1080:261920] Indentified 4k device
2017-01-27 14:54:45.929950 yalu102[1080:261920] calling back 18446744005208992960 3
2017-01-27 14:54:45.930067 yalu102[1080:261920] calling back 2
2017-01-27 14:54:45.930122 yalu102[1080:261920] calling back 3
2017-01-27 14:54:45.930142 yalu102[1080:261920] calling back 5
2017-01-27 14:54:45.930219 yalu102[1080:261920] debug: test point 18
2017-01-27 14:54:45.930510 yalu102[1080:261920] got a cpacr at 4462
2017-01-27 14:54:45.930558 yalu102[1080:261920] debug ---
2017-01-27 14:54:45.930579 yalu102[1080:261920] debug: test point 18z1
2017-01-27 14:54:45.930598 yalu102[1080:261920] debug: test point 18z2
2017-01-27 14:54:46.010205 yalu102[1080:261920] 18446744005199374440, 559435776
2017-01-27 14:54:46.049389 yalu102[1080:261920] debug: test point 19
2017-01-27 14:54:46.049473 yalu102[1080:261920] debug: test point 19a
2017-01-27 14:54:46.049496 yalu102[1080:261920] debug 18*
2017-01-27 14:54:46.049518 yalu102[1080:261920] Indentified 4k device
let the man do his work, just wait
@Mila432 This issue has been open well before your issue
I don't think these issues are related.
Most 4k devices get tte just fine.
If you have "got phys at 0" then it's already game over
my friend said that you guys are testing the JB on the iphone 6 this weekend. is this true? btw sorry if this isn't where i should be posting my questions where do i ask them
@akelly5
If you mean that Luca is testing 4k devices including iphone 6 over this weekened. Than yes, you are correct on that assumption.
we are also trying to do it without @kpwn just so we can have it faster and understand the jailbreak better
Virtual memory allows an operating system to escape the limitations of physical RAM. The virtual memory manager creates a logical address space (or “virtual” address space) for each process and divides it up into uniformly-sized chunks of memory called pages. The processor and its memory management unit (MMU) maintain a page table to map pages in the program’s logical address space to hardware addresses in the computer’s RAM. When a program’s code accesses an address in memory, the MMU uses the page table to translate the specified logical address into the actual hardware memory address. This translation occurs automatically and is transparent to the running application.
Is it possible this is just KPP acting up?
It was mentioned in this issue already, so I figure I'll bring it up here again. Is there any reason I'm not getting any output to my console? It just shows the Darwin kernel version and nothing else ever prints. If I look at the device log I get a lot of random garbage from the OS thrown in with yalu output. Is there anything I'm missing? I have console turned on and everything in XCode. OS X 10.11.6 and XCode 8.2.1.
click go
Go? I am clicking compile and run at the top left of XCode, and it's going to my device. I'm still not seeing any output in the console other than all of the Darwin information. @meyer9
I'm not used to compiling on my device, because usually my NSLog will go to the console if I'm using the simulator.
you'll have to click go on the app ;)
Oh haha, I did that too, I still don't get any output in the XCode console. I can see some yalu things if I look at the device logs in Window->Devices but it's also filled with a lot of random garbage from the OS like biometric sensor logging and stuff. It makes it very hard to tell what yalu is doing. I'm just trying to see only the yalu output, preferably in XCode.
hmm could you add an exit(0) command just before: WriteAnywhere64(ReadAnywhere64(find_kernel_pmap()), level1_table);? Mine panics at that line and sometimes doesn't show logs.
By the way, disassembling is iOS 10 kernel comes up with some stuff.
I just tried that, I'm still not seeing anything though. I'm wondering if it has to do with the fact that I'm trying to run it on an iPhone 7? I want to see what yalu actually does even though it's unsupported, so I figured it would at least output something. But I suppose it's possible that the JB just stalls if it sees that the device is an i7.
Probably. No offsets I don't think.
I know @Mila432 added the offsets for the i7 into offsets.c, so they're in there. I was guessing there was something earlier on in the code that was preventing anything from happening. You can tell some of them are for the i7/7plus because of the T8010 SoC chip at the end of the kernel name.
@anthonyjr2 The issue with 4k devices (what this discussion is about) is the size of virtual memory. Thats what this discussion is trying to help solve for Luca. i7 is a completely different set of issues.
Oh, no problem. I'm not looking for a fix for i7 devices, I was just curious why I wasn't getting any output to my i7 because I like testing and seeing how jailbreak code operates. The only reason I asked in this issue thread is because someone earlier in the thread was wondering the same thing.
@kpwn if you see this, please close this thread. it's getting a bit long.
new one here guys: https://github.com/kpwn/yalu102/issues/127
Most helpful comment
@Mila432 This issue has been open well before your issue