Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order
Rugxulo(R)

Homepage

Usono,
30.04.2013, 14:06
 

Silly hacks -- COMFIX (identify 80186 UPX'd .COMs) (Developers)

Where to talk about things that are interesting but kinda trivial? Well, I guess I'll start here. Apologies in advance if this is too dumb, badly solved, etc.

Recently I noticed that a certain developer (much more savvy than I am) accidentally UPX'd his .COM without the --8086 flag. I've not really totally solved this problem (i.e. tool to actually fix/rewrite that part of the stub to be 8086 friendly), but at least it's fairly easy to identify now.

So here's the horribly kludgy code that I wrote to identify such problematic .COMs. "for %a in (c:\fdos\*.com) do comfix %a" will show you what needs fixing (I hope!).


program comfix;
uses crt;
const special=9; show: boolean = false;
var comfile: file of byte;
  i: 1..special;
  mydata: array [1..special] of byte;
procedure usage;
  begin
    writeln('Error: no .COM specified to analyze!');
    writeln;
    writeln('TODO: Actually rewrite the dumb part of the decomp stub.');
    writeln;
    writeln('Another way to diagnose:');
    writeln('  ndisasm.exe -b16 -o100h blah.com | grep "rol word \[.*,0x8$"');
    halt(255)
  end;

begin {upxfix}
  if paramcount=0 then usage;

  assign(comfile,paramstr(1)); if paramcount >= 2 then show := true;
  reset(comfile); seek(comfile,filesize(comfile)-special);
  for i := 1 to special do read(comfile,mydata[i]); close(comfile);

  if show then begin
    for i := 1 to special do write(mydata[i],' '); writeln
  end;

  textcolor(red);
  {reference:  upx-3.08-src/src/stub/src/arch/i086\macros.S}
  if ((mydata[1]=$C1) and (mydata[2]=4) and (mydata[3]=8)) or
     ((mydata[2]=$C1) and (mydata[3]=5) and (mydata[4]=8)) then
       writeln('Intel 80186 UPX''d .COM found! Sorry, 8086 users. :-(')
  else begin
    textcolor(green); writeln('No problems found, no worries! :-)');
  end;
  normvideo
end.

Rugxulo(R)

Homepage

Usono,
30.04.2013, 14:21

@ Rugxulo

Silly hacks -- APASHTM (.pas to .htm via FPC GO32V2 build)

Another thing I've found interesting is converting .PAS sources to different formats. You can use other tools (GNU Enscript) or htmlfontify-buffer in latest GNU Emacs or write a buggy sed script. :-) I know there are other potential ways, but they don't seem as obvious (to me, yet).

Anyways, despite the horribly weird sources (no offense, but it could use some work), I thought this was interesting.

Another Pascal to Html Converter

Here's what so weird about it: his default .EXE builds use Lazarus. Granted, this was 2005, so maybe smartlinking wasn't effective (or available?), but 6.5 MB seems way overkill! The sources are less than 100 kb!

Apparently you can whip up your own easy console frontend to his UPasHtm (and Reser) units, and it'll still work:


{$mode objfpc}{$H+}

program apashtm;
uses UPasHtm; {which uses Reser}

begin
  if paramcount < 2 then writeln(paramstr(0),' in.pas out.html')
  else ConvertPasToHtm(paramstr(1),paramstr(2))
end.


"fpc -XXs -Os apashtm.pas" is only 36 kb on Linux (as opposed to his Linux Lazarus build from 2005, which is 5.8 MB. Oh, and it doesn't run, for me it needs libglib-2.0.so.0 and other stuff, blech).

This probably isn't super duper useful, and I somewhat doubt how reliable it is (esp. regarding "standard" Pascal), but hey, it's much better than nothing, right? At least without rewriting it myself. :-)

marcov(R)

30.04.2013, 17:24

@ Rugxulo

Silly hacks -- APASHTM (.pas to .htm via FPC GO32V2 build)

> Here's what so weird about it: his default .EXE builds use Lazarus.
> Granted, this was 2005, so maybe smartlinking wasn't effective (or
> available?), but 6.5 MB seems way overkill! The sources are less than 100
> kb!

smartlinking was available for Windows in 2005. Windows always had smartlinking, since it was needed to eliminate calls to unused win32 definitions. (otherwise windows.pas contained a prototype for an function that not all versions of windows had, it would fail to run on such windows versions)

More likely, he didn't enable smartlinking, and probably didn't strip debug info either. A base Lazarus EXE would have been 700-1200kb. (depending on how many widgets were used). Since you compiled the base functionality to a fairly small program, there can't be that much extra.

Nowadays lazarus binaries are larger than then (a few 100kb), but still same magnitude

IOW, it is a debug, not a release build.

> "fpc -XXs -Os apashtm.pas" is only 36 kb on Linux (as opposed to his Linux
> Lazarus build from 2005, which is 5.8 MB. Oh, and it doesn't run, for me it
> needs libglib-2.0.so.0 and other stuff, blech).

GTK and dependencies. Probably GTK1 even.

> This probably isn't super duper useful, and I somewhat doubt how reliable
> it is (esp. regarding "standard" Pascal)

Afaik on level zero parsing level (highlighting) there are not that much differences. A minimal adaptability of the parser would be enough to implement the base level of the various dialects.

>, but hey, it's much better than
> nothing, right? At least without rewriting it myself. :-)

Current Free Pascals contain a secondary parser for documentation tool purposes. It is expanded as the dialect expands (but at a distance). For something more than highlighting, it is probably better.

Back to the board
Thread view  Mix view  Order
15109 Postings in 1359 Threads, 247 registered users, 16 users online (1 registered, 15 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum