>>> jsr puts
>>> fcc 'Hello, world!',13,0
>>> clra
>> Mine can't do that automatically, but it can with a little human
>> assist; the human would need to tell it that the memory after the
>> jsr is a NUL-terminated string, but that's all it would need to
Not all strings are null-terminated. In CP/M, and MS-DOS INT21h Fn9, the
terminating character is '$' !
"If you are ever choosing a termination marker, choose something that
could NEVER occur in normal data!"
Also, strings may, instead of a terminating character, be specified with a
length, or wi
On 01/12/2017 01:30 PM, Sean Conner wrote:
> I've seen the high bit set on the last character, again mostly in
> the 8-bit world.
Prime (in PrimOS) took the approach of setting the high bit on *all*
ASCII data, which does make it stick out in a tape or core dump.
--Chuck
It was thus said that the Great Fred Cisin once stated:
> >>jsr puts
> >>fcc 'Hello, world!',13,0
> >>clra
> or the classic:
>JMP START1
>DATA2: DB . . .
> DB . . .
>START1: MOV DX, OFFSET DATA2
> Which was heavily used beca
jsr puts
fcc 'Hello, world!',13,0
clra
or the classic:
JMP START1
DATA2: DB . . .
DB . . .
START1: MOV DX, OFFSET DATA2
Which was heavily used because
MOV DX, OFFSET DATA3
. . .
DATA3: DB . . .
would
>> Clone [my disassembler] and look at the README if you want to get an
>> idea how it works from a user's point of view.
> I will certainly do that. It'll be interesting how this for 8080/z80
> compares to the 30-odd-year old interactive disassembler for CP/M,
> Dazzlestar.
It will probably come
> But are there disassemblers that can handle somehing like:
> jsr puts
> fcc 'Hello, world!',13,0
> clra
Mine can't do that automatically, but it can with a little human
assist; the human would need to tell it that the memory after the jsr
is a
On 01/12/2017 11:21 AM, Sean Conner wrote:
>
> But are there disassemblers that can handle somehing like:
>
> jsr puts
> fcc 'Hello, world!',13,0
> clra
> ...
>
> putspulsx
> puts1 lda ,x+
>
It was thus said that the Great Chuck Guzis once stated:
> On 01/12/2017 07:35 AM, Mouse wrote:
>
> >> Does your disassembler do flow analysis?
> >
> > I doubt it, because none of the meanings I know for the term are
> > anything my disassembler does.
>
> A disassembler that can do flow analysi
On 01/12/2017 09:52 AM, Mouse wrote:
> My disassembler defaults to disassembling as instructions, but it
> has support for the user telling it that certain areas are text, or
> integers, or whatever. Clone it and look at the README if you want
> to get an idea how it works from a user's point of
rrors of my ways
:)
A
>
> From: cctalk on behalf of Chuck Guzis
>
> Sent: Wednesday, January 11, 2017 7:12:43 PM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: Unknown 8085 opcodes
>
> On 01/11/2017 06:45 PM, Mouse wrote:
>
>> In case a
>>> Does your disassembler do flow analysis?
>> I doubt it, because none of the meanings I know for the term are
>> anything my disassembler does.
> A disassembler that can do flow analysis is a breath of fresh air
> when working with larger binaries. Essentially, it looks at the code
> and makes
>> While 8080 and 8085 are not on the list, Z-80 is; adding 8080 would
>> be a relatively simple thing.
> Isn't 8080 just a subset of Z80?
I think it is, or at least close; I may add 8080 as a slight tweak to
the Z-80 module instead of as a completely independent module.
>> if someone can point m
On 01/12/2017 07:35 AM, Mouse wrote:
>> Does your disassembler do flow analysis?
>
> I doubt it, because none of the meanings I know for the term are
> anything my disassembler does.
A disassembler that can do flow analysis is a breath of fresh air when
working with larger binaries. Essentiall
On 01/11/2017 10:13 PM, dwight wrote:
> Sorry Chuck
>
> It was not you I was talking about. It was the original thinking that
> a 8085 disassembler would make sense out of the original 8041 code.
>
> Maybe I'm confused but I believe the code in question was the 8041.
It's okay--topic drift isn't
>> [...disassembler...]
> Does your disassembler do flow analysis?
I doubt it, because none of the meanings I know for the term are
anything my disassembler does.
> At any rate, the best reference for "undocumented" 8085 instructions
> is the Tundra/Calmos datasheet: [...]
That looks like a webp
On 2017-01-11 11:45 PM, Mouse wrote:
Good list there, the onlinedebugger looked the most promising but it
doesn't do 8080/8085 either.
I built a disassembler years ago to pick apart captured malware. By
now it handles about a dozen ISAs. While 8080 and 8085 are not on the
list, Z-80 is; addin
Johnny Eriksson wrote:
> from another disassembler project:
> { 0xC9, 1, popj, 0, "ret" },
> { 0xCD, 3, pushj, 0, "call %a" },
Someone with good taste, I see.
> I built a disassembler years ago to pick apart captured malware. By
> now it handles about a dozen ISAs. While 8080 and 8085 are not on the
> list, Z-80 is; adding 8080 would be a relatively simple thing. I've
> added that to my to-do list; if someone can point me to 8080/8085
> machine langua
Mouse writes:
> I built a disassembler years ago to pick apart captured malware. By
> now it handles about a dozen ISAs. While 8080 and 8085 are not on the
> list, Z-80 is; adding 8080 would be a relatively simple thing.
Isn't 8080 just a subset of Z80?
> if someone can point me to 8080/8085 ma
Chuck Guzis
Sent: Wednesday, January 11, 2017 9:44:27 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Unknown 8085 opcodes
On 01/11/2017 08:50 PM, dwight wrote:
> Even so, he said the code was
>
> for the 8741. It is not 8085!
>
In the interest of minimizing clutte
On 11/01/17 22:20, Adrian Graham wrote:
I've got some good results with the dz80 disassembler on linux, it actually
does a decent job of recognising the text and shows it as such:
;
db'Telephone Details'; 1799
dwX0401; 17aa 01 04 ..
dwX0805
-Topic Posts
Subject: Re: Unknown 8085 opcodes
On 01/11/2017 01:26 PM, allison wrote:
> PC people would not think to do that as its rare for them to see 7Bit
> ASCII and the tools commonly used might not either.
I think that you sell "PC People" a bit short. The free version
On 01/11/2017 08:50 PM, dwight wrote:
> Even so, he said the code was
>
> for the 8741. It is not 8085!
>
In the interest of minimizing clutter, I didn't quote all of Mouse's
message:
--
I built a disassembler years ago to pick
Even so, he said the code was
for the 8741. It is not 8085!
Dwight
From: cctalk on behalf of Chuck Guzis
Sent: Wednesday, January 11, 2017 7:12:43 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Unknown 8085 opcodes
On 01/11/2017 06:45
On Wed, Jan 11, 2017 at 8:33 PM, Jon Elson wrote:
> On 01/11/2017 11:16 AM, Hayden Kroepfl wrote:
>>
>> Looking at the values it almost looks like it's ASCII text and
>> not actual code data.
>
>
> BINGO!!
>>
>> On Wed, Jan 11, 2017 at 10:10 AM, Adrian Graham
>>
>> wrote:
>>
>>> Example 8085 co
On 01/11/2017 11:16 AM, Hayden Kroepfl wrote:
Looking at the values it almost looks like it's ASCII text and
not actual code data.
BINGO!!
On Wed, Jan 11, 2017 at 10:10 AM, Adrian Graham
wrote:
Example 8085 code fragment:
3440 1792 09 DAD B
3441 1793 01 01 08
On 01/11/2017 06:45 PM, Mouse wrote:
> In case anyone is interested, I export it via git. The thing to
> clone is git://git.rodents-montreal.org/Mouse/disas, though it hasn't
> had much testing off my systems and thus probably contains
> localisms.
Does your disassembler do flow analysis?
At an
> Good list there, the onlinedebugger looked the most promising but it
> doesn't do 8080/8085 either.
I built a disassembler years ago to pick apart captured malware. By
now it handles about a dozen ISAs. While 8080 and 8085 are not on the
list, Z-80 is; adding 8080 would be a relatively simple
On 01/11/2017 01:26 PM, allison wrote:
> PC people would not think to do that as its rare for them to see 7Bit
> ASCII and the tools commonly used might not either.
I think that you sell "PC People" a bit short. The free version of IDA
Pro does recognize stuff like that, the last time I checked.
On 1/11/17 12:19 PM, Charles Anthony wrote:
On Wed, Jan 11, 2017 at 9:10 AM, Adrian Graham
wrote:
Hi folks,
Any 8085 assembler geeks in the house?
A uProcessor geek, but not 8085 :(
However, Wikipedia mentions:
" Undocumented instructions
A number of undocumented instructions and flags w
On 11/01/2017 19:24, "Al Kossow" wrote:
>
> since it's been brought up, and your forgot to mention IDA is a commercial
> product
>
> http://reverseengineering.stackexchange.com/questions/1817/is-there-any-disass
> embler-to-rival-ida-pro
>
>
> On 1/11/17 11:08 AM, shad wrote:
>> try to a
Hi Adrian
It looks like text, not code.
54 T
65 e
6c l
65 e
70 p
68 h
6f o
6e n
65 e
20 space
Henrik
Adrian Graham skrev 2017-01-11 18:10:
Hi folks,
Any 8085 assembler geeks in the house?
Official Intel docs don't seem to be helping with this one, I have 8085 and
D8741A peripheral controll
On 11/01/2017 19:24, "Al Kossow" wrote:
>
> since it's been brought up, and your forgot to mention IDA is a commercial
> product
>
> http://reverseengineering.stackexchange.com/questions/1817/is-there-any-disass
> embler-to-rival-ida-pro
Good list there, the onlinedebugger looked the most prom
On 01/11/2017 09:34 AM, Fred Cisin wrote:
> Looks more like data, than code.
Indeed--the giveaway for x80 hackers is the string of seemingly
nonsensical register moves--although I've seen "trick" code that does
employ them to actually execute someone's name...
--Chuck
On 11/01/2017 19:08, "shad" wrote:
> Hello Adrian,
> not sure if 8085 is supported, but try to analyze your dump with IDA
> Disassembler.
> It's really amazing in analyzing the code, and reconstruct automatically,
> or with small effort, a readable trace of functions jumps, strings,
> symbol
On 1/11/2017 10:48 AM, dwight wrote:
My disassemblers always make a list and count of addresses accessed
by any non-indirect reference. If I see a blank line in the code,
without any references, I get suspicious.
How can the code execute this location if it is never referenced??
I can then
since it's been brought up, and your forgot to mention IDA is a commercial
product
http://reverseengineering.stackexchange.com/questions/1817/is-there-any-disassembler-to-rival-ida-pro
On 1/11/17 11:08 AM, shad wrote:
> try to analyze your dump with IDA
> Disassembler.
Hello Adrian,
not sure if 8085 is supported, but try to analyze your dump with IDA
Disassembler.
It's really amazing in analyzing the code, and reconstruct automatically,
or with small effort, a readable trace of functions jumps, strings,
symbols, etc
Andrea
On 11/01/2017 17:23, "Tony Duell" wrote:
>> 3463 17AD 08 UNRECOGNIZED
>> 3464 17AE 17 RAL
>> 3465 17AF 53 MOV D,E
>> 3466 17B0 65 MOV H,L
>> 3467 17B1 6C MOV L,H
>> 3468 17B2 65 MOV H
[?]
Dwight
From: cctalk on behalf of Tony Duell
Sent: Wednesday, January 11, 2017 10:08:28 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Unknown 8085 opcodes
On Wed, Jan 11, 2017 at 6:01 PM, Fred Cisin wrote:
> Quite realistic would be fo
On 11/01/2017 17:49, "Fred Cisin" wrote:
> .COM V .EXE file extension)
>
>> I'll have a closer look at DASMx's parameters when I get home, that's the
>> freeware one but it seems to make a better job of it than the commercial
>> version, though both the D8741A and ROM dumps produce the same unkn
There is a fairly steep learning curve, but you may
want to consider getting a MAME simulation of the device running.
There are some pretty powerful tools in the debugger for analyzing
things like I/O port references etc. and it can deal with debugging
in environments where multiple microprocessors
On Wed, Jan 11, 2017 at 6:01 PM, Fred Cisin wrote:
> Quite realistic would be for a disassembler that couldn't recognize an
> opcode to display it as
> DB 1A ; Esc
> DB 65 ; 'e'
> DB 09
I once used a disassembler (I can't remember for what CPU) that would
put a comment on each line giving the asc
Quite realistic would be for a disassembler that couldn't recognize an
opcode to display it as
DB 1A ; Esc
DB 65 ; 'e'
DB 09
Code immediately following an unconditional JMP is likely to be data, but
could just as easily be the destination of some other JMP, so a
disassemble can't make assumpti
On Wed, 11 Jan 2017, Adrian Graham wrote:
Well, this is ROM dumps of a telephone system so that would make sense for
some of it, but surely a disassembler should also recognise that it's ASCII
string data and treat it accordingly? I can imagine a freeware disassembler
maybe making that mistake bu
Well unless the code is running a disassembler has no real clue, because as
you can see ASCII corresponds mostly to completely valid instructions,
mainly the MOV reg,reg instructions. Depending on how the code's written it
could be basically impossible for a disassembler to tell.
For example you
Looks more like data, than code.
Telephone Details.Select
On Wed, 11 Jan 2017, Adrian Graham wrote:
By the same reasoning 0xD9 could be XRL A,R1 (opcode 11011xxx) and 0xDD
could be XRL A,R5 but can't match the others. Also the surrounding code
doesn't mention those registers.
Exampl
Hi all,
Well, this is ROM dumps of a telephone system so that would make sense for
some of it, but surely a disassembler should also recognise that it's ASCII
string data and treat it accordingly? I can imagine a freeware disassembler
maybe making that mistake but the second one is commercial.
I'
On Wed, Jan 11, 2017 at 5:10 PM, Adrian Graham
wrote:
> Hi folks,
>
> Any 8085 assembler geeks in the house?
>
> Official Intel docs don't seem to be helping with this one, I have 8085 and
> D8741A peripheral controller dumps both containing several opcodes that two
> disassemblers aren't recognis
Sorry for the double reply.
It's definitely ASCII data and not code. There's also seems to be some
other constant data in the middle, but translating the byte values as ASCII
gives:
"Telephone Details [few odd bytes]Select "
Where [few odd bytes] is 01 04 05 08 which is presumable some other
const
On Wed, Jan 11, 2017 at 9:10 AM, Adrian Graham
wrote:
> Hi folks,
>
> Any 8085 assembler geeks in the house?
>
A uProcessor geek, but not 8085 :(
However, Wikipedia mentions:
" Undocumented instructions
A number of undocumented instructions and flags were discovered by two
software engineers,
Another possibility could be self-modifying mode, something somewhere else
could be writing over this code once it's running. Though that would be
assuming it's in RAM. Though the code around these instructions seems
confusing. Looking at the values it almost looks like it's ASCII text and
not actu
Hi folks,
Any 8085 assembler geeks in the house?
Official Intel docs don't seem to be helping with this one, I have 8085 and
D8741A peripheral controller dumps both containing several opcodes that two
disassemblers aren't recognising and any docs I've been looking through for
either 8085 instruct
54 matches
Mail list logo