ELF loading
in [ASM]
|
From: Betov on 27 Aug 2007 12:23 santosh <santosh.k83(a)gmail.com> �crivait news:faur9d$i83$1(a)aioe.org: > Provide an option for encrypting the sources and it will be even > more "secure". ? And what will prevent from overwritting the "encrytion" ? > Ah, so you store a checksum for the source section and add a stub to the > executable section that compares this checksum against a newly generated > one? This is a simple checksum of the whole file. > Also have you noticed any slow-down in loading time for files with large > sources? Just imagine a RosAsm app which had about, say, 50 Mb of source > embedded in it. Will this cause problems during loading? Any idea? No idea. The biggest source ever written with RosAsm is RosAsm itself, and RosAsm is one of biggest Assembly Source ever written. "Hostile Encounter" (an Assembly game) is the winner (by far), because it embeeds "Sprites created by Code". That is, the repetitive creation of the Sprites takes, i suppose, more room than the BitMaps would. This is a bit special (like the fellow who wrote this :) So, thinking of a 50 Megas sources is something utterly out of scope. Now, if it could exist, would it slow down the loading? I really do not know, but i think yes. The main problem would not be with the Memory, but with the RosAsm Editor itself, which works in a very special way, for splitting the Mono-Source into Sub-Sources (TITLEs). The main problem would probably be with some operations that require 1) full sources re-organization, 2) Operation (for example a Right-Click Search), and 3) the partial Source mode restoration, when the function has done its job. It is evident that there is a limit, after which the responsivity would become boring, but I do not know where this limit is, actually, and we will much probably never reach it. Betov. < http://rosasm.org >
From: santosh on 27 Aug 2007 12:30 Betov wrote: > santosh <santosh.k83(a)gmail.com> �crivait news:faur9d$i83$1(a)aioe.org: > >> Provide an option for encrypting the sources and it will be even >> more "secure". > > ? And what will prevent from overwritting the "encrytion" ? Nothing, but the point of encryption is to prevent those whom you don't want to see or use your source, from doing so. I know that this is not in keeping with the spirit of the GPL, but if RosAsm is ever going to be use in commercial environment, for profit, then the user might want encryption of the source and/or the whole file. >> Also have you noticed any slow-down in loading time for files with large >> sources? Just imagine a RosAsm app which had about, say, 50 Mb of source >> embedded in it. Will this cause problems during loading? Any idea? > > No idea. [ ... ] > So, thinking of a 50 Megas sources is something utterly out of > scope. Now, if it could exist, would it slow down the loading? > I really do not know, but i think yes. The main problem would > not be with the Memory, but with the RosAsm Editor itself, which > works in a very special way, for splitting the Mono-Source into > Sub-Sources (TITLEs). The main problem would probably be with > some operations that require 1) full sources re-organization, > 2) Operation (for example a Right-Click Search), and > 3) the partial Source mode restoration, when the function has done its > job. It is evident that there is a limit, after which the > responsivity would become boring, but I do not know where this > limit is, actually, and we will much probably never reach it. I was actually talking about the PE loader and possible slowing down of it.
From: Betov on 27 Aug 2007 13:04 "sevag.krikorian" <sevag.krikorian(a)gmail.com> �crivait news:1188231628.676062.139010(a)r29g2000hsg.googlegroups.com: > Among other > problems, your IDE has the most useless tree views around. :)) Personally, troll, i do not like this TreeView, and i never use it. Nevertheless, feel free to explain how a TreeView could be "useless". Betov. < http://rosasm.org >
From: Betov on 27 Aug 2007 13:14 santosh <santosh.k83(a)gmail.com> �crivait news:fauu7o$rj0$1(a)aioe.org: >> ? And what will prevent from overwritting the "encrytion" ? > > Nothing, but the point of encryption is to prevent those whom you > don't want to see or use your source, from doing so. Heeeuu... if you don't want others to see your source, you provide a version without source inside. As simple as this. > I know that this > is not in keeping with the spirit of the GPL, but if RosAsm is ever > going to be use in commercial environment, for profit, then the user > might want encryption of the source and/or the whole file. RosAsm does not force the user to GPL, at all. There is a Side-Toy (SourceKiller.exe), for removing the Sources from a RosAsm-made PE. Betov. < http://rosasm.org >
From: rhyde on 27 Aug 2007 14:10
On Aug 27, 9:23 am, Betov <be...(a)free.fr> wrote: > > No idea. The biggest source ever written with RosAsm is RosAsm > itself, and RosAsm is one of biggest Assembly Source ever written. Far from it, dude. You do realize that OS\360 was written in assembly? It was just a *little* bigger than <name stolen from ReactOS>:RosAsm. You do realize that many of IBM's compilers for the 360 were written in assembly? They are just a *little* bigger than RosAsm. > "Hostile Encounter" (an Assembly game) is the winner (by far), > because it embeeds "Sprites created by Code". Not even close. See the above. The scary part is not that you are checking the checksum (easily defeated by someone creating a virus, btw). The scary part is that you are adding code to the user's program that they did not write themselves. And then you scream "not an assembler" when other products do similar things. hLater, Randy Hyde. P.S. "Security" has nothing to do with keeping the source code with the binaries, btw. You should learn the "basics of security" before making such absurd claims. |