I don't have VB or anything installed, as I have absolutely no clue how to properly code (I can read and understand super basic code) - but I have no clue about any functions/ methods etc.
I've got a Lua file that I want to decode/ be able to actually read this file. From what I've read here on stack overflow, I've gathered maybe it's not encrypted, rather in lua crypt or something? Any input would be much appreciated! Thanks!
Here's the code:
FXAP JÈŸ‘Ä#I«ILmOÿ‰ýÚn_ô0J8ôã*2-¿ã´*¶p‹ý
Ëí}ý_A>¢AaÁ`®E÷„êÝ6g¿¿£¹®îãöà€•ãûÛ'—À]M™)bñà?W·S ›(Vâ†É(þ“ñמQ&|#Å´c•HX²¡<d¿CÖÖ[d×A“¨ò“>'fÈîÍ ¿¥±v´ô2Ys2Ñ‚:b/¥˜à¹Ü¬Å H~ß 9SºM‘FCú®}Ñ:Šè|¹7|]òC§CcKX|¾,#
Ž¤6ÚÖ\ºÂZ†ãï¥~t,‘?±…÷ï/è’±Q_™œê'ôYÖenŠ`äCÑ#“IÅ_Kà€þÒ´ek:QýÚ‚ò&ÿO±!ÁÓGâhÏĽD²ÓdŸñÎ^6D3òÚ„üD?ûÕá$‚eÒäúÞ5î72ä±dv¬]hHƒ
Y¤4 ÑÊ#!³-(icæ…*¢ƒ¿þÛLþÉ®±ß¶)îFe!S$ÜS|ƒ¹C¶hl—Ã-í®Ì:+ôÆSD¦¨ÌÅfÌhÕnÉ:_cÔ·Âä"ÏpßÅ7vÅi¸€ß†Mf~÷IBgÕ½
#ÊEüÈÉÙ5¥´·6g†^.æ`Z/Ð[ÏcÁÊ8ô4y[›—A¨›ÿ0j’ºrèyÖ$ÇÿD7"7}è:g
|Ðò¢n¬m8-`{I²Èû«°6˜ê”×o<ñ9*FÔåeDˆ€Åûà]ªý·gÈÿ¥íªCÏâÜá0Ðf¯uÒ·’Æ1<L¹±M¤˜~ïÒ)ÑfQÃq\aň½3K ÐàÀ}ŒXÂœg°’¢d|¹ÛŠ"®£öƒ?È B¼4®½ÎmŸ—r¾)Ù’dçÒ
>L©NN*†q&NòbOñ«ªŸÅ÷S[;×úB ÉS!˼×Yö“í«ÚXÎ]óÜ”®V Véeú"ˆZåZÃE/5GïÊýUÉd–‚ /¼Rd—ƒÅ%Ñà_ÚuŽõ¨·çö}ˆ /y“Ùèø…°åñ ˜Žî$¬¸NfHþqó•¨=€¦}d¨.îÓ±"ÂnãR =8Fx<›ötuèu‘í*Ÿxa Õ½
ç2ÃÓ8¯ —û–7,Š´2ý’5êÒfRè×íX¼’ühA"µsEÕƒ†×¯!Œ˜rp²Gòä×`þ/ àÃ(%B˜UÀð´÷²©ÏëÇ
wY•ƒå™/×)ú·]qÇx›P
~d{#
¶ ¬À€r~…Ûíü£Vn}QÙäJÜ[³dJÁš8±ÌèÏb×ÿÆñ'*ƒŠ*K`›éw=Þ¢’®ÁK¿šÍ"¯×¹
HdÈQãí–y}3ÂOäÞÃRÇ'uG& VY1
ôÚ<lk ®·Êïݲ´ÄEô+}ƒÞó„`Txs¨Ý©ãáOkÂCÇ.’á„oÚæ0‚ê¶iø̉æ9Ä9ºík]y¿ñI‚Õ=\{ñü•ñÎáÚ4Ù$íi—˜ÎEB‘Šªmha-9÷œû
Tried basic research, online encryption detection websites (None worked)
Related
I am a beginner to programming. I am trying to run a simulation of a combustion chamber using reactingFoam.
I have modified the counterflow2D tutorial.
For those who maybe don't know OpenFOAM, it is a programme built in C++ but it does not require C++ programming, just well-defining the variables in the files needed.
In one of my first tries I have made a very simple model but since I wanted to check it very well I set it to 60 seconds with a 1e-6 timestep.
My computer is not very powerful so it took me for a day aprox. (by this I mean I'd like to find a solution rather than repeating the simulation).
I executed the solver reactingFOAM using 4 processors in parallel using
mpirun -np 4 reactingFOAM -parallel > log
The log does not show any evidence of error.
The problem is that when I use reconstructPar it works perfectly but then I try to watch the results with paraFoam and this error is shown:
From function bool Foam::IOobject::readHeader(Foam::Istream&)
in file db/IOobject/IOobjectReadHeader.C at line 88
Reading "mypath/constant/reactions" at line 1
First token could not be read or is not the keyword 'FoamFile'
I have read that maybe some files are empty when they are not supposed to be so, but I have not found that problem.
My 'reactions' file have not been modified from the tutorial and has always worked.
edit:
Sorry for the vague question. I have modified it a bit.
A typical OpenFOAM dictionary file always contains a Foam::Istream named FoamFile. An example from a typical system/controlDict file can be seen below:
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object controlDict;
}
During the construction of the dictionary header, if this Istream is absent, OpenFOAM ceases its operation by raising an error message that you have experienced:
First token could not be read or is not the keyword 'FoamFile'
The benefit of the header is possibly to contribute OpenFOAM's abstraction mechanisms, which would be difficult otherwise.
As mentioned in the comments, adding the header entity almost always solves this problem.
I've been using Cloud 9 (ace-editor) for a while, and recently we made an local server-cache solution that allow us to store local cachefiles of previewfiles from cloud9.
When I include a file directly from preview.c9, it works! But when I run the local cache version I end up with a file looking like this
‹������ÅXmoÛ6þî_Á¹Ü‘å·$ŽŠaÅú2 Y»�Éö¥ÛJ¢mV/Ô(*MZô¿ïŽ/2¥ÈA‹í‡$6yw<Þ=÷Ü1Ï’•5Sdüçõ«`=~:z¶¥
64aäãˆûàù]D&q“òD”“§°SË$"ÌOÂ0ͧ©U,n›šIP¬TÓDa.V'ç'³³y˜¤e Y-™°:Lr2ÁV6¥
+)2æ 'ƒ&—¸’†xxhÏœ2¡~^-ÖëÓ“³ÅäÉ÷öàg~;y’U'¬ˆYš²4Üë®b“'Çß2<ïÅfãŧõ ׿±+J
z¢dþC`ê›m—GÀû¼Á¶A“Fú{Æ·;‘³š#Èôrîr¶_ý4ŠEzw<ªŽGuEËãÝ×JÍ?€ä|]ݶÚjËçòš\Ѳž“þP*|ótôi´›÷õWV¿ rËË J‰""Ëš…E_a±òt·ˆEž¢‰È…ŒÈ£Ùl†ÚÓX•Z?2e°1¯nI-rž¢ÈâùÉ
•Ìf iÊ›:" é‚ѹáÞ¶STìV)K„¤Š‹ÃV2Ô®DÍÍŠd9ìÝèÕ”×UN]x™ó’q.’ŒüÀ‹JHEK¥5išòr‘Ss¼þÈFú*•‘r¶ôN䢘A±ZÛ»Bc¸y£»‚ç[F‹ÈxŒ_cšd[)š2
xA·oäÁRU}&*)ÊtÇ8^±
y!’!zU¿ÃS€¥æ8ï(É*F56Fñ#º&4` “ÿ÷<U»ˆ,t�:ž`âM(/QÕ„jn!…á|«�nLý4ŽsZŽÿéDVšƒVÈGt®µÚˆMþfñìTw ]J®l%¢#¦ÄQµÙ#¹{.ÏážG!¬Ù›ÒF ñu’ÃéV¢ŠH�à÷£1û¿Y8Eê˜Ò"UCÔUÒÛ$§u
1C,½ ݇ã=qú?pÙ‰è؆TCÔÅËáÂ1†p#• (¹²YÔµT¤ƒfxÈ ÓðF�øÓÍÐcººÛ�RIJ뢇_4¥#ìûáGªØø•-��j²)K}}³³3t§Ÿ9Ÿ‹|ðï,Ò}”«
Çm`Ï h\Ìá{'¢ֺ-¤¹-Ñ>ÅÛå=d}²üð2e·Pà÷£CøFÒÂðÛÏ–ßØ3©ð¨€Ö
Ž®`ˆåçƒÜÌaÍOškS³a¼\!²Ì¼ÐnÞ±èëáEgÚ«>›˜™`OKºÿb<ÔÛfH+PÖ–¿°Óú°¶¬‡·MÍt~Â
]¾v08 =â``ìöÙSëW[_~GC¼¶Éëwi0?]{øûõyðœ–
t»Yßo7_—7ô_
m‡àÁªuÖ¶ ×躳¤[í´¿¶ýÀ¼¥n9U'¥Èô(DH>~RôÈçÓÝl¢hœú°³ÉiUÃ|ã>íÁÀä›è™ ˜h¨ý* 3nE%¼†P ÇH½GŸ½›8úµ³îË”«×¬l®¹ÂQüx%ÖÌÏ0p ùç;ZnÙËœpÞ5<¿"‚ï
Üršo€#rÅ2±jÑÐõRçó³¼fy.
…<’£~e‹þ£wžõô*ãyÎ4×hO»î\JžeL1CFž)¿õvUzýutæ¦úwP+É+è®\Óüˆ‰V4u-í0F;&„¯á‘ÉÊàùRnQiw2uá\µ—Õ”:Ü_˜¤kɲ¬® päóÏ í«¥wÄEI«ÊØw;ÆÍßé–d¸ÙªïŸ NÒºù[†C·‘ÓcÐÏÀÅ/í|î n%v¢¿JªŸvtªí%úQã§Äøx‘ H¿gL Øû ×=¹¸‰]±º»X|—,Æv=qü·LÆî ¿A4†«(Js5 ú‹l çžÕ*Jš>×uâBox’7Ï´®Ø%>D0µ:F5¼>N½Rï˜Äd+˜Šd#î…È,~O0¡9+ÓA«z«s›ÙnȨцGúél¼„øýÊ{#¶-ȼ´¸ÆÉaºL¡gù
1‡Î鬧 ‘ó€BÊPâ] è°Òz‰ÔwËé°
oT�P¨Ìú*X‡5ÎÙyï�Øâñ¢'ŽX–Çì-ú±Ä”^¯úÆ쪜Ÿë\x‰0Ø;¨°ŽÏô`lþZvx²��
Any idea of whats cousing this?
PS: Sorry for poor english
Found an error in the encoding import.
I will return with the error / and fix as soon I get it firmly tested.
I need to import the Geonames database (http://download.geonames.org/export/dump/) into SQLite (file is about a gigabyte in size, ±8,000,000 records, tab-delimited).
I'm using the built-in SQLite-possibilities of Mac OS X, accessed through terminal. All goes well, until record 381174 (tested with older file, the exact number varies slightly depending on the exact version of the Geonames database, as it is updated every few days), where the error "expected 19 columns of data but found 18" is displayed.
The exact line causing the problem is:
126704 Gora Kyumyurkey Gora Kyumyurkey Gora Kemyurkey,Gora
Kyamyar-Kup,Gora Kyumyurkey,Gora Këmyurkëy,Komur Qu",Komur
Qu',Komurkoy Dagi,Komūr Qū’,Komūr Qū”,Kummer Kid,Kömürköy Dağı,kumwr
qwʾ,كُمور
قوء 38.73335 48.24133 T MT AZ AZ 00 0 2471 Asia/Baku 2014-03-05
I've tested various countries separately, and the western countries all completely imported without a problem, causing me to believe the problem is somewhere in the exotic characters used in some entries. (I've put this line into a separate file and tested with several other database-programs, some did give an error, some imported without a problem).
How do I solve this error, or are there other ways to import the file?
Thanks for your help and let me know if you need more information.
Regarding the question title, a preliminary search resulted in
the GeoNames format description ("tab-delimited text in utf8 encoding")
https://download.geonames.org/export/dump/readme.txt
some libraries (untested):
Perl: https://github.com/mjradwin/geonames-sqlite (+ autocomplete demo JavaScript/PHP)
PHP: https://github.com/robotamer/geonames-to-sqlite
Python: https://github.com/commodo/geonames-dump-to-sqlite
GUI (mentioned by #charlest):
https://github.com/sqlitebrowser/sqlitebrowser/
The SQLite tools have import capability as well:
https://sqlite.org/cli.html#csv_import
It looks like a bi-directional text issue. "كُمور قوء" is expected to be at the end of the comma-separated alternate name list. However, on account of it being dextrosinistral (or RTL), it's displaying on the wrong side of the latitude and longitude values.
I don't have visibility of your import method, but it seems likely to me that that's why it thinks a column is missing.
I found the same problem using the script from the geonames forum here: http://forum.geonames.org/gforum/posts/list/32139.page
Despite adjusting the script to run on Mac OS X (Sierra 10.12.6) I was getting the same errors. But thanks to the script author since it helped me get the sqlite database file created.
After a little while I decided to use the sqlite DB Browser for SQLite (version 3.11.2) rather than continue with the script.
I had errors with this method as well and found that I had to set the "Quote character" setting in the import dialog to the blank state. Once that was done the import from the FULL allCountries.txt file ran to completion taking just under an hour on my MacBookPro (an old one but with SSD).
Although I have not dived in deeper I am assuming that the geonames text files must not be quote parsed in any way. Each line simply needs to be handled as tab delimited UTF-8 strings.
At the time of writing allCountries.txt is 1.5GB with 11,930,517 records. SQLite database file is just short of 3GB.
Hope that helps.
UPDATE 1:
Further investigation has revealed that it is indeed due to the embedded quotes in the geonames files, and looking here: https://sqlite.org/quirks.html#dblquote shows that SQLite has problems with quotes. Hence you need to be able to switch off quote parsing in SQLite.
Despite the 3.11.2 version of DB Browser being based on SQLite 3.27.2 which does not have the required mods to ignore the quotes, I can only assume it must be escaping the quotes when you set the "Quote character" to blank.
Ada is still new to me, so I am trying to find my way around the GPS IDE. I asked another question earlier, but I think this problem has precedence over that one, and may be at the root of my trouble.
When I compile, I am getting a long list of *warning: source file ... not found"
In my .gpr file, I have listed all of the spec and body source files and use the following naming scheme:
package Naming is
for Casing use "mixedcase";
for Dot_Replacement use ".";
for Spec_Suffix ("ada") use "_s.ada";
for Body_Suffix ("ada") use "_b.ada";
end Naming;
What is odd it the error messages all look either like this:
warning: source file "xxx_b.adb" not found
or this
warning: source file "xxx.adb" not found
Note that neither of these (xxxb.adb or xxx.adb) conform to the file specs, which should end with .ada.
Can someone explain what is going on here?
I'm 99% sure that the problem is one of the ones I mentioned in answer to your other question: GNAT does not normally support more than one compilation unit in a file. I got exactly the behaviour you describe with GPS and these files:
james_s.ada:
with Jane;
package James is
end James;
jim_s.ada:
package Jim is
end Jim;
package Jane is
end Jane;
The error message on compiling james_s.ada says it can't find Jane_s.ada, but when I ask GPS to go to the declaration of Jane it takes me to the "correct" line in jim_s.ada.
You could use gnatchop to split jim_s.ada, but it doesn't understand project files or naming conventions; you probably want to keep the existing names for the code that works, so you'd rename gnatchop's output as required.
However! to my great surprise, it turns out that GNAT does support having more than one compilation unit in a file, provided package Naming in the project file tells it about each unit in the file:
package Naming is
for Casing use "mixedcase";
for Dot_Replacement use ".";
for Spec_Suffix ("ada") use "_s.ada";
for Body_Suffix ("ada") use "_b.ada";
for Spec ("Jim") use "jim_s.ada" at 1;
for Spec ("Jane") use "jim_s.ada" at 2;
end Naming;
It's up to you whether to do this or to bite the bullet and use gnatchop, either on the multi-unit files or on the whole source tree.
First off, this isn't an Ada problem, its a Gnat problem. Other Ada compilers have no problem with the file names you are using.
However, Gnat is rather unique in that it expects there to be only one program unit (package body, package spec, stand-alone routine, etc) per source file. This is because it is also rather unique in that it expects to be able to find the source code for any program unit just by knowing that unit's Ada intentifier. Most other Ada compilers maintain some kind of library file that maps file names to program units, and you have to register all your files into it. (Whereas your typcial C compiler just leaves the problem of finding files for all your code up to the user entirely).
Generally the easiest thing to do with Gnat, the way that will cause you the least trouble, is to just use its default file naming convention (and of course don't put multiple program units in a single file.
If you already have some existing Ada code (perhaps developed for another compiler), the easiest way to import it into Gnat is typically to run the gnatchop tool on it all. So that's what I'd suggest you try.
From GPRbuild User's Guide:
Strings are used for values of attributes or as indexes for these attributes. They are in general case sensitive, except when noted otherwise [...]
Based on this, I believe you have to use "Ada" instead of "ada" as index for Spec_Suffix and Body_Suffix. I currently do not have access to the tools for testing this, so I suggest to just try it out.
I developed a new method of encrypting information. It does not comply with standard methods of encryption and was custom made to encrypt info stored in session cookies.
It basically works like this:
-It takes a standard 72 char string as it's IDENTITY or password. There could be more than a million variations of this.
It then uses a pre-defined set of randomly generated variations of text and uses that to hide the actual content. However, it has special chars hidden in each enrypted line to help identify how to decrypt it.
My reason for posting here is to see if anyone here could (a) crack it or (b) give me some advice on how to make it better.
I am not too reluctant to give too much info yet as this is still in aplha stage and not the finished project.
Here is an example. It is the 50 US states in random order. Please note that even if I keep the same order, each time it will look different. To prove that, I will run it twice with the same order used:
First Run:
H39pwxMnczu+#u!?:IeQAAeSPrjJFRZ84#zma-XbMaU7#F|Bm!6o3qgnJ3 cFIoTYNS|dAfVa
ibes!zd!O-e4sxx8yOo!?hTvK-f6htqlRxT?pV3CT--l4vU#7TInYV-WXNFil-t3+tG+:9b5X
?9#2Ncfn8AUim!3LZw#s5YRqF5Xfwm1:sCO?B90ViBQkmW?MlHn1h4Pd5AU8Lw QYwzr8IxhB
0r!mccmccmffmRzbapQ_dSjm+9#5jRR_IlqvWjY:Z9RfiABL_Rp#Dp!DyP?HiAB#9+HXRp?1x
SHjCpl+lvLvKVECH#bY+jn?T_-:1T7M#x?4uQ!bsJglVmc5dHN79HUF58|sTVDIp#jN__8tIk
?5ErfVd2N9TgcR3pWE#Dw98FYnUT9BHlBolV:mPFYnHw5P69BmJhWo|fYYL25P?rguINWY+f4
P?6QBXUxyYg3iWNpVL2FoBd-s UaqyAaOc M#2xd6ewglq??MZe4nD-#UnW3H6Fa?TIAdegkd
ERM?yyKtW_IydIOm77ia:9ao8 o#RcB8u_G3Jwox-K?0IC#S22GG0wQH-hfbptWSCCKo0Noaj
SRnCpwIzQv2CwvtH_Qt2RUT9ms#TDY9#Jb9J88m_V5xmQL_Gnj_9kO5JiRYVN0pY?YW_RnI9g
rDVUGkUuEg76dDXVawq|SImE8MyKKDDmar+|vHh93?y88SwmFwtYvzCNEA52n:eCfu1PGgH k
RO6ZAV7VO3S:3WWz+1LGzlb+o#!+:xyL3BKA1jIHArAd+K#4:5k2 Oi2Og2F|:DI+fxXL|f7G
DmqBiMZv2277kCjE# 6JPAorUURxk+xNB p?ew!cnuTz?GMqO8v63tJ7Mu TGoENfSN6Q4C7Y
!VMBYFY5YLadz0!TnjMrVA8Sr2rFdML-zR45:9m59i5e zg8dx0+T x?1LP79cFTnj:mc93w
S#?vL+v+i+mNXmV:W4ckvwjGMJRcQKAntLxgIH9KMWJQFTVb!Vxhlp9ELJ_7FVBU2YD:gJbAL
omUd_SFpmR_dXC RwigvHF67DObZdOZ-O_f6#egP4lMfP?BHzJZEiMj!bdEZQSfTsRBbWrzm:
09!mIINcG-n??B1-jQfdA#_lp|tG++M9jpedAJ_mpzd+P 7Ws5MD4Y#+p4dP97n0?HYR4!0Z+
cEtiKjA:6hfp+#D2ClS-2eH9e1dDsNZ7mN5vwR- a:EZ6j|3Py#I3ivk0hfp1|KIglp-Jz-d
|c9O:#Ue5Mk575P004EY 9QKC!5 cQ0ysIGgp46Z-r0 ZQyEIPLVo-HZXLN0RRiYbAYV0S_ZV
xXY#8SAwW ZB?Sr4OcL!ncpl+#m_W?iL5HAJ3 Z0Jol9|DyC-A80UgCm7zmr_8QMOpDmHE4XF
:r7:LlgSvzJuKm6oXy8r#XRMaJvNsnydX?N-rtt4Y73YsrwIXsf6nKoYf7Zc be:dj0ppKKh#
G-f8w8PPb-Z-oHp:BPAVDj-MHvSZyp0_E8k mwZvLLp?30AaFCUO!DUZ+h:#OS637Am6UXKUu
TcWQAUyQ:VJKv94zus2X9tn88p3vD34tgr2iupAwD+INKoMQuc?mXeZoouyKDohTm6 JoveXP
dP27Gb4iLdZ51w7YDr8#XTdisjQGrYII#BnX6P532?KH2r0LtS?D:nN6Q:2-_2lGDcZU3THX3
wAt9|j:9:OyvSwM8GmuFAN0zbg:eGXTUaknggG!bAgcqU62PgrkaxGCTXCtGlrF|lGq:XdUT1
np1lj08kyIC-qNcOpxAwjxS9Y|#A6g-dNJgxiDx+K6W?vp3jqpplpSDvTI:49N|16NHZNs :i
qA_92j6!YML9jMMF mv|b5NSS K97Seq|8JXS+5b2 zvmzf c+BCc qMmr|vyhVgc+xLhn_Oh
3O!9IS|9Vj9BY_G J-0: !zf!ZIGLjuq|Reqq9q4fuPt8vm0y5G0#H0p78zeYE6eGd3O sO+5
4KxCIUCRCe614E_K 5aI72VD297P BMP76eD|1VqjmRP uXjdF3jP|NiCBPoVUKmx1QT_skiB
rD_IvYESiE::6th4CKM67?:hNStD1:g _xH_jdY54#+y8YK+snh2|zyf0:we UtwCKHhcI:jc
j4vbZ0hkYSkr2!Vq5ua+rxT4mHUxGtLYEEXXxeTAmzsyG_vL4hX:xeArSKJq8ldm4ij2qklrx
848Tf?I76s?TZVDsSW7NW M6om3j+E6|jiIbOR_+5uD4US?14G|Nb9dD 961hLBj1zsb!0bZo
QefvLrM!sP:OmqqRRsHuCNV_BPG0O83RXsHCapIbJ75#N8czeJx5as7LxiFv#5cVydKyrsPL3
gJxaabTzbY!7LSCNsZ-XhBFrl1dbtleLgsPmrHP7tK2VStDTs qsJ07ckxwul2mwXg_Xrr8nw
glo3YkbTQnzTQJ5evtzc8gDulM0o qF_std?h TFlgqwTrKm_Fd-74j73gJwzrK0gloYJteVS
aHDL7A+ZHlFLIygly8nkKBqQjNUQF8 sC48pgqJDq|?FV+ih-nsjh#Bw#NN1AhGL+Jm78BqAw
H-U8Jyg7n:6ei#af:qF?erI6l?As8iefonU9nwI-l7As!IrRm-ajd3F|0NVM-sccAbZIMC6VF
JqWhZczdLcpfqn_5kNwuKe30yKP6e8|ZeqXO3k8Vn3CFkDB_ke??9qDMr8tfqpRvqkGhMe2XF
AAx7JTdlXYYSdVMdA1!NjHgS1RNdUI2AxCDcaJuS8iiwm#NuxeJcNK7jSuiDA2ZAj!lj+n7D_
-FQf::fvo9:1MM:YVuA0VxX-+yuhn+61y 4vyVddlx aIupDxQFMxyPtaVcX1!mhmZAmLxT5W
CC603Xv0n:CqhLd 9:1g3yFpS2CYaaOf8L2gtSFLjWTC2ay1:v1T0kTQ?WyRNn14Qv_zy5|6l
qSU9E92MC9hstXhHAA+Ssy 5-aSKejShBLyHdfFDC:C1WCRSpOvAx8|4zwjcV|M18b:PnBqmN
pGWHgmJUU3:sBt|6lSB+2?9tUMGCXG?mk?1_2MufcGW1XdiMDY7Td3#HckI!h+Qsp?SjNB3 ?
p97lhhHvpl7#E93wDTkoWeiCtCB6Ca9lMN:rjvVugE?IvmBjht_|wUQ1|XS#Xp9_agWo2gd5R
Ua9QU!j|UQ|G:tdALda+OaP-bthr|dmPLW9tc01_WBJj|OHIU9:Qk8o:kHm3CE95BP?W6ptd3
usPh|dRWdWftqwqtZ21#4R5O4+ 4#T2C?nkCjbSZMM#Ml5YqO-?q:HL?J|sT3h-#rQ9#gB09P
j4ehkYokoQUs2Gvb5GS?xv_Tmmis?wO1TrHY1r_txSAJG+C04nza5xZ:dH93a!C0G56X4#fAx
us:1SdYdh14#T2C?nkCjbSZMM#Ml5YqO-?q:HL?J|sT3h-#rQ9#gB09P5t4QK_wb3XZiO|ZFS
p4sHcceZElZvE+Nh:gUlQqEUQIWBswi931xdjFMGBpaCqrTM#1x9GXZdRJwBBjU3IUcpG!sHG
jmQbkkb??bb9aO4Chq4HvXq_jG:iZh5Uux5VWYxwa2+uT1n#iLmKCjmf6oGlwssJE0qHP+qtd
gJ-mTnvc?VoJrCXtG-fSg78_B!wfPCXJSactZKuggGNr5NT7S0MzS1J 0QQrhDvlxH?t 3V
Second Run:
GAG58FX0vFXjbXH-S#Np6aEPC6ekzwQvpbP0 3F8AihC9UdZ0+2of_70kfqv?KH-SQo5kyEAM
hjLKSsOShgSjjH3Grh|YMjqC6fwRji hY9v?aJZDunghjC FYvd#x8nxCm#theeFMuXMrhTlC
:dZNv3gLrJMp04uYXAL 5z3v#nkrCjDa c:oPi6 pPVY?fIsduoUp7T#mb9rYCUN2AvIr:epy
p1rJJrJJrhhr4HM!mtC6AQiYq 50jSC!Gt?6QcrfEjfGorwCll?s0UsnCdhG34 EY5sj0I7F
kxATb4J4aBae!wHoXJx0WnZdLl0pdP V_s9m17E:ex5b#3ok83maad-2pXIwxUXvNUEnnyLXH
AoRZTCJ2!T#4-c::ZcokDSyFgo#9TTlncSKkMCstgolM jnvB4sibSNV!O1Xdj884jdEpwRI7
hM1S#R|RM1GKrJlMx7uChoIdYQnZYMSSem96piXhBpqGB7EE3fpxv9Zjn|BOfB#FxLVShoI6h
Dz3ivvRAodwv4wlgZZrQm73U8BLYANr8dJQ0p!Lus76Cwj#SxJII!JxDKTnktxm#j27FCTFY7
RK#iHq4tlVDiqV3Mr73+VVhWnz6f2|#6yq#gFFBU61en7OrZ#DU#_T1KIV|CHz||N|3UaQcki
qSKpX6p:MgXacPBTjDqRS1|MytVmc??jcmdLh5r6m tywS8|h8_Sh apmSLq1AMaC+9bh Yv+
QJdvgr#rdpm76yyoGd8Zb#JVv7zG7uR8-LrN!OaNNXNiGEM?53CJoI8JHUJPf5za:BWa809sZ
CFg3J2sndTYYBTdm5Oh9WdFqlDC wO NCOF|SdC5aLf0|:1sAOFpu1Rt1LOfpkbjAVNQI1Ttn
PdjcQ1QWQy-wUagFcNgxQxV#G_x6_g3bHF3m8Jjfmgmp0ZaVTAA4OeAR 3RqJTgjc??jb2?v0
xL+B? B m3gyOgBCnPy:me40_ZZyiYBCM|zl7DA00nH8v EC4ozl7hDr|H:irBmLv9rCl?DB|
jSWhZYRNSoZh6Tko5ePqx8d+x9jOwJ9q9HyXm_YGGt!RGUsxUVOYqw622w8I2#y45KkjCzS++
! vpssP#mwYBBcVoY1t:TnLqPzzv5mu#F1 QTnLxqy:5wVyYd9uKy1nsqY:wSyji79D-8diOs
XCV34ukN|9|WzyBUU0+ZU!i6!JbB:LS88L238 |CXRNP-lxppoMipVK6A9EpJx#r20jXCQkfC
u!e1W0uHKh2KRKdD-HW59Zf84MQ_CwD0qCdt?HVC94R_dw0XCl!T?:znt!rR44gLCb5|R9aft
s7RcsundeK|Y8u1xE7|gg7VUgLt2kQ8W?Pw--aO0-N!S3lq-hwizVe9k2yrI2iBEEVurPbz3k
cEXHAQK:TEdT-ZCkdpv:hT0n5d+r!ZxRb-rs:vvgNdW4l:pai-3CZfkNpdfoIDPu6Z-15aaxS
AcH!Y!JJCpCbHJOosE2NF+bc:MJSd!TAtkjoNIj2eewlovAdRTcAjFljX1SwAJdoyuNsW2wc9
Nd4brngbG+DCb+1NL1U-+BBAxDXbHX1cm1qzyWcwCXFiH1v30r4P-U3:CXXgS?dVPdM9pUU-Q
X+Qnb_IduieZkrnWkUAd4XQ?zC6Jzv22p8CgXA 4:Xz#8zylUpXkAC5|6VRvp:+JkUoF4X#iN
q7fgCpMgMH7rt7+?RCrn9HV5T7xUEw_bP1Uv9HHKgBmYbm A211PJLS_|S+Lj1ne2EYxwSW_s
ipqEg:X?!c-pYtxIgbtVG-VFMNct?xpiXTSLQcbfw?NPJgtGW4p#4zTJLZ-UFmPTvEt8mdb-Q
kuXTnNQz|asTNayvWFXJK v7TmmVBMp|Jp9un K!s0Xb0esN 5EnW|yF0UXotdAN#x+t9mtl
-Eb1J#-1|:18ylTE+ hZ!pmyIF6TxSr2lQWY+CY:Zrp8Vj-RSZo1lGRtIVmPyzdWV+?Dn4D5Z
!zupeZpspY0j?zc37puAR+LM+BRQg c34d1!8yziP94:2ntqeVJD8ynp1szKB6VXe_9gyZil5
hrp|wESsOSh6JjB8BGCBH?9:vxjxnhM1fO6naExgQCAu8RrA7Fx7iMCH16h9K|M8EsLrVY6:y
Zf#puO9hDFNPUqwJW0:SGmp2woALX-ufvV:SL8WhGt_1f ub2NScmQOPoYzJ4TlG2RcUJIhPS
_ObYH2 Jk72YU-LG1S+O-DkURITg547tg#NU#8GTe1OLyHhG4kzZt0VOnpJ1QMiVxW+aGJtcC
Fm7|tY1feJyc5ngtpeFPM6kjG54cQUzp!TNX_sv1m3:Y6UD!amHM_px mCMYp::vhNZMqex9j
VQ0qqPuIPYwuQeD2UDjGpKlrHZqXGwVY?QJWrtMIl|CdW8-RcGIQ_6u1e9hoQz#HGD1Prrn!H
WLqm:eKU2jtUkDEwAf1L2?I7xbe:gShmzfo2CgcUxL|jgqUmLhhetInURV|a_LSKVxjtDNna4
Qp73OmWkpry3wuxrveKyM-PLia5A3Hd#giIXzFe3PJqxEsTm+P2rNe6Euaa9_N0wvefCJiFCr
7:x!sRIUtHyZXI#:Gx4D97prCQ89mXZMD+?d+VesF:vPDblFyytLF6UdSI!84EBl9yIFKA4O
9F+3I6B#e65AEKQhDPrEDcbIVW9scy BcEnR?2ywFbhC2vpt2c:lf?HDudzNE0P-E2UiTnk46
GKir5CGmzJfE7FEBly6nQXfiH6PPv_6j5FsWa YK?HCPW6+dYc4#U+fK??FQVi+nyGnH1aFY
wc!:aa:PzUae88aBrc2zrAkqGXc|gOF5XwVfXr umGylJ4jxAL3TAX9+8k7e:yfPfIh:qAe10
2RIPO7LP|09zfg66O7gpSbDQ20?GEfW6Qg+B?TqUa+9GEEbrPz+RcCRfI2b?pD+rP4nNcdRj3
gJMzaz73_zlK2VlSALg qshMb7t5!UtlTQnZBm3qVcVrO3NtmwaeHA7BFJuJ2uLGezg4aXrs1
f mS+!RNg:xZ3OvGhIiLOARNN0j!8OK+ Kg620GbuOj!QDB+nKmcD0t44O|kAvBM?KIcL00TK
fK6QTTSc_QIMHA0?nU|w2!VqNq3R!hA2PExBz_w9KCKyC+ZxSOXEL3:i4 u+uDG6nKjN2KDWg
F_CF1GhM1FMvkGm4XmpGjdEZHA-xhmN4JQsgjdUVQPPx8zmU96pgRp5Vc|PidU6Jqpkf ylKs
gJ17?3TY3YHN?s5BurGPLhsVAl0AcgrHkJFKk3SdX MTYsJaVhR5wtlRmgDC? 5c8fG1US4!v
UW1j|o+|+jOHMrE68LsyYE33e4cOyS5k8xkWYnK3usy5r0kTpo:gt6yPu_55N0DdItdam+yy6
gJBma3L37mAcgrHkJFKk3SdX MTYsJaVhR5wtlRmgDC? 5c8fG1US4!vsBefg1n3ht7QlZOXS
bCYjqq#b?tbN?p FN-cyocxVu#HSLF-EncXQ?_290F3SJ--Gn5z69zAkwFF0S?Zn8Z aYzcBw
UahK||KUUKKUa5LDOTH_WkTK31PcyH!qt6Y4druSa8gt3Yo+OWnGkMw?da1LSppnBdQkWgG3k
R:rZbqHTDa:6Azhrq8Md OeBI::jAac!dc|xVOO Bq3A73+-yczUVq-fY3gnec5S7iorx|:4Y
As you can see, it looked different for the same order of 50 lines of text.
So, any ideas?
Any encryption method which relies on the secrecy of the algorithm is flawed. The attacker will always know the algorithm. See Kerckhoff's Principle for a longer explanation.
It is absurdly easy to write an algorithm that you yourself cannot break, anyone can do it. However, unless you are a professional cryptographer, a professional cryptographer will find it easy to break. Have you tested your algorithm against differential cryptanalysis? Do you even know what differential cryptanalysis is?
There are many excellent cyphers available already, suitable for many different purposes and with varying levels of complexity and security. Don't reinvent the wheel; use an existing cypher.