Log in

View Full Version : Small Devices & RCE


Daniel Pistelli
July 25th, 2008, 09:11
Didn't want to go off-topic in the other thread, that's why I'm opening a new one. I wanted to add some thoughts about the IDA-on-IPhone news.

Quote:
Good news for real iPhone fans: we ported IDA to iPhone! It can handle any application and provides the same analysis as on other platforms. It is funny to see IDA on a such small device:

http://hexblog.com/2008/07/ida_on_iphone.html

Ilfak Guilfanov

I think it's awesome.

It's also funny, because in theory the new CFF Explorer will be compilable for mac os (being written in Qt), thus also IPhone. The only problem is the small display of such devices and I'm not sure if there's a possibility to reduce the needed space, but I'm quite optimistic.

I mention this because the new CFF Explorer will support elf and other formats (lib, object, symbian etc), making it useful also for other systems and it might become part of a new generation of cross platform/device tools. It would be encouraging to know that in the future it will be possible to do reversing stuff on such a small device. The new CFF will also have zoom in/out features for the hex editor, making it very useful on devices with a small (or big) display.

I hope that other programmers will follow the same lead.

The main problem is writing cross platform applications and reorganizing GUIs for small displays.

I want to share something I read on wikipedia some time ago:

Quote:
Microsoft software is also presented as a "safe" choice for IT managers purchasing software systems. In an internal memo for senior management Microsoft's head of C++ development, Aaron Contorer, stated:[7]

“The Windows API is so broad, so deep, and so functional that most Independent Software Vendors would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead... It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO (total cost of ownership), our lack of a sexy vision at times, and many other difficulties [...] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move. In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago.

Companies such as Apple and Microsoft are very conscious of the strategic importance of hard binding applications to their propretary API. That's why Apple pushes cocoa and Microsoft .NET. They don't want cross platform development environments (oh and don't tell me that .NET is cross-platform, before doing so, show me a .NET GUI with more than a button in it on a system which isn't Windows), because it would make possible for users to switch to another system without losing his tools.

However, "the times they are a changin'". Nowadays, developers are more conscious about this problem and prefer not to bind their application to only one platform. You can notice this if you pay attention to the names of newer applications. Ten years ago there were lots of windows applications which contained the word "win" in them. Winhex, WinDvd, Winzip, WinRar, WinAce, Winamp etc. etc. etc. Have you noticed that this trend has stopped? It's interesting, right now a struggle between developers and OS producers is taking place. OS producers want to ever more bind (even more than before) developers to their platform. Why do I say more than before? Well, consider that .NET implements its own languages, you can't simply share real C++ code with the managed one (yes, you can rely on pinvoke, but not for everything). Well, it's a bit more complicate than that, I know, but unsafe code is not encouraged in the .NET environment. Meanwhile, Apple pushes Obj-C. I want to know how this ends. Speaking for myself, I refuse to take a side and will stick with my beloved C++ (the real one).

I hope this post won't generate a big controversy like the one about Windows Vista.

Shub-nigurrath
July 26th, 2008, 19:34
interesting post mate, indeed on iPhone is not the first, on PalmOS there were good on-device reversing tools since a lot of years, unfortunately that OS is falling out, but was worth mentioning.
Second is not clear if at Hex-Rays ported IDA for Apple on an unlocked iPhone 3G or not, this does the difference. The underlying system of iPhone is an OSX with almost the same interfaces of its big brother, as you said. Unlocked 3G iPhones comes for example with full POSIX interface and with a gcc already distributed. This extends the portability to a lot more programs. Looking at the post they did it seems that a jailbroken iPhone is needed.

On the same track is moving symbian which is trying to drop its cumbersome developing environment since a lot of time. They slightly moved to python and added full support to POSIX, which means an easier porting from Unix programs.

BTW Python itself is becoming one of the prominent standards for embedded systems, because its footprint is very small and good for directly piloting embedded devices.

Anyway do you know that MS is working on the porting of c++ into the CLR? I am not speaking of the managed c++, but of the real and standard c++ language. This would inject imho a new life to this language and definitely let me enter the .net world, using the c++ backyard door. ^_^

reverser
July 27th, 2008, 06:20
The screenshot clearly shows IDA running in Terminal which definitely needs a jailbreak.

Daniel Pistelli
July 27th, 2008, 07:34
I don't know anything about iphone at the moment, but as I read some news about it I think that the development environment is too restrictive at the moment. So, they might decide to open up a bit to gain dev interest and enlarge their market. I don't think that right now it is possible to do as much as it would be possible in theory.

About the C++, I had the same idea some years ago, I'd be interested in knowing more about this project, thus if you have any information, please share. However, this reflects my opinion I expressed at the end of the 2 articles about .NET internals: it is necessary to offer a native compiling method.