Running a debugger like gdb with real-mode 16-bit code on the x86 platform is not the easiest thing to do, but incredibly useful when it comes to analyzing BIOS firmware and DOS software. Although it’s possible to analyze a BIOS image after running it through a disassembler, there is a lot that can only be done when the software is running on the real hardware. This is where [Davidson Francis] decided that some BREAD would be useful, as in BIOS Reverse Engineering & Advanced Debugging.
What BREAD does is provide some injectable code that with e.g. a BIOS replaces the normal boot logo with the debugger stub. This stub communicates with a bridge via the serial port, with the gdb client connecting to this bridge. Since DOS programs are also often 16-bit real-mode, these can be similarly modified to provide light-weight in-situ debugging and analysis. We imagine that this software can be very useful both for software archaeology and embedded purposes.
Thanks to [Rodrigo Laneth] for the tip.
In 1983 i have , with a college, reverse engineerd the system roms (2kx16) of a PLC system by dumping the code and then converted the machine code back to a sort of ASM (as in what the 8086 manual said).
The result: lower 2k was it’s “OS” and the upper part was a “INTeL monitor” program what used a serail port to Read/Write code and data as in going to “init 1” (Linux single user debug mode).
Learned a lot about the working and the use of the 80×86, one of the my memories is “Rep MOVS[B,W,D]” (MOVS move data ala Direct Memmory Access but without a DMA controller) and also reading and understanding of raw Hexcode whitch came in very handy in 1986 to write DOS .com programs by only using the dosdebugger for lots of usefull (to me) programs. Nearly on all of them you got a help by “type” that .com file (just after the “JMP start”) and use that space for it’s stack.
That was real-mode later on , 1992, with BP 7 (Borland Pascal) DPMI (Dos Protected Mode Inteface) to write a TSR (Terminate and Stay Resident) programs to interfcae with real-mode netwotk cards,
our own true color BGI unit for a 1280×1024 monitor in stead of the 640×350 res from Borland.
Also to solve problems with the BP 7 compiler (prefetch caching on newer than 40486) and TP512.lib video init (‘error 200’ divide by zero as result of a loop counter with a to low value for the higher clock speeds, upto 200 MHz was ok) changed the value fron 0A to 40 and as result a 3 GHz i7 has no problems with that init.
By now most of that knowleage is gone ;(
Turbo Pascal 7? Wow, that’s modern! 😮 It even had a free 16-Bit Windows compiler in the package or so I heard! 😃
Among my father’s 5,25″ vintage floppy disks I “merely” found v3 through v6, with Turbo Grafx libraries on separate diskettes.
– Plus, Turbo Pascal for Windows 1.0 (TPW), the predecessor to the Windows compiler in Borland Pascal 7..
Pfuu, that´s nothing. I was punching kilometers of strips of animal skin, carefully shaved and thinned, and punching whole programs using a homemade polished bone punching tool until late every evening, at the light of the bonfire. Ah, those were the days …
You had animal skins and punch tools? We could only dream of such things. We had to draw circles and dots in the sand, and grandpa had to interpret the instructions before it rained, or days of precious source code would be lost.
TP3 was great, TP4 was even better, from then on it was meh. Tubro/Borland Pascal for Windows was very good compared to the MS SDK, but then they moved to the weird Delphy thing and it became bloated.
Delphi was basically a VB knockoff but with a proper programming language under the hood and was quite popular for database development work back in the day. Delphi programs were native machine code (unlike VB) and (AFAIK) didn’t require a huge pile of runtime DLLs. I actually wrote software in Delphi back in the day and thought it was great.
C/c++/batch assembler 1 buggy 2 malware vulnerable software technology debugging?