Extracting Next drivers on Linux (Lubuntu)

Started by pTeK, February 01, 2024, 04:42:32 PM

Previous topic - Next topic

pTeK

Hi.

 I'm having trouble extracting Next drivers on lubuntu so I can load them in Gheidra.

 I'm trying to extract the NS33 EIDE updated driver, the one with the PIIX3 code?.

tar -xvf EIDE.tar
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

 I also don't have a NFS system to get files out of the VirtualBox image.

 I've tried using Chat-gpt 3.5 to produce ANSI C89 code to rip the binary out of the .tar file at offset x length y, but there seems to be difference when I'm ripping the code looking at the first 1K doing Hexdump -C on Lubuntu and od -x on NS33.

 If some one can upload the EIDE_reloc binary filesize 99636 would be much appreciated or know how to extract the .tar files.

EDIT: Also won't work with 7z

cuby

This tar file (I assume you extracted the file from the EIDE.pkg installer?) uses a variant of the ancient V7 tar format - see the Wikipedia page under "Pre-POSIX.1-1988 (i.e. v7) tar header" - with different offsets (0xe0 instead of 100).

In theory, GNU tar should be able to handle that file, but it might have problems detecting the format since V7 tar has no identifying magic at the start of the file.

This is a quick and dirty extractor I wrote since I stumbled across this problem before, too... hope it helps.

#include <sys/types.h>
#include <sys/uio.h>
#include <unistd.h>
#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>

int main(int argc, char **argv) {
  uint8_t buf[512];
  int fd;

  fd = open(argv[1], O_RDONLY);

  while(1) {
    int n = read(fd, buf, 512);
    if (n < 512) break;

    char *fn = (char *)buf;
    char *smode = (char *)buf+0xe1;
    int mode;
    sscanf(smode, "%o", &mode);

    char *suid = (char *)buf+0xe9;
    int uid;
    sscanf(suid, "%o", &uid);

    char *sgid = (char *)buf+0xf1;
    int gid;
    sscanf(sgid, "%o", &gid);

    char *ssize = (char *)buf+0xf9;
    int size;
    sscanf(ssize, "%o", &size);

    buf[0x114] = 0;
    char *sts = (char *)buf+0xf9;
    int ts;
    sscanf(sts, "%o", &ts);

    printf("# %s %o %d %d %d\n", fn, mode, uid, gid, size);

    if (size > 0) { // file
      int wfd = open(fn, O_CREAT|O_WRONLY, mode);
      for (int pos = 0; pos < size; pos+=512) {
        int n = read(fd, buf, 512);
        printf("# %d %d %d\n", size, pos, size-pos);
        write(wfd, buf, ((size-pos) >= 512) ? 512 : (size-pos));
      }
      close(wfd);
    } else { // dir
      mkdir(fn, mode);
    }
  }
}

pTeK

Thanks @cuby it's extracted, I'll alternate between that and the NS3.3 boot loader with ghidra

cuby

Quote from: pTeK on February 01, 2024, 04:42:32 PMI'm trying to extract the NS33 EIDE updated driver, the one with the PIIX3 code?
There's also an EIDE driver that supports the PIIX chipset in the Darwin-0.3 sources - this early version of Darwin was still based on a Mach 2.x kernel and used the Objective C-based DriverKit. Maybe this helps a bit with reverse engineering the NS3.3 driver.

pTeK

Quote from: cuby on February 02, 2024, 12:46:03 PMThere's also an EIDE driver that supports the PIIX chipset in the Darwin-0.3 sources - this early version of Darwin was still based on a Mach 2.x kernel and used the Objective C-based DriverKit. Maybe this helps a bit with reverse engineering the NS3.3 driver.
I've had a look at those and have had trouble compiling it straight out of the box as it's missing headers.

It seems to compile most of the way on Rhapsody DR2 compared to OpenStep 4.2 or NS3.3 as there seems to be more of the missing files in Rhapsody DR2 headers directory. Their also seems to be a .lkproj in the archive which is a loadable kernal module with Rhapsody Project Builder which would be a _reloc.tproj on NS33/OS42.

@neozeed has managed to get it to compile but I think that is because he has copied over all the darwin source code and built a working kernel which creates a few extra files to get it compiled. I haven't take the next step (pun intentional) to that stage yet.

Also on OpenStep 4.2 when you read the Driver Kit notes it says to use NS 3.3 Developer?!?!, I don't know if that means just to use the includes or to compile on NS33 and OS42 is compatible.  :'(

I see that all the 3rd party drivers on github who compile for Rhapsody and NS33 provide drivers for both Rhapsody and NS33, I don't know if this means that NS33 drivers are binary compatible with Rhapsody DR2, this would be good as I'd be able to use the AMDPCnet driver on Rhapsody with Virtual Box but I don't know how to get it on a bootable disk to work with Rhapsody as Rhapsody can not read NS33 CD-ROMs or Floppy disk drives  :'(

I also found out that the example AMDPCCSIDriver driver on NS33 wont compile as it's missing a header file driverkit/IOPower.h :'(

The amount of frustration I get trying to compile that EIDE driver on NS33, when you've included the "ATA_EXTERN.h" and it says "undefined type: found 'ide_return_t'' IdeCntCmd.h

 :'( Tears of happiness and funnnnn timmmmmmmmes  ;D . I'm just glad this forum is here, I don't know how far I would get just using stackexchange. (apologies for my rant)

protocol7

Quote from: pTeK on February 02, 2024, 04:17:29 PMI see that all the 3rd party drivers on github who compile for Rhapsody and NS33 provide drivers for both Rhapsody and NS33, I don't know if this means that NS33 drivers are binary compatible with Rhapsody DR2, this would be good as I'd be able to use the AMDPCnet driver on Rhapsody with Virtual Box but I don't know how to get it on a bootable disk to work with Rhapsody as Rhapsody can not read NS33 CD-ROMs or Floppy disk drives  :'(
Try using HFS. That should work with Rhapsody.

cuby

Quote from: pTeK on February 02, 2024, 04:17:29 PMI also found out that the example AMDPCCSIDriver driver on NS33 wont compile as it's missing a header file driverkit/IOPower.h :'(
Hm, IOPower.h is part of the Darwin-0.3 driverkit sources. There's not a lot of code in it (but, of course, the #import'ed <kern/power.h> might be missing?).

pTeK

#7
Quote from: cuby on February 02, 2024, 08:41:44 PMHm, IOPower.h is part of the Darwin-0.3 driverkit sources. There's not a lot of code in it (but, of course, the #import'ed <kern/power.h> might be missing?).

That's what I was complaining about, NeXT provided example source code but they didn't include all the headers, or they used private headers which were no good to the public as the public did not have access to those headers.

I guess #ifdef is your friend

EDIT: here is the fixed AMDPCSCSIDriver/AMDPCSCSIDriver_reloc.tproj/AMD_SCSI.h

#import <driverkit/IOSCSIController.h>
#if (IO_DRIVERKIT_VERSION == 330) // Patch to compile on NS33

// kern/power.h

typedef enum {
    PM_READY = 0x00, // PM enabled, full power
    PM_STANDBY = 0x01, // Standby mode
    PM_SUSPENDED = 0x02, // Suspend mode
    PM_OFF = 0x03 // Off completely
} PMPowerState;

typedef enum {
    PM_DISABLED,
    PM_ENABLED
} PMPowerManagementState;

// driverkit/IOPower.h

@protocol IOPower

- (IOReturn) getPowerState:(PMPowerState *)state_p;
- (IOReturn) setPowerState:(PMPowerState)state;
- (IOReturn) getPowerManagement:(PMPowerManagementState *)state_p;
- (IOReturn) setPowerManagement:(PMPowerManagementState)state;

@end

#else
#import <driverkit/IOPower.h>
#endif
#import "AMD_Types.h"

@interface AMD_SCSI : IOSCSIController <IOPower>

EDIT2:04/Feb/2024 fix to AMDPCSCSIDriver/AMDPCSCSIDriver_reloc.tproj/AMD_x86.m
you need to replace "unsigned  *basePtr =0;" to "unsigned long *basePtr = 0;" this is found in driverkit/i386/PCI.h

static BOOL parseConfigSpace(
  id deviceDescription,
  const char *title,
  unsigned regSize,  // in bytes
  IOEISAPortAddress *baseAddr)  //RETURNED
{
  IOPCIConfigSpace configSpace;
  IORange portRange;
  unsigned *basePtr = 0;   <-- replace this line
  unsigned long *basePtr = 0; <-- with this line

pTeK

Quote from: protocol7 on February 02, 2024, 04:49:19 PMTry using HFS. That should work with Rhapsody.
Thanks, and this works, I used:

# mkisofs -hfs -J -R -V Volume_Name -o CD_Iso_Name.iso path_to_image

AMDPCNetDriver
NextStep 3.30 driver doesn't work but doesn't crash the machine like
OpenStep 4.00 and NextStep 3.32 (this website) Driver crashes on VirtualBox RhapsodyDR2 i386:
AMD PCnet-32: Am79C970 revision: 0x2621003
Registering: en0
AMD PCnet-32 PCI at port 0xd020 irq 9
en0: Ethernet address 08:00:27:55:9e:xx
System Panic:
recycleNetbuf: buffer underrun

VBE20Display driver also doesn't work as it doesn't have code in the kernel, I thought that if it had code in the /usr/standalone/i386/boot it would work but there seems to be extra code in the kernel.

I don't know if this code is in the kernel released with Darwin 0.1/0.3 that the kernel hackers on this forum are using.

Error log at bootup on Rhapsody DR2
Error occurred while linking driver VBE20DisplayDriver:
rld(): Undefined symbols:
_VBEModeInfo2IODisplayInfo
Error linking VBE20DisplayDriver device Driver.

configureDriver: driver class 'VBE20DisplayDriver' was not loaded
Driver VBE20DisplayDriver could not be configure

on OpenStep 4.2 Patch 3 /mach_kernel 1,117,920
# od -s3 /mach_kernel |grep VBE
4037436 _FBAllocateVBEConsole
4045377 _VBEModeInfo2IODisplayInfo