English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 17 November 2014, 17:05   #1
stainy
Zone Friend
stainy's Avatar
 
Join Date: Mar 2001
Location: Concord, NC, USA
Age: 50
Posts: 1,550
Send a message via ICQ to stainy Send a message via MSN to stainy
I`m surprised..

Now.. I have very very little coding knowledge.. I can script in unix.. and I`m now just starting in Monkey-X but..

I`m surprised in this day an age that we can`t de-compile code, break in and whatnot. ... especially Amiga games..
Like I said.. I have no knowledge at all..so please be gentle with your replies.
stainy is offline  
Old 17 November 2014, 17:10   #2
ajk
Registered User
ajk's Avatar
 
Join Date: May 2010
Location: Helsinki, Finland
Posts: 1,323
What makes you say that we can't de-compile code? Amiga games have been cracked and patched for as long as they have existed.
ajk is offline  
Old 17 November 2014, 17:13   #3
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,664
Amiga games have been reverse engineered since the dawn of time! What makes you believe that this isn't possible?

If you REALLY mean decompiling, well, there's no decompiler that runs on Amiga but IDA Pro has an (expensive) decompiler plugin.
StingRay is offline  
Old 17 November 2014, 19:48   #4
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 3,204
Quote:
Originally Posted by StingRay View Post
but IDA Pro has an (expensive) decompiler plugin.
Which doesn't support M68K sadly. (Though kind of academic considering what an IDA Pro + Hex-Rays license would cost... )
mark_k is offline  
Old 17 November 2014, 19:54   #5
stainy
Zone Friend
stainy's Avatar
 
Join Date: Mar 2001
Location: Concord, NC, USA
Age: 50
Posts: 1,550
Send a message via ICQ to stainy Send a message via MSN to stainy
I guess what I mean is changing all the code from compiled back to source again ( complete source )

Is that do-able now?
stainy is offline  
Old 17 November 2014, 20:02   #6
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by stainy View Post
I guess what I mean is changing all the code from compiled back to source again ( complete source )

Is that do-able now?
It's doable but it's difficult and the results won't be 100%. Here is a similar thread about the topic:

http://eab.abime.net/showthread.php?t=53210
matthey is offline  
Old 17 November 2014, 20:51   #7
ajk
Registered User
ajk's Avatar
 
Join Date: May 2010
Location: Helsinki, Finland
Posts: 1,323
Quote:
Originally Posted by stainy View Post
I guess what I mean is changing all the code from compiled back to source again ( complete source )
Think about what you are asking. Depending a bit on the language, there is no direct relationship between a compiled binary and the source code that it was created from.

With assembly there is a reasonably straightforward link between machine code and source code, but even under the best circumstances you'd be losing all comments, variable names, macros, how the code is organized into different files, etc.

With C, for any non-trivial program there is essentially an infinite amount of options the source code might look like. Same goes for Basic and any other compiled language really.

It's a one-way street.
ajk is offline  
Old 17 November 2014, 21:17   #8
stainy
Zone Friend
stainy's Avatar
 
Join Date: Mar 2001
Location: Concord, NC, USA
Age: 50
Posts: 1,550
Send a message via ICQ to stainy Send a message via MSN to stainy
Well it doesn`t matter what I`m asking.. I said I have no idea.. hence no idea that it`s a one way street.
Now I know so thanks
stainy is offline  
Old 18 November 2014, 06:19   #9
ajk
Registered User
ajk's Avatar
 
Join Date: May 2010
Location: Helsinki, Finland
Posts: 1,323
Well, I assume that before anyone asks a question on the forum he has first thoroughly researched the matter using Google and what have you

But essentially the problem is this: if I give you the value 10, what was the computation that led to it?

It could be 2 + 8 or 5 x 2 or it might have been just 10 to start with. You can figure out a solution that works, but you can't be sure it's exactly the same as the original.
ajk is offline  
Old 18 November 2014, 07:04   #10
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by ajk View Post
But essentially the problem is this: if I give you the value 10, what was the computation that led to it?

It could be 2 + 8 or 5 x 2 or it might have been just 10 to start with. You can figure out a solution that works, but you can't be sure it's exactly the same as the original.
That's a little over simplified. An equation can usually be derived from the disassembly. Compares, branches and jump tables can usually be spotted that were once if-then, if-then-else and case statements. There are several ways that they can be written and organized though. The whole project that was once many C files would now be one big C file. The disassembly process is not 100% to begin with either. If I could get 100% disassemblies I could run an optimizer and reassemble with vasm doing peephole optimizations. Unfortunately, the disassembler I have worked on developing can only disassemble and reassemble 50%-75% of programs without a problem and errors can be difficult to detect.
matthey is offline  
Old 18 November 2014, 07:09   #11
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,664
Ajk put it in layman's terms and described the problem pretty well! Basically, everything can be disassembled and converted to working code again, the question is how much time one is willing to spend to achieve this. For high level languages this is a lot more difficult and complex than for stuff that was done in 100% asm!
StingRay is offline  
Old 19 November 2014, 23:23   #12
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,242
one thing that is difficult for a decompiler to do with Amiga code is tell which bits are code and which bits are data. especially if tables are used to store addresses of subroutines. "best practice" might be always to store data in a different hunk in the executable file, but not everybody does this!
Mrs Beanbag is offline  
Old 20 November 2014, 06:52   #13
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,664
Quote:
Originally Posted by Mrs Beanbag View Post
one thing that is difficult for a decompiler to do with Amiga code is tell which bits are code and which bits are data.
This problem is not specific to Amiga disassemblers, it's a general problem.
The code has to be carefully examined to identify what's data and what's code. And tables aren't a real special case here as these are handled just like any other code. The only difference is that there are a lot of different possibilities to create routines which deal with jump tables.

Quote:
Originally Posted by Mrs Beanbag View Post
"best practice" might be always to store data in a different hunk in the executable file, but not everybody does this!
This is not always possible or feasible (what if you need 100% pc relative code? Possible, yes, but requires extra work if different hunks are used!) and not really required anyway IMHO. Besides, anyone who programmed a game back then probably didn't waste a single thought about how to make disassembling easier.
StingRay is offline  
Old 20 November 2014, 10:03   #14
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,008
Quote:
Originally Posted by Mrs Beanbag View Post
"best practice" might be always to store data in a different hunk in the executable file, but not everybody does this!
Depending on the host OS it makes sense for writable data, but not for read-only data. The PC-relative addressing modes of the M68k were designed to reference read-only data in the code segment.

As Stingray already mentioned there is no such requirement for AmigaOS at all (although I'm trying to avoid writable data in code sections). It is required for Unix, or other operating system with memory protection, which use the MMU to write-protect the code segment.

BTW, reassemblers can identify most of the code and data by following all branches and sub-routine calls in the program. It only becomes difficult with indirect jumps, using function pointers from the data.
phx is offline  
Old 21 November 2014, 20:01   #15
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Mrs Beanbag View Post
one thing that is difficult for a decompiler to do with Amiga code is tell which bits are code and which bits are data. especially if tables are used to store addresses of subroutines. "best practice" might be always to store data in a different hunk in the executable file, but not everybody does this!
As phx says, moving static data to another hunk may be less efficient (it's fine for small data until hitting the 64k ceiling). You are correct that this static data in the code section can cause disassembler detection problems but this is how 68k compilers generate code. Using symbols can greatly improve disassembly success (and stay away from questionable assembler tricks). Most disassemblies of vbcc compiled programs using ADis are very accurate. It's great for testing low level code changes where I can usually disassemble, make some changes and reassemble.

I also recommend avoiding writable data in code sections (which most compilers avoid). It usually doesn't affect disassemblies but could be bad or at least less efficient when caches grow on new 68k fpga processors.
matthey is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Surprised there's no video reviews of Gods Castelian Amiga scene 5 10 March 2011 14:18
Now click this old link and be SURPRISED! andreas Amiga websites reviews 7 20 November 2001 19:50

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 09:39.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.10790 seconds with 15 queries