Any chance for this project getting ported to ARM?

[Date Yoshinobu]

Any chance for this project getting ported to ARM?
My previous attempt on maloader (the base project of this project) has failed (compiled, but crushed).

[Luboš Doležel]

Dne neděle, 23. prosince 2012 19:34:25 UTC+1 Date Yoshinobu napsal(a):

Any chance for this project getting ported to ARM?
My previous attempt on maloader (the base project of this project) has failed (compiled, but crushed).

Hi,

porting is not such a problem after all, only a couple of assembly functions need to be ported.

The question is what you'd expect from such a port.

(Sorry for multiple posts, but Google Groups doesn't work properly on Android. Fail.)

--

Luboš Doležel

 

[Date Yoshinobu]

I thought the same thing as ARM port would mean that we can run iPhone binaries on linux at least on command line level.
My problem was just that I never had programming experience in Assembly before.

2012年12月24日月曜日 5時16分23秒 UTC+9 Luboš Doležel:

[Luboš Doležel]

That's correct, the problem is I doubt there are any console-only iPhone binaries except for those you make yourself.

That being said, I plain to support ARM just in case anyone would take on the effort of reimplementing UIKit and other frameworks.

Luboš

Dne neděle, 23. prosince 2012 21:28:35 UTC+1 Date Yoshinobu napsal(a):

[Alexey Perevalov]

Hello Luboš,

Now I'm trying to run darling on ARM, on rpm based linux.

I stuck on class_table population for MachO classes.
for example:
@interface ITest : NSObject

-(void)printTest;
@end

@implementation ITest

-(void)printTest
{
    printf("printTest");
}
@end


int main(int argc, char * argv[]) {
 
    printf("%x\n", objc_getClass("ITest"));

result is 0x0, for ARMv7,
I think it's due ABI 1 - ProcessImageLoad is trying to work with __OBJC segment instead of __DATA.

I changed the way of working for ProcessImageLoad to ABI2 on ARM, and I got illegal m_slide (for main it was correct ;), but for another segments, e.g. __DATA, classlist section not so correct.
e.g.
getsectdata(mh, SEG_OBJC_CLASSLIST_NEW, SECT_OBJC_CLASSLIST_NEW, &size)
returns address which is out of range available for executable.
b6ed8000-b6edf000 ---p 00002000 b3:17 3363       /lib/libdl-2.13.so
b6edf000-b6ee0000 r-xp 00001000 b3:17 3363       /lib/libdl-2.13.so
b6ee0000-b6ee1000 rwxp 00002000 b3:17 3363       /lib/libdl-2.13.so
b6ee1000-b6ee9000 r-xp 00000000 b3:18 4501       /opt/home/root/sample/just_str1
b6ee9000-b6eee000 rwxp 00000000 00:00 0
b6eee000-b6ef1000 r-xp 00000000 00:00 0
b6ef1000-b6efe000 rwxp 00000000 b3:18 4501       /opt/home/root/sample/just_str1

it pointed to somewhere in /lib/libdl-2.13.so address space, my suggestion it's due
m_slide evaluation for __DATA segment as b6ee1000 - 0x4000 (where 0x4000 is vmsize).
And of course crash with segfault,
the same story if I disabled ProcessImageLoad, in this case
[ITest alloc] crashes in objc_msgSend_fpret, on ldreq    r4, [r0]
r0 pointed to somewher in /lib/libdl-2.13.so as well ).

Now I'm diving into MachOView,
ITest there has 0xc0dc value. I don't know, should it be relative of __DATA segment?
I could only guess about m_slide, due I didn't find essential ARM/MachO description. Or I could reverse engineering of existing loader for elf ).