In MachOView, I can see that in a iOS binary file, class pointers are stored in section __objc_classlist. They are absolute address values which point to class Data in section __objc_data. But we known that iOS use ASLR, so when loaded, the real address must be different.
I checked the "getsectiondata" method, can not found any rebase logic.
So the question is:
dyld handles rebasing as part of loading the binary, long before you call getsectiondata. The LC_DYLD_INFO_ONLY load command within the binary points to the rebase opcodes which contain information about which addresses to update and how.
You can use xcrun dyldinfo -rebase <binary> to see the list of addresses that dyld will rebase. You'll see entries for each class within __DATA,__objc_classlist. You can set DYLD_PRINT_REBASINGS=1 in the environment prior to launch to have dyld print out each address it rebases.
And yes, since dyld modifies data as it rebases it, the page no longer matches the underlying storage and is dirty. Avoiding dirtying pages during load has been a motivation for switching some Objective-C data structures from using pointers to relative offsets.