If an author wants to hide something to prevent FEB find it, it means that he does not want the corresponding module to be misappropriated or modified by others. Sorry that such a comment might be a bit mean, but I don’t think it would be wise to force the author’s encrypted part to unpack.
If that is the case, I recommend developing more stronger encryption.
When a new format is developed, I would like to develop another routine for it.
In this case, the routine was requested about a year ago, and I had advance notice of its development.
However, it was a pain to create, so I kept it on hold for a long time, but this routine became absolutely necessary, so I implemented it.
That was when I was erasing unnecessary routines to save space on Kaitou.
When I erased all the debug routines, the menu definition pointer also disappeared, and I could no longer access the menu from FEBulderGBA.
By the time I realized this, I had already stored other data in that area, so it was a hassle to change it.
Therefore, I needed a routine that could keep track of the menu pointer even if it had been destroyed.
Without it, I would have to manually enter the address each time, which is inconvenient.
To implement it efficiently, it was necessary to modify the structure of the FEBulderGBA constants.
And if I were going to make it anyway, I aimed for a general-purpose routine that could handle ROMs with pointer corruption.
I think this method of using reflection is very convenient because it allows us to deal with more complex structures just by who makes the definition in custom_pointer.txt.
The recommended obfuscation routine for now is to swap the contents of the structure.
For example, the zeroth of the Unit structure contains the string ID of the name in the short type.
If you swap this with other data, it will not be recognized correctly by FEBuilderGBA.
If it is a BG, you can swap the lz77 data with the TSA data.
Just change ldr a little.
However, the side effects of this routine are extensive and may be troublesome to create.
FEBuilderGBA is strongly dependent on the contents of the structure, so I believe it would be quite difficult to deal with this.
Not impossible, of course, but …
In fact, this has led to the leakage of a lot of material that is not expected to be published. Including battle animation, and portrait and so on.
Not everyone wants their work F2U or even F2E. The leak of the material caused by the update of the new version has dampened the enthusiasm of many authors who contributed non-open source GBAFE materials. And forcing hackers who know programming have to rewrite encryption patches to fight thieves who use FEB to steal material. However, even so, those encrypted works that have been released cannot be recovered because of this update.
These are not assumptions I’m talking about, it’s what’s happening.
I strongly disapprove of FEB’s forcible re-exposure of the author’s actively encrypted parts to others. Suppose such a scenario, I made my own material that none open sourced, then you tell me, “ok, I have the right to decrypt even the actively encrypted material for anyone to steal since I think it should be open sourced” ？？ What do non-open source authors think about this approach?
Let me take two examples,
FE10RE, after you open it with FEB, you can’t see the materials such as battle animes, etc. Guess why? Is it because the author’s level is too poor, which leads to a bug, or is it because they actively avoided FEB recognition?
Another example, such an battle animation, have you found it in the public F2E repo? No, because it is not open sourced. However, such a material is indeed under development. The original author stated that the project will not continue to develop until they find the effective way to prevent thieves dump them through FEB.
¯_(ツ)_/¯
I agree with you. It is our work, our efforts and we want to keep it with in secret.
Firstly, if there are any animations in the Repo that have been dumped from roms that the devs don’t want, I’m right here. You can tell me to remove them if they’re illegitimate.
Secondly, @explosionwolf, isn’t this your game?
That looks like an animation from the repo, one by Khrene Kleaver. I’m not saying you guys can’t have your secret animations or whatever, but it never fails to amuse me when people take things from the community and use tools made by the community but also have strict “Nobody can use my toys!” rules.
“The community helped me out. But will I give back to them? No!”
That’s the common attitude I see.
What leakage? What animations have been illegitimately used or put in the repo so far?
I’m ambivalent about decrypting intentionally encrypted roms, by the way. I just shake my heads at people who take-take-take but never give back, but I’ve no interest in stealing their work, either.
5 Likes
Trying to fight art theft by trying to develop stronger encryption is frankly a losing game, especially when the material is not being kept secret in the slightest; it’s put on display for anyone to see if they play the hack. The only reliable way to make sure no one else uses something you made is to not put it into a public release in the first place.
More generally, art theft is a cultural/societal level issue, so approaching it from a technical standpoint is unoptimal. The best way to deal with it is by creating an atmosphere where it’s not tolerated. For communities to require properly credited and properly permissioned usage of resources to host projects, and removing projects that break those rules.
5 Likes
I understand that you want to hide it.
But I want to see the data.
The more it is hidden, the more I want to see the data.
Whether or not you then decide to steal it is they decision, not mine.
2 Likes
I’m not talking about our common repo. If people can directly dump animes from other works and insert to their own rom, uploading to repo is not profitable for them.
At the same time, I’m not advocating for people to stop contributing to the public community. The existence of a large number of non-open source authors is an objective fact. They do not agree that their resources are misappropriated by others, and that’s just the fact.
Both properly credit to the open source material, and respecting the encryption behavior of non-open source authors, the goal are the same, which is to inspire more people to participate in the FE Hack cause. And the work you mentioned is not my game. What I’m working on is just c-SkillSys.
1 Like
A resource that is dumped by skilled hackers, or it is exposed to anyone who has the FEB, these are not the same thing. Especially when you take into account the difference in the numbers of these two groups of people and the difficulty of obtaining encrypted resources.
1 Like
My point is to respect the needs of non-open source authors, not take away their rights.
1 Like
Anyone who’s intent on stealing from someone’s ROM has already been able to do so, and this update doesn’t make a major difference. The most this update does is skip a few steps in the reverse engineering process; a thief still needs to perform that reverse engineering themselves for a number of things. This doesn’t crack anything wide open, it just makes FEBuilder able to apply what someone’s reverse engineered.
7743 may have oversold the feature and other people may have overreacted as a result. The technological impact to FEBuilder’s internal structure is major, but the practical effects on asset theft is small and niche. The thieves still need to find pointers themselves.
2 Likes
How you use this feature is up to each of you.
I think we should do as we please.
I think this discussion will probably end up sterile.
This is because ultimately we are talking about the right to repair, the pros and cons of reverse engineering, and the pros and cons of ROM Hack.
So I think everyone should be free to do as they please.
4 Likes
https://drive.google.com/file/d/18Z9N7nHnXYdixmosG6VPMsdoNYNGMb1d/view?usp=sharing
yep, once again, thank you for your time
when Raigholm moves next to Near the game glitches out and eventually crashes, this has happened previously relating to other units but those issues have been fixed before.
02833E: B8
I’m not sure why, but it looks like 02833E needs to be B8, not 09.
It is a 1 byte correction, so I will not send ups.
please do it yourself.
1 Like
once again I thank you so much for this, I have no idea how this keeps happening.
https://drive.google.com/file/d/1lhmpjY53-b5zrrG7Tz4KLaVLA0KRZ41N/view?usp=sharing
I hope you can help me because I have got some issues with the Weapon Rank EX patch in my Rom which i hoped I could just ignore but now even if I am not to far in this rom at the moment it still is a bit annoying and I don’t know what the problem is there.
If you could see through it that would be great 
Beansy is the one who created WeaponRankEX, so please ask him.
I do not use WeaponRankEX, so I am not familiar with the specifications.
1 Like