Does WINZIP7 not unzip RAR files? On Sun, Dec 15, 2024 at 2:50 AM Doug Jackson <[email protected]> wrote:
> Ahhhhhhhh!. > > I was expecting a hex dump and maybe a disassembly text output. Instead, > I discovered the file (which I now understand) to be a disassembly tool > project archive . > > I tried all sorts of stuff to get to the contents including treating it as > a ZIP file, which gave me some contexts, but nothing like what I was > expecting. > > Looks like I need to find this Ghidra disassembler and start playing with > it on my windows box. > > I wonder if IDA pro will read it? > > Thatks for the pointers. > > I'm sorry for my disparaging comment. I experience the same frustration > when people use RAR files believing everybody has a paid WinRAR > subscription when there are other archive formats that are open and I > thought I was just dealing with yet another archive format. > > Doug > > > On Sun, 15 Dec 2024, 6:00 pm RETRO Innovations, <[email protected]> > wrote: > >> On 12/15/2024 12:30 AM, Doug Jackson wrote: >> > I saw that, byt the owner doesn't want the archive opened - Its some >> > sort of proprietary archive format. >> >> Hmm, the author of the files is on list (Royce Taft), and I'm sure that >> was not his intent. From this list, 11/21/2024: >> >> >> http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/2024-November/090131.html >> >> The list archive scrubbed the HTML, but I pasted the original text below >> >> The repo is mine, so if there's something Royce or I need to do so make >> it more public, let one of us know >> >> ---------------------- >> >> If anyone tried to access the Ghidra disassembly files in Jim’s GitHub >> repository and found that the project doesn’t load, please disregard >> those files. The correct file has been uploaded which can be imported >> (or “restored” as Ghidra puts it) into Ghidra 11.2 or higher to load a >> snapshot of the disassembly thus far. >> >> >> Even for the code I’ve stepped through and commented, I don’t have >> everything figured out yet. I’ve got a handle on good portions of it up >> to the DOS IPL which was loaded to RAM from the first sector. >> >> When the ROM copies data to RAM, I used the byte viewer tool in Ghidra >> and manually copied the data into RAM at the appropriate location. From >> there, I could continue the disassembly in RAM. I did the same for the >> first sector of the boot disk. I used a separate hex editor to copy the >> 256 bytes from sector 1 of the boot disk and pasted that into Ghidra’s >> bytes viewer at the appropriate location in RAM. >> >> As I stepped through code, when writes were made to data in RAM, I >> manually made those changes using the bytes viewer. >> >> When playing around with it, keep in mind that reads and writes to >> 0x0000-0x07FF are not referencing the ROM and are instead referencing >> RAM1 once the bank has been switched to RAM1. Ghidra doesn’t know this, >> so those references must be manually changed. I probably missed some >> references as I stepped my way through. >> >> The amount of code I’ve stepped through and tried to decipher+comment is >> relatively small in terms of bytes compared to the size of DOS or disk >> basic, so there’s much left to do. >> >> I’m hoping to get back to this soon. I should probably try to capture a >> bunch of this FYI type info for the Ghidra disassembly project and >> compile it into a readme. >> >
