Reverse engineering IRIX: The beginning.

Reverse engineering IRIX: The beginning. - Printable Version

+- IRIX Network Forums (//forums.irixnet.org)
+-- Forum: SGI/MIPS (//forums.irixnet.org/forum-3.html)
+--- Forum: Development/Porting (//forums.irixnet.org/forum-9.html)
+--- Thread: Reverse engineering IRIX: The beginning. (/thread-3311.html)

Pages: 1 2

Reverse engineering IRIX: The beginning. - Raion - 12-27-2021

So thus far most of my time on development for new parts of the base has been replacement, not much else.

Finally feel comfortable enough announcing a project I picked up purely because I thought I could do it.

File Alteration Monitor is a part of the IRIX base system. The version shipped with 6.5.12+ was released as GPL2/LGPL2 (the latter for the library).
The original version 1 was as far as I understand never actually released. But the library is tiny, and I made friends with an excellent source code documentarian and developer. He was kind enough to pop the 5.3 era library through Ghidra and write out exactly what it did, function by function (and even function names, as he had debug symbols).

As I speak I was successful in reconstruction of it from the documentation he provided. He provided a significant analysis of each and I did my best to match the CFront era C++ function design and setup. As a result the code quality is atrocious and likely will not be my finest work, now or ever. I am currently working in getting it compiling and will build a few programs for testing purposes.

This library will not be acceptable to use as a drop in replacement likely. I did this strictly as an exercise and in hopes that someone with more brains and skill can make due of it.

The source will be released under the MIT license, and I will do my best to document it both with comments and a short function manual. It is my hope that I or someone else can:

1. Write a fam daemon from the library to replace the V1 daemon in 5.3

2. Upgrade the library to support version 2 that is widely distributed.

3. Port it to other OSes, using OS specific functions for event based monitoring.

4. Make it not suck or insecure.

It is my hope that barring some freak problem I should have this released within a month or less..

Far from stopping here I have a number of other libraries and commands that I plan to reverse engineer or help someone else do.

I make no claims as to the quality of my work but only that I will do my best and hope that I can be a better developer because of it. My friend who's a artist once told me that is not about painting a Picasso your first time. Sometimes you have to get in practice and lots of it in order to actually be a better developer and he said a lot of it just takes time.

RE: Reverse engineering IRIX: The beginning. - Raion - 12-28-2021

Finally started testbuilding it for IRIX and FreeBSD -- as I figured a lot of code needs to be refactored

RE: Reverse engineering IRIX: The beginning. - TruHobbyist - 12-28-2021

Hey Raion, why not releasing your source code somewhere, so we can have a look? Shouldn't take more than 5 minutes to skim over it. And maybe I can give you some useful hints.

RE: Reverse engineering IRIX: The beginning. - Raion - 12-28-2021

I wanted to release it in a functional state first.

I actually have it building now so I'll have it up soon ish

RE: Reverse engineering IRIX: The beginning. - Raion - 12-28-2021

http://gitea.irixce.org/Raion/OpenFAM

OpenFAM source code is here. It needs way more documentation/code review and bugfixing. But it does compile on IRIX, not yet on anything else. Gotta see if bzero() and pmap_getport(); exist on other platforms and if not what is needed to rewrite.

The fam.h header also lacks any documentation for it yet. I need to fix that.

If anyone has any questions on this by all means.

RE: Reverse engineering IRIX: The beginning. - jpstewart - 12-28-2021

(12-28-2021, 06:30 PM)Raion Wrote: Gotta see if bzero() and pmap_getport(); exist on other platforms and if not what is needed to rewrite.

bzero() is ancient, apparently stemming from 4.3BSD. It's deprecated in recent POSIX specifications, with memset() recommended instead. It's a simple change:

Code:
bzero( string, size )

becomes

Code:
memset( string, 0, size)

pmap_getport() is a pretty basic part of the RPC subsystem and should be pretty widely supported as a result.

RE: Reverse engineering IRIX: The beginning. - Raion - 12-28-2021

Thanks for the insight on that one because I've never seen that used before let alone finding documentation on what exactly it was doing.

Hopefully that will allow me to ditch the internal compiler header.

Besides documentation I have been weighing whether or not I want to do a full rewrite of certain portions of it, changing C printf to iostreams where possible and finding a good C++98 solution for a native snprintf type function (I've read a fair bit about C++11 std::string which isn't usable here)

RE: Reverse engineering IRIX: The beginning. - jan-jaap - 12-28-2021

First code I open:

Code:
void getword(char *p, long *l)

{

        char    *pp;

        pp = (char *) l;

        *pp++ = *p++;

        *pp++ = *p++;

        *pp++ = *p++;

        *pp++ = *p++;

}

void putword(char *p, long *l)

{

        char *pp;

        pp = (char *) l;

        *p++ = *pp++;

        *p++ = *pp++;

        *p++ = *pp++;

        *p++ = *pp++;

}

This will do different things on big-endian and little endian platforms
This assumes sizeof(long) == 4 bytes

RE: Reverse engineering IRIX: The beginning. - Raion - 12-28-2021

That one is purely a Band-Aid until I unravel where in the code it's relying on long types.

RE: Reverse engineering IRIX: The beginning. - Raion - 12-29-2021

Ok, managed to add some progress:

Removed CC/libc.h dependency, corrected a few typos, and managed to change those functions to uint32_t.

It still won't build outside of IRIX, and that's ok. I'm just finishing up tests for it to make sure I didn't break something in all these changes.